LabVIEW programming topics - ms resolution timestamp
The timestamp related functions in LabVIEW generate a timestamp with a 15.625 ms time step. The clocktick related functions generate a number of clockticks with a 1 ms time step.
If a timestamp with a higher resolution is required, can both functions be combined? It appears it can! The timestamp variable can hold other values than set by the 15.625 time step. This page describes a module that combines timestamps with clockticks.
The idea is to catch an initial timestamp together with an initial clockticks# (number of clockticks). Each time a new timestamp is required, just read the new clockticks# and subtract the initial clockticks# and then add the difference (divided by 1000 going from milliseconds to seconds) to the initial timestamp.
Unfortunately the clockticks# goes up to 2^32 - 1 and then wraps back to 0. That could take anyting between 1 ms and about 49.7 days to occur. But when it occurs the clockticks# goes downwards instead of upwards. This would make time go backwards which obviously is not the case in most laboratory experiments.
If the current clockticks# has gone past the 2^32 - 1 barrier then the clockticks# running since the initial clockticks# can be calculated as follows:
clockticks# running = ((2^32 -1) - initial clockticks#) + current clockticks# If the current clockticks# passes the initial clockticks# again a 49.7 day cycle has gone by. At that point an additional 429496.7296 (number of seconds equal to 2^32 milliseconds) must be added to the timestamp to get an accurate value. But who needs ms resolution in a monthlong experiment anyhow?
The following images demonstrate how to calculate the proper number of seconds to add to the initial timestamp:
Scene 1 shows simple addition where the clockticks# has increased compared to the initial clockticks#
Scene 2 shows the abovementioned solution if the clockticks# has passed the 2^32 - 1 barrier
Scene 3 shows what if the clockticks# passes the initial clockticks# again
The following files were created with LabVIEW 8.5. You might need to do something similar to right-mouse-click and 'Save Link As...' to download these files.
timing seconds to add.vi
This is the vi that calculates the time to add to the initial timestamp.
This vi is a module that stores the initial (or previous) values required to calculate the ms timestamp.
This vi demonstrates how the normal timestamp goes up in 15.625 ms steps and how to use the module.
I thank Paul Rijkers for pointing out the 15.625 ms issue.
the timestep may vary for different computer systems (e.g. 15.625 for Dell Optiplex 745 / Windows XP)
sleep or hibernate mode may significantly disrupt this approach
Knowing that timestamp variables can hold a higher precision time, Paul Rijkers devolped an alternative set of vis.
the ms timestamp function doesn't need to be initialized
the timestamps of independant programs are correlated (as long as Init_msTimeStamp.vi keeps running)
The core vi (Get_msTimeStamp.vi) provides an easy solution to the problem that occurs after about 50 days. After each call it just makes the intial time equal to the current time.
The support vis (Launch_msTimestamping.vi and Init_msTimeStamp.vi) provide a way to initialize and occasionally call the core vi. This has the following advantages for other programs that need the ms timestamp:
This zip file contains the project file and the library file with the abovementioned vis. These vis were created with LabVIEW 8.2.
A discussion on Sub-millisecond timestamp, A better tick count [LAVA] suggests something very simple: subtracting two U32's (clockticks#) returns the right answer even if the clockticks# has gone passed the 2^32 - 1 barrier.
Together with Paul's solution this could lead to the following single scene solution:
or rather this implementation for the 'get time' action of the timing.vi:
This vi is a simple and concise program that produces ms timestamps. This vi was created with LabVIEW 8.2.
Bart Boshuizen, 2009/02/05