I'm forced to use schematic approach for a project (instead of VHDL).
My problem is the following: I have two buses, for instance BUS_A[3..0] and BUS_B[2..0], I would like to connect BUS_A[3] signal with BUS_B[2] signal.
How can I realize such an assignment?
EDITED:
Here is what I tried with the following error message:
ERROR message:"Bus name allowed only on bus line -- signal "DIN_1[0],DIN_2[1]"
Related
Used JSSC to write/read data from a COM serial device. COM was detected but attempting to write or read gives this error: EXCEPTION_ACCESS_VIOLATION
This is a known bug in JSSC. Several other people noticed it too (e.g. https://github.com/arduino/Arduino/issues/6788). It seems to happen with Java SE 9 on Windows 10, x64.
Unfortunately, it appears that the JSSC project is no longer maintained/dead. However, as of this writing, there are over 150 forks, some of which appear to be active. For example, maybe the following fork might contain what you're looking for: https://github.com/aploese/spsw
In case you want to go with a different library altogether, this question provides a working example using jSerialComm: How to fix Java rxtxSerial.dll or jSSC-2.7_x86_64.dll Serial Port Error in Windows 10?
I'm developing a tool for Intel PIN. Somewhere in the runtime, it gives me the below error. I want to know if there is a way to tell PIN to print the backtrace or let me handle the segfault in the tool itself.
I'm running my tool with MPI and it crashes when I insert values into an unordered map.
C: Tool (or Pin) caused signal 11 at PC 0x2b09594533cb
mpirun -np 44 pin-3.7-97619-g0d0c92f4f-gcc-linux/pin -follow_execv -t pin-3.7-97619-g0d0c92f4f-gcc-linux/source/tools/Simp ... -- program
You can use the following API:
PIN_AddInternalExceptionHandler()
from where you get access to an EXCEPTION_INFO structure which is supposed to be manipulated with the exception API.
Otherwise, you can also debug your tool from within a debugger, by launching your tool with the -pause_tool 20 option. Then you have 20 seconds to attach your debugger to the process. Once attached, the debugger stops (at least with Visual Studio) and lets you set the breakpoints you need in your tool's code.
This is not that easy to debug though, as the whole system switch from pintool code, to pin, to target application constantly. Hence there is not a continuous process of steps inside your pintool code that you can follow, as you can expect when debugging "classic single threaded applications".
I'm making a heart rate analyze, but I'm having a real problem with that. When I'm press to start the programm doesn't work, so, I've press to stop the running program and it shows me in the section where it's ready to close or finish the connection:
Error 5002 occurred at Init.vi. Unable to establish connection with
Arduino. Please ensure that you have selected the correct COM port
and that you have flashed the Arduino with the correct firmware.
This error code is undefined. Undefined errors might occur for a
number of reasons. For example, no one has provided a description for
the code, or you might have wired a number that is not an error code
to the error code input.
Additionally, undefined error codes might occur because the error
relates to a third-party object, such as the operating system or
ActiveX. For these third-party errors, you might be able to obtain a
description of the error by searching the Web for the error code
(5002) or for its hexadecimal representation (0x0000138A).
This is my VI diagram:
And this is my control panel:
And the connections to my arduino:
So:
how can I solve this problem?
Where can I find more information to get this
Thanks for your help, but I'm new on this world (Arduino and Labview)
Follow the suggestion given in error message. First of all, make sure that you could communicate with Arduino using some simple serial line terminal, like RealTerm, or HTerm. In case if you couldn't send any command using serial line terminal, check out which firmware do you have on Arduino.
This is the way, how you could troubleshoot this issue...
You can ignore the second and third paragraphs of that error message; they're generated because the Arduino VI's you're using are generating a custom error code that they haven't registered with the LabVIEW development environment, so its automated error handling doesn't know what they mean. The information you need is in the first paragraph though.
As kosist's answer says, the first thing to check is that you can communicate with the Arduino at all. Before you even start with LabVIEW, have you tried using the Arduino IDE to program your device with a simple program like the 'blink' example?
If that works, then the next step is to make sure you've programmed your Arduino with the firmware it needs to communicate with the LabVIEW VIs you're using (can you link to where you got them from?) and then try a much simpler test program in LabVIEW - again, just get the Arduino to do something simple like turn the buzzer on and off. If you hit a problem with any of those, I suggest asking a new question with details of exactly what you tried and what errors you saw.
There is a one process called NSM in my code. Which abruptly got a SIGTRAP signal and it got killed. So just wanted to know that when can a process get a SIFTRAP signal?
as said in the comments it is a signal so can be triggered at any time. SIGTRAP signal is handled by the debugger; in the absence of a debugger it is quite natural for the process to be terminated. if you are using static libraries in your project then you are not linking them appropriately. with out further information in your question, I suggest you to check your linking with libraries.
I have a LabVIEW 8.6 program that is using a DLL written in Qt; the DLL listens to a TCP port for incoming messages and updates some internal data. My LabVIEW program calls into the DLL occasionally to read the internal data. The DLL works perfectly (i.e., receives data from the TCP port) with another Qt program. However, it does not work at all with my LabVIEW program.
I've attached a debugger to the DLL and can see calls from LabVIEW going into it -- my function for getting the internal data is being called and I can step through it. The code that gets the data from the TCP is never called though; it looks like the signal for incoming data on the TCP port is never triggered.
I know this sounds like a Qt issue but the DLL works perfectly with another Qt program. Unfortunately, it fails miserably with LabVIEW.
One theory:
The event loop is not running when LabVIEW calls the DLL
In the Qt DLL's run() function, I call socket->waitForDisconnected(). Perhaps the DLL is not processing incoming events because the event loop is not running? If I call exec() to start the event loop, LabVIEW crashes (LabVIEW 8.6 Development System has encountered a problem and needs to close."):
AppName: labview.exe AppVer: 8.6.0.4001 ModName: qtcored4.dll
ModVer: 4.5.1.0 Offset: 001af21a
Perhaps when I call the DLL from another Qt program, that program's event loop is allowing for the TCP signal to be seen by the DLL. Unfortunately, kicking off the event loop in the DLL takes down LabVIEW.
Any thoughts on how to keep signals running in the DLL when LabVIEW is the calling program?
EDIT Debug trace of the exec() call:
QThread::exec() -> eventLoop.exec() -> if (qApp->thread() == thread())
in the call to
QObject::thread() {
return d_func()->threadData->thread;
}
The macro Q_DECLARE_PRIVATE(QObject), the second call, triggers the crash.
EDIT 17 Aug 2009: Status update
After two days of trying various ways to get this to work I decided to implement a TCP listener directly in LabVIEW. My LabVIEW application sends data out via the DLL and receives data in via TCP. All is working well.
This question was cross-posted on http://forums.ni.com/ni/board/message?board.id=170&thread.id=431779
You should change the library call to 'run in any thread' that way the UI thread can still run the event loop.
Can you debug through exec() to see where it crashes LabVIEW?
You can also set debugging the maximum in LabVIEW in the configuration page for the Call Library Node.
LabVIEW is finicky with DLLs. It may be easier to run the DLL as a service (write a service that runs the event loop), and then have LabVIEW call a DLL that retrieves the data from the service.
Old NI help note
Just a shot in the dark...could the Qt data be clobbering some of the LV memory space immediately after the exec loop is started?
You probably don't have a QApplication object created when you are trying to call exec() in the QThread. This might be causing your crash. For the main problem, however, I would say that it is very likely you aren't getting any activity in the DLL due to the event loop not executing.