TimeStamp miliseconds control in Labview

[markstab]

the question is about the miliseconds part of timestamp. It seems there is no way to control(write) directly the miliseconds part, also when read there is no ms part in the indicator. What is the structure of the time stamp record?Are there some way to write and read ms part (but without string conversion), as bytestream for example and use/write it as array?

[CoastalMaineBird]

If you typecast a TIMESTAMP value to a string, and display the string in HEX format, you'll see that it's four U32s.

The high-order one is stuck at zero.

The next one increments every second.

The third one increments much faster, but only has the high-order bits used.

I would guess that it's a fraction of a second, intended to be used as N/ (2^32). This allows for higher resolution uin the future (yeaahh!)

The fourth is stuck at zero, for even more future resolution.

If you typecast it to a cluster of four U32s - you can extract the parts yourself.

BTW, if you create an indicator from the Get Data/Time in Seconds function, it DOES have a millisecond part.

[markstab]

great, thanks for the precision help
I try also to convert timestamp to DBL and the result is: add one conversion but save 64bit for every record. I dont know what is beter. I have large amount of data, and the original problem was that the time info that is comming whit every record is up to seconds precision. Some events are occuring in one second so in the graph and analisys part they all are on one time point. I try to get all events in one second and add to every time stamp (or DBL) the corresponding 1/(number of events) seconds. About third and forth U32 here they show some numbers and may be as you say they both represent the decimal part (.123) of the number, the indicator realy has milisecond part, but in the time stamp control I cant manipulate i
t to add part of seconds.

[CoastalMaineBird]

I'm not sure what you're concerned about more, the storage space (TIMESTAMP = 128 bits) or the processing time (conversions).

If it's the storage space, you COULD sacrifice the extra range by typecasting to a cluster of four U32s (no conversion time), extracting #1 and #2 (discarding #0 and #3) and storing those two. That's assuming you can live with the overflow that will happen in the year 2040 or so.

Another trick you might consider is storing ONE timestamp value, and ONE mSec timer as a starting point, then store the mSec Timer (32 bits) with each record. When it's time to display a record, use the record's timer minus the starting timer as an elapsed-mSec value, and add that to the starting timestamp to get an absolute times
tamp for each record.

Be careful with that, though. The timestamp does not have mSec directly - it looks like field #2 is fractions of a second - so you'll have to convert one or the other to add them correctly.