TDMS data unreadable due to windows language settings??

[JeroenBK]

Hello,

I have a strange issue. We have an executable created from Labview to run tests and create a pdf report from that test. This exe is installed on about 30 to 40 computers and with one I have an issue. In short the way we work:

1. We create a tdms file and fill it with information.
2. Now we start a test and enter the data into the same tdms. We close the tdms afterwards.
3. We open the tdms to create a report, hereby the information entered in step 1 is used to select the correct test and to be displayed in the program.
4. Now the program wants to get the data to create graphs from it and it ends with an error (20312).

I've been checking a lot of things, like read/write issues but that is not the case. The only difference I could find so far is the date in Windows language settings. But I sure hope that will not be the issue!

Anybody ever had similar issues and/or a solution to this?

UPDATE 1: I store the data (waveform) with a t0 defined as 00:00:00.000 DD-MM-YYYY, and I use that same format to read the data. Is it possible that the windows settings influence this definition in the tdms?

With kind regards,

Jeroen

[RavensFan]

What is the  language setting that was causing you a problem?

It could definitely cause issues.  If your file has the format you show with the decimal point for the decimal point, but the PC is set for a language that uses a "decimal comma", I could see problems.

[Artem.SPb]

Are you using non-english ("unicode") symbols?
If yes, try english-only or change settings as here https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019NYmSAM&l=en-US

Also (about date), it possible if reading VI get "system date format" instead of scan by exact form or different PC has different (dot-comma) decimal point

[JeroenBK]

Hello RavensFan,

I've checked that part and it is the same for both my pc and the "faulty" one, the only difference is that on the faulty pc the date is stated as mm/dd/yyyy and the time is in AM/PM format.

[JeroenBK]

Hello Artem,

No I don't use non-english, especially not within the data/waveform.

How can I check whether a VI is getting system settings or something else?

I create/work on a PC with the Dutch settings, the faulty pc has US settings (location is Saudi Arabia). However we also have users in Norway and Canada they have no issues.

[Artem.SPb]

First of all try change "Dutch settings" to "english" settings. As you wrote in previous post, "normal" date is mm/dd/yyyy.
And the "Dutch" PC can has d.m.y or something else.
Also make simple example and send it to us, it will be easier to help you.

[JeroenBK]

Hello Artem,

The issue is not with the "Dutch" PC, the only one is the one in Saudi. So it seems to be contra-productive to change my pc to the settings of the faulty one. About the example, I have to investigate where the issue is really happening and that is a problem because I have to do it with a teamviewer connection and only the executable on the remote pc.

I will probably need to build a special exe in which I display the content of the data array. Then try to work from there.

[Kevin_Price]

You said that the "t0" is from a waveform, which would make it a well-defined 128-bit timestamp datatype.  However, much of the conversation sounds like it's talking about date / time *string* formats.

How are these times stored, as strings or as actual timestamp types? 

(Back in the early days of TDMS, I stored time info in a string-based format.  Timestamps and waveforms weren't yet supported and during all my testing the string converted back and forth just fine.   But later, I got bit by Daylight Savings time when the same data file would report different timestamps depending on which PC was used to read it or what time of year the reading was done.

   The lesson: store time information as timestamps when possible, otherwise as doubles using LV's standard meaning of "seconds since 00:00:00 Jan 1 1904".) 

-Kevin P

[JeroenBK]

Hello Kevin,

All the times are stored in a timestamp datatype, however when I look into the cluster storing this information the properties of the datatype say "System time format" (see attached image). Should that be changed to a fixed value?

[Kevin_Price]

Just to be very precise and clear:

Those are *not* properties of the timestamp datatype itself.  They are *display* properties for a timestamp *indicator*.   The timestamp data that feeds these indicators (or which can be queried with a "Read" local variable) will *not* be affected by changes to the display properties of the indicators.

I don't find a lot online about the 20312 error (actually, I expect it might be a -20312 error).  There are some indications that's an error code range used by LabVIEW analysis vi's.

Have you traced down the source of that error within the post-processing code?  Do you get it always or sometimes?  Have you confirmed that the data file itself is ok, i.e., have you tried opening the same file on one of your other PC's that doesn't show errors when opening its own files?

-Kevin P