how to properly time stamp

[kjs356]

I was using the get date/time in seconds, but I found that uses the pc clock I think (I am not really sure) and that is not very accurate.  I thought I could use the timestamp function, but I do not understand how that works. All I could figure out was how to get the current date and time. I don't know how to make it continue like a clock. Thanks for the help.

[JÞB]

All of the LabVIEW built in functions access the PC clock- and are not tracable to either civil time (Time of day) or time (SI second).  So an answer depends on what you need.

If you need to accurately log the time of day NIST maintains day-time servers that can be queried via the internet Any GPS reciever will also provide an accurate time of day.

For Time measurments (or frequency) you need a suitable stable oscillator.  How accurate? is the biggest question and drives what type of equipment your system needs.  A simple DAQ counter-timer my meet your needs if you are looking for low resolution but if you need Fempto-second accuracy you will need a pretty serious time standard.

[Adam_U]

You might consider the PXI-6682.

[tbob]

---

@kjs356 wrote:

. I don't know how to make it continue like a clock. Thanks for the help.

---

This vi will continuously display the date and time.  If you want just the time, like a digital clock, change the format string.  See the help function for how to build a format string.

 %H:%M:%S will display the time only in 24 hour format.

[kjs356]

Basically what I am doing is collecting data 10 times a second and time stamping them. The problem is I am connected to the internet ( and I need to be connected to the internet). Since the pc clock is a little fast after a while it will resync with the actual time through the internet and my time stamps will repeat. For example,

18.1sec

18.2

18.3

18.4

17.9

18.0

18.1

....

So I am trying to resolve this issue.

[Coq_Rouge]

Please post your code, but not as picture. Then we can have a look and see what we can do to help you. I think your problem is related to some Labview beginner problems. But do not worry about that. We have all been Labview beginner at some time 😉

[kjs356]

Here is the code. Your right. I'm new.

[JÞB]

NIST publishes a free application (nisttime-32bit.exe) available from Here Which resets your system clock to the correct time of day.  The same site also offers advice on how to set up a time service inside a corporate firewall. 

I've used the nisttime-32bit.exe app for several years and yes, you can call the app from LabVIEW using SystemExec.vi

[smercurio_fc]

---

@Jeff Bohrer wrote:

NIST publishes a free application (nisttime-32bit.exe) available from Here Which resets your system clock to the correct time of day.  The same site also offers advice on how to set up a time service inside a corporate firewall. 

I've used the nisttime-32bit.exe app for several years and yes, you can call the app from LabVIEW using SystemExec.vi

---

Based on the poster's response in message #5 it seems the computer already automatically updates the system time based on a time server, and this is the crux of the problem. His code runs along getting time, and then in the middle of it the clock adjusts itself.

Assuming what I said is accurate, then you could do one of two things:

• Force a time synchronization to occur at the beginning of your program and then turn off the synchronization programmatically.
• Keep track of time yourself. You can get the current tick count and time at the start of the program and simply keep track of the elapsed tick counts. You would have a start time that won't be affected by a time change, and you'd only be keeping track of tick counts. Of course, this would likely be affected by the "fast" clock you have, but it would be relative. If your duration isn't too long this should not have too much of an error.

[kjs356]

Yea i had thought about doing that. Though I think it still auto corrects when you turn off the syncing for some reason?? Maybe because I am still selecting a time zone and it keeps in sync with that. I am not sure, I might have looked at the wrong data so I am running another test now.