How can TDMS write generate error 4?

[andre.buurman@carya]

First of all, please review all information I posted.

The error string I posted shows that the error originated in TDMS Write, TDMS Write produced the call chain.

[isakbm]

Hi André,

After some more digging it appears that there has been a similar instance in the past, where a customer got error 4 at TDMS Write. In that case the user was deploying code on a cRIO, and storing TDMS files locally on the cRIO. Here's the issue and description paraphrased

---

The system creates a TDMS file as one of the initializing steps since creating it later when it is time to start saving the data, can cause error -2519 as the system doesn't have enough memory left to load the TDMS.dll (needed to create a file). However, this means that if the user starts the system, forgetting to clear the cRIO disk of old TDMS files, and thus ftp in and delete all the TDMS files that they can see on it, they are actually deleting the new file that the system will try to save data too later. So it errors out when it tries to save because the file it wants to save to doesn’t exist anymore. 

---

Perhaps your issue is similar, and also related to accidental deletion of initialized TDMS files?
Even if it's not directly similar, it might be worth while to know that memory issues and premature deletion or complications with the TDMS file itself can result in error 4 seemingly occurring in TDMS write.

If you provide us with a minimalistic example of the code that creates error 4 in TDMS write, then we can have a deeper dive into what might be the issue.

Best,

Isak

[andre.buurman@carya]

Hello Isak,

Thanks for the effort to dig up the case based on TDMS write.

Please find my example attached.

The code is placed in state "Process Train Passing".

It is called once per cycle: open file - write data - close file

Each file name is unique at seconds level: %s_<name>_%^<%Y%m%d_%H%M%S>T.tdms

File are sent remotely by:

- putting all unsent file paths in a send queue at system start

- putting the path of a newly generate file in the send queue for processing

The problem occurred after several hours of generating and sending file without problem. The send queue prevent the file sender from sending any file that is not available in the send queue.

[andre.buurman@carya]

Additional piece of info. There is only one function in the application that is generating TDMS files.

That function opens, write and closes the file. The function is not reentrant.

[isakbm]

Hi André,

I deployed the code you attached on a cRIO 9076 and it seems to work fine.

I see that you are making calls repeatedly to TDMS Open, it could be that this is where the error 4 is coming from. 
I found this thread where it has been documented to occur when using LabVIEW RT version less that 10.0. 

https://forums.ni.com/t5/LabVIEW/TDMS-Open-Causes-Error-4-or-2506-on-cRIO-if-Operation-quot-Open/td-...

What version of LabVIEW RT do you have on your target? 

Best,
Isak

[andre.buurman@carya]

BTW it's coded in LV 2017 (no SP1) (initial post)

The error call chain points explicitly to "TDMS Write"as source of the error.

The system that had the error is an NI 9065 Linux target.

[isakbm]

Hi André,

Sorry for the late reply, but it's because I haven't found anything useful so far it seems, despite my efforts.

I am considering escalating this if we are able to reproduce the error, but not before.
Let me know if you are able to reproduce the error.

[mpatientX]

We have seen this multiple times when writing to a TDMS file using a IC-3120 running linux. We use external USB drives and when it has been logging for an extended amount of time the TDMS Write.vi produces error 4: "10:22:18 PM UTC: RT Error 4 - TDMS Write in..."

We don't see a file on the drive after we see this error and if you try to create a new file and we've seen it happen over different files. If you try to reference the file that produced error 4 you get error 7 File Not Found once you stop the write. 

[bhpowell]

I also saw this today.  (End of file error while doing a TDMS Write.)

Is there any update on this issue?  Was it ever escalated to R&D?  I think it'd be worthwhile to do so, even if just to ask them to examine the code for obvious ways that something could go wrong and be reported as error 4.

Details:

* I'm not doing a repeated open/write/close.  Instead, I'm opening once, writing a bunch of times, then doing the close.  At some point (after logging many megabytes of data), I got error 4 from TDMS Write.

* This is on a PXI RT system, writing the file to the local hard disk.

* I'm using LabVIEW 2018.

[bhpowell]

I just got back onto the customer system to check a few things, so here's some additional data...

* The PXI RT system is running Pharlap 13.1

* The file size of the TDMS file was 4,194,176 kilobytes, which seems eerily close to 2^32 bytes.  Does Pharlap or TDMS have a file size limit of 4G?  If so, that may be my issue.  Is there a programming solution for handling this limit?

Thanks.