If you refer to the PI SDK Programming Reference (an easy way to access it from a machine with PI SDK installed is from "About PI-SDK" and click on "View Help"), you can find the description for UTCSeconds and UTCFileTime properties
PI SDK Programming Reference
UTCSeconds is a Read/Write property that exposes the time stored in the PITime object as a UTC time expressed as a double representing the number of seconds since 1970 UTC.
UTCFileTime is a Read/Write property that exposes the time stored in the PITime object as a UTC time expressed in the Win32 FileTime format.
Internally, PI stores timestamp as number of seconds from UTC time "1-Jan-1970 00:00:00", I guess you can say that UTCSeconds is closer to what is being stored in PI.
I understand that PI3 supports sub-seconds like 1265519413.8630012 or 1265519413.2010066. A double might not be able to represent a timestamp accurately. Is the UTCFileTime the better representation of a timestamp? The bottom line is I need to know which timestamp representation I can use to read and delete a data value at a specific timestamp.
PI3 does store timestamps in doubles and does support sub-second, to a minimum resolution of 15.26µs (up to 65535 values/second). As pre Han Yong's previous post, PI3 internally uses "seconds since 01-Jan-70 UTC" as its basis, therefore PITime.UTCSeconds is as close as you can get to the internal timestamp.
UTCFileTime gives the "FILETIME" representation of that timestamp: that is, the number of 100-nanosecond intervals since January 1, 1601 UTC.
Roger ChowWith that said, you should be able to read and delete values at specific timestamps, with any of these notations - LocalDate, UTCSeconds and UTCFileTime.
The bottom line is I need to know which timestamp representation I can use to read and delete a data value at a specific timestamp.
Please let us know if you come across any problem representing a specific timestamp and we'll try to sort this out.
Hope this helps!
I think I have come to a problem. I have some data from a SEL relay which records data every 0.00125 seconds for about 1.2 seconds. I write the value into my tag using the PISDK and I can see the timestamp is correct when I write it in, but different when I read it back out. The time written in is "2012/11/25T12:51:30.54825" (UTCSeconds = 1353801090.54825), but when I retrieve it using Processbook or PI-OLEDB Enterprise, I get "2012/11/25T12:51:30.54826". Is this what I should expect, or did I miss something?
1 of 1 people found this helpful
I'll take a shot in the dark at explaining perhaps why this is happening, though I don't know for sure. First let me correct Steve Pilon's post of 2010 where he said sub-seconds is up to 65535 values/second. This is wrong. Subseconds will vary from 0 to 65535 but if you count the 0 then you really have up to 65536 values/second.
For your UTCSeconds = 1353801090.54825, let's just focus on the subseconds portion 0.54825, which is an input time; this is not the saved PI time so let's examine (conjecture) what happens along the way. If you multiply 0.54825 subseconds by 65536, you get 35930.112. This is a floating point value and to store as a PI subsecond requires it to be a whole number value that aligns evenly with 65536. So I am guessing that PI takes the ceiling of 35930.112 rather than round up or down. If this is true, for your input time to be saved the subsecond slice will become 35931, or when divided by 65536 becomes 0.5482635498. That's what is saved to the PI server. And when you ask to display it with a certain number of decimal places, it becomes 0.54826.
Thank you for your response. So basically, we are running to the limit of the accuracy of the PI timestamp being stored. Funny that it uses ceiling rather than rounding, but I guess if it always uses ceiling, you won't have values trying to be stored with the same timestamp, which rounding up or down could cause. It also looks like when it brings the timestamp back it floors the timestamp.
Again, thank you for your response.
Subseconds will vary from 0 to 65535 but if you count the 0 then you really have up to 65536 values/second.
I like to confirm Rick is right here.