Waveform t0 invalid (later than system time)

[elyte_dev]

Hello everyone. This is my first post.

I am encountering a problem when trying to acquire an analog input (current) from my cDAQ-9171 in combination with NI 9208 (AI +-20mA). I try to acquire continuous samples with a rate in-between 1 to 10 Samples/s. I haven’t wired the “number of samples per channel”-input from the DAQmx Read VI to get a non-blocking behavior, so that I can stop the loop whenever I want. The actual problem is that the waveform has a wrong start-time t0, which is ahead the system time, see screenshot. It’s exactly the system time plus the sample rate, until the system time reaches t0 and it starts again. Therefore, the timestamps in my log files aren’t correct. The Log VI is coded, so that it logs only when the array isn’t empty. This is necessary because of the non-blocking behavior which gives me a waveform each iteration. I know that I can adjust t0 manually afterwards but I would prefer to get a correct t0.

If I wire 1 to the “number of samples per channel”-input I get a correct t0 but I have a blocking behavior, which means with a samplerate of 10 I need to wait up to 10s to finish execution.

Actions that didn’t solve the problem:

• Wire the DAQmx Read property node “Available Samples Per Channel” to “number of samples per channel”-input
• Insert a 100ms wait to slow down loop execution
• Wire the timeout input (100ms) and “number of samples per channel”-input to 1, in combination with clearing the timeout error

Software is up to date:

• Labview: 2020 SP1 32-Bit
• NI CompactRio: 20.5.0
• Windows: 10 Pro 64-Bit (Version 21H1; OS Build: 19043.1165)

See attached VI snippet (part of a library -> not executable, only for visualisation) and screenshot with the problem.

Thanks in advance.

[Kevin_Price]

I noticed that the "problem" case you illustrated was one where you ended up reading 0 samples, in which case you shouldn't be logging anything anyway.

Your post contained 2 seemingly contradictory descriptions:

---

If I wire 1 to the “number of samples per channel”-input I get a correct t0 but I have a blocking behavior, which means with a samplerate of 10 I need to wait up to 10s to finish execution.

Actions that didn’t solve the problem:

• Wire the timeout input (100ms) and “number of samples per channel”-input to 1, in combination with clearing the timeout error

In the 2nd case, are you getting wrong t0 values only when you also get timeout errors and 0 samples back?  What happens with t0 when you succeed at retrieving the 1 sample you ask for?

In the longer run, I'd probably want to use that short timeout strategy to keep the loop responsive to commands coming in on the queue.

If I get a couple minutes later near hardware, I'll see if I can replicate your "future t0" problem.

-Kevin P

[elyte_dev]

Thanks for your fast reply.

Samplerate is currently set to 0.1 Samples/s = 1 Sample per 10s.

First case (rightTimeLogging.png): 1 is wired to the “number of samples per channel”-input and I get a correct t0 but I have a blocking behavior. The Log-Button Value change event doesn't correspond to the first acquired sample because last iteration needs to finish first. An Exit would also be delayed as already mentioned. Beside that, the acquisition seems to be correct.

Second case (wrongTimeLogging.png): Wired the timeout input with 100ms and “number of samples per channel”-input to 1, in combination with clearing the timeout error. Responsive but wrong (future) t0 and therefore wrong timestamp in log. When there are no Y-values coming from DAQmx Read VI, t0 is reset to the value when it executed first.

[Kevin_Price]

Didn't replicate here using your original approach (0.1 Hz, dt=10, # samples to read unwired).   Each single real sample made t0 update to be equal to the probe update time. Then for many fast iterations where 0 samples were retrieved, the t0 time remained constant at that previous value until 10 seconds passed, then it would update to be present time again.

LV 2020 64-bit (also LV18 32-bit, LV16 32-bit)

DAQmx 20.1

PCIe-6341

Win 10 Pro 64-bit

Aside (for the wider audience): I'm not sure why DAQmx 20.1 kept support for LV 2016 on this PC.  On another one, installing DAQmx 20.1 *removed* the DAQmx support for LV 2016 I'd previously estalished with DAQmx 18.x.   Not sure why things are different here, but I like it.  Anyone know the secret for making this happen on purpose?

-Kevin P