LabView hangs on continuous digital input acquisition (9421)

[littlesphaeroid]

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.

[MarkGrot]

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.

[littlesphaeroid]

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.

[Brad_K]

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

[littlesphaeroid]

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!

[littlesphaeroid]

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!

[Brad_K]

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