NI DAQ data acquisition

[Kevin_Price]

Please post your latest code, and if you package it into an archive format, please use the much more commonly supported ZIP format rather than RAR.   What property node do you think has such slow execution?  How did you test it?

As I said before, Windows will *not* be deterministic or reliable at meeting 2 msec loop times, even with virtually no code inside the loop.

The technique I showed before allows you to read existing recent data from a DAQmx task as frequently as the code will execute without ever needing to wait for new data. 

But you also have some interactions with a Keysight instrument, and I have no knowledge of whether it will also support your timing "requirements."   (I put that in quotes, because Windows won't fully meet them in the best of circumstances.  If you use Windows, you can't also say that the timing goals are truly "requirements.")

-Kevin P

[rakesh@labview]

If I use Read property node fror DAQ it will cause delay. So I have diasabled it. See the image. VI also attached. If I use propery node the acquied data that I logged is with 10 to 15 millisecond duration. Else it is logging in 2 millisecond itself but with old data from NI card. I am logging data in TDMS file. Screenshot of log file also attached

 

 See the data log sceenshot. In it as you see TMVoltage1 is having value but Input current has value after some time.TMvoltage is from keysight DAQ. Input current from NI DAQ. From NI DAQ almost 1000 instance is old value. 2020-06-16 12:30:28:000 PM is the time I get NI daq value. But even before that I am getting keysight DAQ value (2020-06-16 12:30:25:000 PM). Almost 2 seconds difference. 

Please help

[rakesh@labview]

 See the TDMS log with channels marked

[Kevin_Price]

Well, you didn't really follow the technique I linked.  In addition to reading relative to the most recent sample, it's *also* vital to set a negative value for Offset.  In your case of reading 1 sample, you should also set Offset = -1.   

Further, as the comments in the link discuss, if you always read the same # samples, you can set those properties just one time before the loop starts.

-Kevin P

[rakesh@labview]

 

Thanks. Kevin. Please mention  how to set properties just one time before the loop starts

When I used read property node inside my loop it is causing a delay of 10 to 15 milli seconds

If I put read property node outside loop, one time and set offset and relative to properties whether it willl work (that i will always get most recent data from buffer) for all future reads using DAX Mx Read node (not property node). Is it like shown below?

[Kevin_Price]

Yes, settings for Offset and RelativeTo are *persistent*.   They will remain in effect until or unless you explicitly change them.  So the very small code screenshot you just posted looks correct to me.  Normal LabVIEW dataflow ensures that those properties are set just one time before the loop starts.

To test it out, I'd encourage you to run a simple example similar to what you posted.  Set the hardware sample rate to something like 100 Hz.  Add a delay timer to the loop with a control that lets you vary the delay time.  Change the loop delay through the range of 0 to 100 msec and observe that:

- you see voltage changes pretty instantly, even when your loop iterates slower than your sample rate

- you don't get buffer overflow errors, even when you don't read often enough to retrieve all the samples that the hardware digitizes and puts into the buffer

-Kevin P

[rakesh@labview]

Thanks kevin. I will try and update.