Time Stamp Irregularities

[Gizmaa]

Labview: 8.2

Hardware: cFP-2120 (Compact Fieldpoint)

I have an embedded data collection VI which is collecting a line of data once every 5 seconds. When the VI starts it synchronizes the Fieldpoint's time with a NIST time server. Up to this point it has been spot on with UTC time.

Recently the data has introduced gaps in certain areas and sample rates of twice the rate expected. When I looked at the data I discovered certain segments of the data were time shifted so they overlapped with other data files. The odd thing is that it was only certain segments and not consistently biased.

Here's a screenshot of the time stamp generating script.

What could be causing the problem?

Jeremy

[kellis.wiseman]

Hi Jeremy, 

I am sorry to hear that you are having trouble with this. I would like to find out more about your application, to provide more meaningful and immediately applicable suggestions. Are you using variables to communicate the data from the FieldPoint to a host computer? Are you using Real-Time, or are you using FieldPoint with regular LabVIEW? Once you have the timestamp from the code you posted, do you use that as an initial time, and add 5 seconds to the time stamp with every read, or do you constantly acquire time from the NIST time server as data is acquired?

Thank in advance for your answers. I am sure we can get this resolved.

~kgarrett

[Gizmaa]

The time synchronization with NIST is only done once, when the VI starts. The time stamp is acquired from the Fieldpoint for every cycle.

The VI itself is embedded on the cFP-2120 Compact Fieldpoint so yes, I am using Real-Time.

The data is saved in a text file to a compact flash card or the internal storage on the Fieldpoint.

Thanks for taking a look at the problem.

[kellis.wiseman]

Thank you for your response, Jeremy. The reason I asked about Real-Time, and if you were using variables is that there are some options to enable timestamps inherent to both that OS and those communication methods. However, if you are simply writing to the onboard flash, that eliminates both of those alternatives.

 As far as I can tell, there seems to be nothing wrong with the code you are using for generating the timestamp. That being said, the behavior you are seeing could be due to the VI not being successfully run with each iteration of data acquisition, or the VI losing its connection to the NIST server (and therefore maintaining the last known value, and therefore the same timestamp as the previous iteration).

You said that up to this point, the time has been spot on with the UTC. Has anything changed since then that might result in either of these two scenarios? Thanks!

~kgarrett

[Gizmaa]

As far as I can tell the Fieldpoint shouldn't be over taxed computationally. Here's a screenshot of the code.

[kellis.wiseman]

Hi Gizmaa, 

From just looking at your code, I do not see any immediately obvious issues. How are you checking the available memory on the FieldPoint (I can see the subVI, but not what you are doing inside of it)? Also, has anything changed in your setup since the last time this ran without the undesired behavior you are currently experiencing? 

~kgarrett

[Gizmaa]

No changes, it's been running continuously for some time. 

[Gizmaa]

[Gizmaa · Accepted solution]

I think I may have found the problem but I'm still not sure why it would happens. There are two datalogging VIs running at the same time and independently of each other. Each VI records data to its own text file. Once a file reaches 10 MB in size the VI synchronizes time with NIST and creates a new file.

For some reason whenever one VI cycles and syncs with NIST the other VI's time stamp is offset by a day. Why would this be the case?

I have modified the VIs so they only synchronize with NIST at the startup of the VI and not every time a new file is created. If the error is going to come up again it'll be another day or so before the data files reach their 10 MB limit.

[kellis.wiseman]

Hi Gizmaa, 

I'm not sure what would make it offset by a day. Is it exactly 24 hour offset, or roughly? Please let me know if that fixes the issue, or if you still are experiencing that behavior. Thanks!

~kgarrett