How to use TDMS Advanced functions properly

[MemoryGrowth]

Thanks for the link, Eric_NI. The thing is, we were able to just copy any TDMS file from the RT target's FTP folder to this desktop and open it while it is not closed when we were using normal TDMS functions but now we cannot do that with TDMS Advanced functions. Is the conclusion that this inconvenience is supposed to come only with TDMS Advanced? We intend to run the system 24/7 and TDMS files should be closed and newly created only once a day ideally. What we need is quick checks on any TDMS files anytime we want. We had this nice freedom before. We can programmatically open TDMS files with TDMS Advanced Read but that's not as free and convenient as just being able to open the files with Excel or DIAdem like we used to.

By the way, I found something weird from these TDMS Advanced examples from NI:

TDMS Advanced - Synchronously Write.vi

TDMS Advanced - Synchronously Read.vi

I ran the Write VI first and it created a TDMS file named TDMS_Advanced_Synchronously_Write. In that file, there are two channels with 512 elements for each. Now, if I read this file using the Read VI, I get weird results.

In TDMS Set Next Read Position, the offset is set at 128 and the selected channel is 1. The graph should display 512 - 128 = 384 elements from channel 1 but it shows 384 * 2 = 768 points. If I change channel 1 to 2, only the first element disappears and it displays 767 elements. I found the following is how the read function actually works, which may not be orignally intended. The numbers indicate the reading sequences. It reads data horizontally!

For a workaround, we set the channel to the first column for TDMS Set Next Read Position. Then, we convert the 2D array into a 1D array and use Decimate 1D Array to read the data with steps. To choose different channels, we use a Case Structure. It works but it's very tedious especially if there are many channels and I'm concerned about efficiency.

I attach my testing VI for your reference. Please bear in mind that there are some unnecessary things because it's just a testing VI.

[deppSu]

Hi,

Unlike "TDMS Read" node, "TDMS Advanced Synchronous/Asynchronous Read" node doesn't read by channels.

After you use "TDMS Set Next Read Position" to locate to a certan sample position of a specified channel, "TDMS Advanced Synchronous/Asynchronous Read" will read continueous data in TDMS file just like binary read.

By the way, you can still use "TDMS Open" and "TDMS Read" nodes to replay a file produced by TDMS Advanced API.

[MemoryGrowth]

Thanks for the tip, deppSu. I will check on how they work together, memory performance-wise.

As for the last attached VI, it would be easier to just manipulate the channel name for TDMS Set Next Read Position without using the Case Structure (only using the first output terminal of the Decimate 1D Array). I can't still programmatically change the number of terminals (which is the step size, n) of the Decimate 1D Array though.

[MemoryGrowth]

In fact, in order to avoid any hard coding, we can just use a For Loop instead of the Decimate 1D Array function. 

 

---

deppSu wrote:

By the way, you can still use "TDMS Open" and "TDMS Read" nodes to replay a file produced by TDMS Advanced API.

---

To do this, it seems we have to close the file reference with TDMS Advanced Close first after writing and re-open it using TDMS Open and read it with TDMS Read. We will have to close the file too frequently for a real-time reader then. This will probably cause a performance issue in our real application that's writing lots of data 24/7.

[MemoryGrowth]

This data processing + logging module keeps crashing after several hours of operation. Last time, it crashed after almost 9 hours. The time it takes to crash isn't very consistent. I need to run it 24/7. TDMS files are closed and created once each day.

The program writes to 4 TDMS files. 7 columns for 3 TDMS files and 11 columns for one TDMS file. In the current settings, it writes 5 data points for each column every second.

When I disabled the TDMS writing part (TDMS Set Properties & TDMS Advanced Synchronous Write) as in the following block diagram, it could run for days without any trouble. Therefore, the culprit must be the writing part. Is there any known issue with TDMS Advanced Write or can you find any bad coding practice that may cause the crash?

[deppSu]

Can you post the VI that can reproduce this issue, thus we can look into it and try to find out a solution.

[MemoryGrowth]

---

@deppSu wrote:

Can you post the VI that can reproduce this issue, thus we can look into it and try to find out a solution.

---

Thanks for the offer but I can't post it here because it's a big program that belongs to the company.

[MemoryGrowth]

Here's one thing I forgot to mention. Even with the whole TDMS writing part, I was able to run the program for days with no crash. The difference was the save interval. I tried 1 second save interval, which means 1 data point per column per second unlike 5 data points per second (0.2 sec save interval) in the usual setup. 0.2 sec save interval doesn't mean the program literally saves data every 0.2 sec though. The entire loop iteration rate is fixed at 1 second. It just means that from the acquired data array (for one second) from the DMA FIFO, it will extract 5 values and save them every second as if those numbers have been saved every 0.2 sec. If the save interval is longer than 1 second (3 seconds for example), it will keep the previous values using the feedback nodes so that it can save 1 value per 3 seconds (per column). When the save interval is longer than or equal to 1 second, it uses the True case shown below.

[Eric_NI]

Hi MemoryGrowth,

I noticed that there is no error handling in your VI, and the way it is wired seems to be a SubVI, I would recommend having an error wire to determine were the error is and what it is about. You can also check the following link that may give you another way to handle TDMS functions as SubVIs.

https://decibel.ni.com/content/docs/DOC-10543

If you are receiving an error code you can do a search with the wording of the error and that may return interesting results that can lead to a solution.

Best Regards,

Eric NI

[deppSu]

Looks like the logging for 4 TDMS files is concurrent, have you tried wire the logging VIs sequentially?