This content is not available in your preferred language.

The content is shown in another available language. Your browser may include features that can help translate the text.

How Do I Get a DAQmx Timestamp in LabWindows™/CVI™?

Updated Apr 18, 2019

Reported In

Software

  • LabWindows/CVI

Driver

  • NI-DAQmx

Issue Details

How do I get a DAQmx Timestamp in LabWindows™/CVI™ or other C-based application development environments?

Solution

Unfortunately, we don't currently have a function call that will return a timestamp from the DAQmx driver in LabWindows/CVI or other C-based application development environments. This requires us to take our timestamps manually.

To begin, the timestamp returned by the DAQmx driver in LabVIEW is called t0 and refers to the time when your first sample is read. This time is taken by reading the system time at the time you call the DAQmx read and subtracting the number of samples already acquired to determine t0. It is important to note that this doesn't work if you call the read after the acquisition is complete. The time between when the acquisition is complete and when you call the read will not be accounted for. 

In LabWindows/CVI, you cannot obtain t0 directly from the driver. This is because you cannot read a waveform data type. So, we need some way to manually calculate t0. With t0 and dt, we can approximate the exact time of every sample in our waveforms.

There are two options for manually determining t0. Each option has it's own limitations and requirements.

Option #1:
Try and do exactly what the driver does. Call the current system time immediately prior to calling the DAQmx Read and subtract dt * x where x is the number of samples already acquired. This will require you to know exactly how many samples have been acquired. This can be found by calling the Total Samples Per Channel Acquired property immediately prior to the DAQmx Read. This introduces some points of innaccuracy. For example, you're system time is already inaccurate to some amount. In addition, it takes some time between calling system time, calling the total samples acquired, and calling the DAQmx read. If any samples are acquired between calling the system time and total samples acquired, you're t0 could be off by that many samples multiplied by dt. For slower clock rates, you will have more accuracy. 

Option #2: 
If you are not using any triggering and your acquisition starts immediately upon calling the DAQmxStartTask function, you can use option #2. All you need to do is call the current system time prior to calling DAQmxStartTask and using this system time as the time for your first sample. The inacuracy in this measurement will be due to the system time inacuracy and the amount of time between calling system time and initiating the task to start taking samples. 

Additional Information

If you would like to know more about the limitations of t0, they are outlined in the DAQmx help. You can find the help file by going to Start»Programs»National Instruments»NI-DAQ»DAQmx Help. Once inside, search for waveform timing limitations. In addition, t0 is taken from the computer's system time and will carry the inaccuracies of this time.

Considerations:
If you are using any triggering to start your acquisition, you must use option #1. If you are calling DAQmxRead after all of your samples have all been acquired, you must use Option #2. Otherwise, both methods should be pretty close to the initial time for the first sample. The main point is that you should take t0 with a grain of salt. Understand that taking timestamps using system time has its own inherent inaccuracy. If you are looking for a device that has more accurate time stamping information, I would highly advise you to take a look at our High Speed Digitizers.