Waveform timestamp wrong after DAQmx Read timeout

[dstubbs95]

I am developing a data acquisition program that uses a rising edge digital signal to serve as the start trigger for acquiring a finite number of samples. To aid the user in checking the sensors are configured correctly prior to running the test, I have developed the program to run in a continuous acquisition mode showing the data to the user via a waveform chart whenever the start trigger is not armed. When the user presses a button to arm the trigger, the task is stopped, reconfigured to use a start trigger with finite acquisition, and then daqmx read is called to acquire the desired finite number of samples. I have the timeout on the daqmx read currently set to -1 so that it will wait indefinitely on the start trigger. This is working fine except for in the case where the user has armed the start trigger but then wants to abort the test and go back to "preview mode". To implement this, I need a way to get a daqmx task which is waiting on a trigger out of that state and back into a state of continuous acquisition.

After doing some research, it seems the best way to do this is to set the timeout on daqmx read to something finite so that it doesn't block indefinitely. That way it doesn't block execution of the entire loop and each time it times out I can check if the user has pressed the abort button. If they have, I discard the timeout error and reconfigure the task for continuous acquisition. If they have not, then I simply discard the error and call daqmx read again. This works and allows for aborting a task configured to wait for a trigger. The issue I am having is that if the DAQmx read call times out waiting for the trigger, when the trigger is eventually received, the waveform data I get has an incorrect start time of 6:00 PM on 12/31/1969. The relative times are correct, but I was wondering if anyone had any suggestions for how to avoid this erroneous t0 value?

[Kevin_Price]

Please post runnable code and identify your OS.

I can only note that the timestamp you mention is suspiciously close to the Unix epoch time of 12:00am Jan 1 1970  -- a mere 6 hours earlier.   I wonder if you're in a U.S. Central or Mountain time zone?   Central Standard or Mountain Daylight would be 6 hours behind UTC...

-Kevin P

[dstubbs95]

Hi Kevin, thanks for the reply! I am using Windows 10 and I am indeed in US central time zone. I think you might be onto something regarding the Unix epoch time. I am attaching a VI here that will recreate the behavior I am describing. Since the simulated daq devices auto trigger themselves, I think it will require someone with some physical hardware to fully recreate the scenario. Using the attached code, if you set the timeout to 30 seconds and send a trigger pulse over PFI0 during that window, the code will return 1000 samples with t0 set correctly. If instead, you set the timeout to something small like 0.1 seconds, the code will still return the expected samples upon getting a trigger pulse on PFI0, but the t0 of the waveform will be 1969.

Also, I saved this for LabVIEW 2020, but I am using LabView 2022 Q3 with DAQmx 22.5.

[mcduff · Accepted solution]

Don't have hardware to try it out; simulated hardware worked no problem, but I cannot time out the operation with simulated hardware. UNIX time is weird because LabVIEW doesn't use that standard; maybe DAQmx does, but it seems strange NI uses two different standards.

A "task wire" is like a reference/queue wire, you can branch it and use the Abort Task if you are in in a "infinite wait mode", that is, timeout set to -1. Use a button to initiate it. See below. (There is probably a better way but need hardware to test it. This will work for any task, used continuous acquisition to show you can stop task outside the loop. You will have to catch the error though.)

[dstubbs95]

This solution seems to work, thank you! I am attaching a version of this that works on my real hardware in case anyone in the future should want to reference it. Essentially it ignores the aborted task error and has some logic included in stopping the event structure loop to determine if the task needs to be aborted or not.

 

[mcduff]

Glad it works. A better solution may be to use the "N Samples Acquired Event" instead of a straight read. It is non-blocking and you should be able to stop the task instead of the abort; however I still don't have real hardware to check. Look at the example finder for continuous input with events. (Note the event structure will also work with a finite input task.)