Inconsistent Parallel Loop Performance

[arcranda]

My original question was can traditional DAQ devices run in parallel loops? I have some extensive data processing and additional automation that would be a lot easier to do in parallel with an acquisition loop rather than cram it all into the acquisition's while loop. As I was building an example VI, I discovered the answer seems to be "sometimes".

I am working on a calibration rig for hot wire anemometers. It requires pressure values to be read into a PCI-4351 (traditional DAQ) for the duration of the calibration and record wire voltages to a PCI-6110 (DAQmx device) only when the pressure values have settled (i.e. the stream velocity is constant). Inevitably, both devices will be polling data simultaneously at some point.

It seems that the 4351 would transfer its data to a parallel loop, but not when 6110 was running and vice versa - and sometimes the buttons to stop the loops wouldn't work. Will traditional DAQ and DAQmx devices not perform parallel tasks simultaneously?

The attached VI might clear up the parallel structures I'm talking about.

Andrew

[altenbach]

(Sorry, I don't have DAQ installed, and don't use it much, so I cannot answer you primary question.)

Still, your loop in the lower right has no wait and thus grabs all the CPU it can get.

You should also eliminate the indicators and transfer the data between loops without involving the UI and local variables. Currently, you are updating the charts even if the data is stale. Try e.g. an action engine.

How many CPU cores do you have. If you would use timed loops, you can dedicate CPU cores to each, for example.

[Brad_K]

Hi Andrew,

Multithreaded Features of LabVIEW Functions and Drivers explains that Traditional NI-DAQ has a global lock, so if you were accessing the PCI-6110 through Traditional NI-DAQ, Traditional NI-DAQ would serialize all of the DAQ function calls. However, since you're accessing the PCI-6110 through NI-DAQmx, this should not be the problem.

I think you're right that both devices are polling the data simultaneously. I'm not 100% sure about the 4351, but reading multiple samples from the PCI-6110 with "on demand" timing will involve polling the hardware to find out when samples are available. If you switch to "sample clock" timing (by adding a call to DAQmx Timing (Sample Clock).vi), then the PCI-6110 will perform a hardware timed acquisition using DMA. This will free up the CPU to run other threads and will make the time between samples deterministic. It will also allow you to get much higher throughput, which is what the PCI-6110 is designed for.

Brad

[arcranda]

Altenbach,

You pointed me a good direction - I wasn't familiar with action engines until you mentioned them, but after some reading (namely Ben's AE nugget), you have me convinced (although not entirely sure on how to proceed) so here come the questions!

1. I tried to use Ben's running average example as a template - what should the cases inside my AE be? Right now they're "initialize", "acquire", and "close". However, I have to pass a value from initialize to acquire to close - so as is, the VI won't run.

2. Ben had his AE in a loop to add data to the array and in another loop to perform the running average calculation. Since you end up with two of the same thing in your BD, how is this better than creating a local variable?

3. Best practice? I'm pulling values from several channels - should I isolate each channel an put it into its own SR within the AE or keep the data together and have a single SR for the 2D array?

I don't expect anybody to have the 4351 drivers installed - so the what you're probably seeing as three "?" VIs in the "Initialize" panel are the VIs needed to initialize the device (sampling rate, number of scans, etc.), the single "?" in "Acquire" reads the data and the two in "Close" end the acquisition.

Brad,

Thanks for the tip - I'll keep that in mind when I'm implementing the 6110 acquisition into my code