03-20-2012 10:35 PM - edited 03-20-2012 10:36 PM
I'm having fun wrapping up a new application in LabView, but I'm having an irritating problem. My app spawns four VIs that monitor four DAQ cards continuously. One of these monitors five lines on a digital input port. When this VI runs, the top-level VI hangs. I have done some tests and found that if I don't spawn this monitoring VI in the top-level VI, but rather run it in parallel, it will still hang the top-level VI (no user input is possible, although the indicators being updated by the other three monitors are updated.
When I quit the errant VI, the top-level VI becomes responsive again.
I've tried stripping down this routine to the barest essentials, I've changed the DAQ task from a port read to a line read, I've tried a variety of acquisition types (continuous, single measurement). All give the same result. Removing the polymorphic mxDAQ Read vi resolves the problem, albeit unsatisfactorily.
The card in question is a 9421 DAQ chassis card running over Ethernet. The other cards are 9207 and 9208 AI cards and a 9215 AI card. The main user interaction I'm trying to achieve is a digital out on three DIO cards. LV2011.
I'm not sure how to debug this further. Any insight would be appreciated.
03-21-2012 05:32 PM
How fast are you running your digital input task? How many samples are you reading at a time? My guess is that your read size is too small for your sample rate.
03-21-2012 07:40 PM
THanks Mark,
I am reading at a low rate. I've tried 5Hz and 100Hz, reading one second's worth of data at a time (5 or 100 samples). The loops (Producer consumer architecture) show the VI is running at 1Hz, as expected.
I am going to look to see if there are some LV primitives that I can try, in case the problem is with teh polymorphic VI available in the mxDAQ palette. I'll be able to test things aghain tomorrow.
I didn't mention that everything did work for a few housrs yesterday morning, but then broke again.
03-21-2012 09:23 PM
Hi littlesphaeroid,
The fact that you're seeing this with 4 VIs makes it sound suspiciously like the issue described in this Idea Exchange posting: Make DAQmx calls capable of running more than 4 multithreaded tasks. The comments describe some potential workarounds, like making LabVIEW allocate more threads.
Brad
03-21-2012 09:40 PM
This was very helpful. Thank you. I avae some new ideas to persue, such as installing a delay a little under the data aquisition time before the DAQmx Read VI. I can also try combining into one task two of the routines, since both are reading voltages from two separate devices. The other two are current and DIO reads, and AFAIK a task can only handle one kind of data aquisition (crrent/voltage/counter, etc). I'll report on my tests tomorrow!
03-24-2012 02:34 AM - edited 03-24-2012 02:34 AM
I applied the simplest of the solutions suggested first, and it worked: by setting a delay before the mxDAQ read VI, the lockup I was experiencing did not occur. TO be safe, for every VI that executes a continuous data acquisition, I set a delay in the loop of 90% of the acquisition time before the read function. I guess this means that these reads do some sort of continuous polling and thereby occupy a thread. I did not delve into thread issues at all. Thanks for the help, this saved me!
03-26-2012 11:17 AM
Hi littlesphaeroid,
That's right, waiting in NI-DAQmx's nilvaiu.dll (or any other external DLL) occupies a LabVIEW thread until the function call returns. Whether NI-DAQmx polls or uses a different wait mechanism is controlled by the Read.WaitMode property, but it still does its waiting in a DLL call.
Brad