Multifunction DAQ

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView hangs on continuous digital input acquisition (9421)

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.

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 1 of 7
(3,423 Views)

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.

0 Kudos
Message 2 of 7
(3,404 Views)

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.

 

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 3 of 7
(3,396 Views)

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

---
Brad Keryan
NI R&D
Message 4 of 7
(3,393 Views)

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!

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 5 of 7
(3,390 Views)

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!

 

_____________
Creator of the BundleMagic plugin for LabVIEW!
0 Kudos
Message 6 of 7
(3,373 Views)

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

---
Brad Keryan
NI R&D
0 Kudos
Message 7 of 7
(3,354 Views)