topic Re: Time Stamp Irregularities in FieldPoint Family

Time Stamp Irregularities

Gizmaa — Thu, 11 Aug 2011 18:31:07 GMT

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

Re: Time Stamp Irregularities

kellis.wiseman — Fri, 12 Aug 2011 20:33:09 GMT

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

Re: Time Stamp Irregularities

Gizmaa — Fri, 12 Aug 2011 20:39:29 GMT

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.

Re: Time Stamp Irregularities

kellis.wiseman — Fri, 12 Aug 2011 21:40:00 GMT

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

Re: Time Stamp Irregularities

Gizmaa — Mon, 15 Aug 2011 21:12:20 GMT

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

Re: Time Stamp Irregularities

kellis.wiseman — Tue, 16 Aug 2011 18:42:59 GMT

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

Re: Time Stamp Irregularities

Gizmaa — Tue, 16 Aug 2011 19:13:57 GMT

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

Re: Time Stamp Irregularities

Gizmaa — Tue, 16 Aug 2011 19:22:46 GMT

Re: Time Stamp Irregularities

Gizmaa — Thu, 18 Aug 2011 15:04:46 GMT

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.

Re: Time Stamp Irregularities

kellis.wiseman — Thu, 18 Aug 2011 17:52:33 GMT

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

Re: Time Stamp Irregularities

Gizmaa — Thu, 18 Aug 2011 18:12:21 GMT

Exactly 24 hours. The DDOY VI sends out the current time in our custom format. Fortunately it's made it easy to manually fix.

YYYYDDDHHMMSS.S

YYY = Year

DDD = Day Of Year

HH = Hour

MM = Minute

SS.S = Seconds to a fraction of a second

Re: Time Stamp Irregularities

kellis.wiseman — Fri, 19 Aug 2011 22:17:34 GMT

Hi Gizma,

Some NIST servers are configured to lock you out when you query too quickly from the same IP address. Try using a different server. If you still get the same behavior, try querying the server by two VIs on your host computer (making sure that the two VIs query close to the same time). If you get the same behavior, then the issue is with the server.

~kgarrett

Re: Time Stamp Irregularities

Gizmaa — Mon, 22 Aug 2011 16:32:27 GMT

The most my VIs sync with NIST is twice every two days and the move one can request a time sync is once every four seconds.

My alterations seemed to have worked though. New files were created and the time values have been consistent so far. If irregularities crop up again I'll add an update.

Re: Time Stamp Irregularities

kellis.wiseman — Tue, 23 Aug 2011 21:12:09 GMT

Hey Gizma,

Thanks for the update. If you would please, tag the post where you described your alterations as the solution to this post so other readers may see what you did to fix the issue. If you have any further issues, please post back. Thanks!

~kgarrett