Data Acquisition with DAQmx Read in a parallel loop does not write all samples after first run

[jtboik]

 Hi everyone,

 So I've got my valve timing pattern in a state machine and then I want to read/write pressure (and eventually add more channels in an array) in a separate loop. There aren't any race conditions so it should be fine its own parallel loop constantly reading/writing data the entire time with a wait time of 100ms.

For some reason the read/write only functions properly in the first run, writing about 90 samples in 20 seconds which is enough for now. If you re-run the program it only writes one sample to the next file for some reason. 

This might have something to do with the way the analog read is setup, but I can't quite figure out why it doesn't "reset" on the next run even though I have it being cleared. Please let me know if the reading is set up wrong and how I should go about setting it up for a continuous read/write the entire time the program is running. 

[jtboik]

I switched the DAQmx read to N samples and now it seems to be writing more than one sample, though I don't understand why it can't just loop 1Channel-1Sample over and over. 

[Kevin_Price · Accepted solution]

It's not the DAQ.  It's your use of a GUI indicator that's set in the upper loop and which terminates the lower loop.  When you start the 2nd run, the value is already held at True from the previous run.  The lower loop will query it long before the upper loop has a chance to set its value, causing the lower loop to terminate after 1 iteration.  The upper loop eventually ends too, but will always be setting the value back to True as it terminates.  So all subsequent runs keep doing the same thing.

The simplest fix to your original code would be to make sure you initialize that indicator to False before the lower loop starts.  You can write False to a value property node before the loop and use the error cluster to put it in line with the DAQ config.

-Kevin P

[jtboik]

Thanks, I ended up checking the "clear indicators when called" in Vi properties instead of using the property node. Not sure if keeping the indicators cleared each run is bad practice but it seems to make sense to reset them every time.

[Kevin_Price]

I'm not 100% sure but I suspect that setting will reset all indicators to their default values -- and it's possible for a boolean indicator to have a default of True.  Setting the specific troublesome indicator to the specific needed initial state of False would be a better practice.

A crude analogy is that you're using a sledgehammer where a flyswatter would suffice.  It's both overkill *and* less likely to work as intended.

-Kevin P