DaqMX - Access TDMS dt and timestamp Before "Stop Task" is called

[irishfan22]

When using DaqMX to store sampled data to a TDMS file, how can I access the Start Time and dt? Is there a property Node, etc I can read from? The TDMS file does not include the datestamp and dt until AFTER the "Stop Task" is called (looks like another Labview bug), and I need to view it while the task is still running. See attached

[Taki1999]

Interesting. I have to admit that I don't use the built-in TDMS logging. Most of the time I'm using explicit TDMS Writes.

For your dt, why not just pull it from the sample clock setting VI? Why open the TDMS in order to view it?

Alternatively, why not use the waveform output from the DAQmx read and grab t0 and dt from that?

[ben64]

---

@irishfan22 wrote:

When using DaqMX to store sampled data to a TDMS file, how can I access the Start Time and dt? Is there a property Node, etc I can read from? The TDMS file does not include the datestamp and dt until AFTER the "Stop Task" is called (looks like another Labview bug), and I need to view it while the task is still running. See attached

---

It is a bit odd to open, read and close a file while it is being use to log data (because the task is running and you used Configure Logging.vi) . Unexpected thing might very well happen in this case. The Log and Read logging mode is made to allow you to use the DAQmx Read.vi while logging, why don't you read the output of this function instead to see if the timestamp and dt are there?

Ben64

[irishfan22]

I suppose I should clarify... So our application generates the TDMS file during functional test; the TDMS file is to be used for troubleshooting reasons only when a failure occurs. When we get a failure during functional test, the requirement is that the software pauses on failure. When this happens, we need to be able to open the TDMS file to look at various signals to see how they behaved during functional test to help us arrive at the Root Caue. The issue is that until the "DAQmx Close Task" VI is called, Labview does not store the To and DT information in the TDMS file (not sure why this is, appears to be a bug). Since we cannot terminate the functional test due to our Pause on Failure requirement, when we look at the TDMS file for debug purposes, it shows the timestamp starting in the year 1903, and it inferrs a DT of 1 second, rather than 10ms. This is very embarrassing to show to the customer.

It's obvious that Labview knows the DT and To, but only chooses to write it to the TDMS file when we Close the task. Any insight? TDMS files are made to be viewable while Labview is writing to them, but waiting until the end to store the Timing information is a Huge drawback to using them with DAQmx...

[Taki1999]

I guess I'm a little curious now. If you do a TDMS Write instead of using the DAQmx logging function, are dt and t0 stored after the write or do you have to Close or Flush the TDMS file?

I guess it doesn't surprise me too much that the DAQmx function doesn't store the waveform t0 and dt values until after the task has completed. Might allow for tigher synchronization to triggers if those are written at the end of the acquisition.

Might also be symantics but I would interpret, "pause on failure" to mean that the acquisition tasks are also paused. In this case, you could stop the task prior to reading the TDMS file. You probably want to do this anyway otherwise you run the risk of continuously growing a TDMS if the operator doesn't notice that the test has paused.

[ben64]

Have you tried using TDMS Get Properties.vi to get wf_start_time and wf_increment values?

Ben64

[irishfan22]

In response to Ben,

I have tried to access these. It's the same story. DAQmx does not create these two TDMS properties until the DAQmx Close Task.vi is called on a task...

[irishfan22]

"If you do a TDMS Write instead of using the DAQmx logging function, are dt and t0 stored after the write or do you have to Close or Flush the TDMS file?" I believe you must close it, but labview does not give that option when using DAQmx. It is performed low-level when using the "Stop Task" vi.

"Might also be symantics but I would interpret, "pause on failure" to mean that the acquisition tasks are also paused."

That would be great, but no... we must continue the Debug Logging after the failure occurs as well per customer requirements. The "Pause on Failure" only applies to the functional test sequence, not the "Constant Monitor" Data Logging (TDMS).

[Taki1999]

I'd try and push back on the customer requirement. If the functional test environment is anything like what I'm used to, unbounded growth of files is a bad idea.

As I mentioned before, I don't use the DAQmx logging feature. If I'm writing to TDMS, I'm using the DAQmx Read and a subsequent TDMS Write.

It is a bit of a workaround rather than a fix.

Another workaround would be to chop your acquisition into finite chunks instead of a continuous read. It doesn't surprise me that TDMS cleanup on a continuous Read Task doesn't happen until the continuous task is stopped.

[cpede]

After reading this I'm in doubt if I can use the build-in TDMS logging in DAQmx.

I call StartTask and then monitor data for a long period. This actually means that I do not call StopTask, but

was relying on this code:

// stop logging
DAQmxErrChk( DAQmxSetLoggingMode(m_taskHandle, DAQmx_Val_Off) );

But I have trouble reading the TDMS file because it is not released by DAQmx. So when is it released by DAQmx?

-cpede