Slow response from DAQ

[Indiana_Bill]

My DAQ system includes RTD temperature measurement via a NI9219 module.  The usual analog in (NI9201), analog out (NI9264), digital in, digital out (NI9401) work fine and run adequately with a single software timed while loop at 20 msec per iteration.  When I add the temperature inputs the loop slows down to the 2 Hz rate of the NI9219 - fine for the temperature measurements but too slow for the user interface and the rest of the system.  How can I keep the loop running and only update the temperature data when the NI9219 finishes?

[crossrulz]

Use a case structure so that you read the temperature every 25 iterations.

I would recommend keeping the count in a shift register.  Each iteration increment and use the Quotient & Remainder to get the remainder of the iteration number and 25.  When the result is 0, read the temperature.  Put the remainder into the shift register.

[Indiana_Bill]

Thanks for the quick reply.  It will take me a bit to implement the case structure and I don't think it will work.  The problem, as I understand it, is that LabVIEW blocks other conversions and updates while the NI9219 performs a conversion. What I believe I will see with your suggestion is half a second of updates followed by a frozen half a second while the NI9219 does it's thing.  Is that what you were expecting?  If so, it is no more acceptable than updating everybody at the NI9219 rate.

What I think I need is some way to start a NI9219 conversion.  Continue LabVIEW processing, polling the NI9219 for conversion complete.  Upon completion collect data and start over. Unfortunately, I don't see the tools to do that.

[crossrulz]

How are your tasks setup?  If you are doing continuous aquisition, then it will be constantly getting the data at a given rate in the hardware.

[johnsold]

I do not know anything about the NI 9219 but it sounds like you should look at a parallel loop for the slow acquistion. Something adapted from the Producer/Consumer (Data) Design Pattern should work. You might need three or more loops so that all your hardware tasks are isolated from the data analysis and GUI.

Lynn

[Indiana_Bill · Accepted solution]

Thanks to both of you for your help.  Lynn, your response put me on the right track but I don't need the Consumer/Response Design.  What I needed is three while loops.  One for the slow sensors (NI9219), one for the fast sensors and user interface, and a third around both.  Now LabVIEW starts the slow acquission and then lets the faster acquission run.  I still have a lot of clean up to do but that is the easy part.

Again, thank you both.

Bill

[iyeager2012]

You should really look into decoupling your UI from your data acquisition. It won't matter how much optimization you get done, if your UI waits on any acquisition, it will always become problematic eventually.