Get Date\Time Function - Unexpected Outputs

[dcj_]

Hello,

I am tasked with writing a program that reads data from a scale (serial port communication), then writes the weight, relative time, and timestamps to a .tdms file of my choosing. I use a subVI to write the weight, relative time, and timestamp to two different group in the .tdms file(One group has channels for weight and relative time, the other group only has the channel for the timestamps.). The inputs to this subVI are weight and .tdms filename. There are no outputs. The subVI should terminate after the the timestamp, weight, and relative time are written to the .tdms file. It is attached, named "write_tdms.vi".

I have had no issues with this program in the multiple tests I've run. These tests have been up to 96 hours long, and at sample rates as low as 2 Hz. The largest number of data points accurately collected was 89600. Last weekend, I started two tests about 9 minutes apart. They were scheduled to run for 72 hours at 0.2 Hz (sample every 5 sec). An error was discovered after the 33890th recorded timestamp in both tests (9 minutes apart). From the 33891st to the 91079th index in both .tdms files, incorrect/incompatible timestamp values were recorded. See attached "Labview_Timestamp_error.JPG" for a screenshot of the start of the issue. Please note that most of, but not all of, the incorrect/incompatible (#####...###) timestamps have the same value. It is important to note that the weight and relative time are written to the .tdms file immediately after the timestamps, and only 33889 values were recorded for each of these (1 less than the timestamps). I believe this suggests that the subVI became "stuck" at the point where the timestamps are written to the .tdms file... but I do not know why, how, or if that is correct.

Other things to note:

- the .tdms files were being written to a folder in a company network drive. 

- the rest of the labview code continued running as expected. 

- 91079 data points is significantly larger than the expected number of 51,840 (# samples taken over 72 hours at 0.2 Hz)

           - 57189 incorrect\incompatible date\times were recorded

- Some dates recorded were prior to 01JAN1904 00:00:00 UTC, suggesting a negative value calculated by the Get Date\Time in Seconds function.

Any suggestions as to why this happened, or work-arounds to prevent it from happening again, would be greatly appreciated! 

[altenbach]

What program is used to display the data in the jpg file? Is it possible to make the column a little bit wider?

Are you sure that all participants use the same epoch?

[dcj_]

Hi Altenbach,

1. The program used to display the data is the excel, using the TDM plug in from NI. The issue was originally  discovered by MATLAB's tdmsread() function, where the data could not be loaded due to the invalid data types in the TimeStamps section. The data can be viewed in excel. Making the column wider simply extends the '#####' to fit the width of the cell. Hovering over these '###' strings prompts the cursor display to read "Dates and times that are negative or too large show as #####." From that, I think these values were not able to be recorded in the date\time format, and create errors for analysis programs.

2. The same epoch should've been used, as it was run simultaneously on the same computer. (From my understanding the Get Date\Time In Seconds calculates based on the systems epoch). I'm new to LabVIEW so I could certainly be wrong. 

Thank you for your quick reply!

[altenbach]

No, LabVIEW uses a different epoch (1 January 1904) that excel (0 January  1900). Not sure if the plugin or tdms tools do any translation.

[dcj_]

In that case, I'm confident the tdms tool / excel do not do any additional translation. I've been able to use this tool and MATLAB to accurately display date\times before. The fact that MATLAB is also unable to load the date\times accurately in this instance suggests, to me, that the output written to the .tdms file is the issue. 

[mcduff]

Not sure what is causing the error, but maybe trying writing the data all at once. (Guessing it is the dynamic data type) You will need to convert from Epoch time.(See Below) Also recommend not writing a single set of points at a time, not shown, write multiple values at once.