The PI Data Archive supports 1/65536th of a second, which is approximately 15.26 microseconds. This is commonly called PIPrecision. The legacy PI SDK and the PITime object would support this same precision. AF SDK, AFTime, and .NET's DateTime object also support this same precision.
That said, different PI tools have a more limited view. For instance, SMT and DataLink may limit the time to milliseconds. For DataLink, this is an Excel constraint. When working with Event Frames, which are stored in a SQL Server database, the constraint there is SQL Server and its datetime data type, which has 3.3 milliseconds of precision.
Here is a link to an old blog that I wrote when I was an OSIsoft employee:
Though it talks about it from a developers viewpoint, it does talk about how Event Frames have a precision of 3.3 milliseconds, which means that an AFTime or .NET DateTime may have its precision truncated when saving the event frame.
The PI Data Archive supports 1/65536th of a second, which is approximately 15.26 microseconds. This is commonly called PIPrecision. The legacy PI SDK and the PITime object would support this same precision. AF SDK, AFTime, and .NET's DateTime object also support this same precision.
That said, different PI tools have a more limited view. For instance, SMT and DataLink may limit the time to milliseconds. For DataLink, this is an Excel constraint. When working with Event Frames, which are stored in a SQL Server database, the constraint there is SQL Server and its datetime data type, which has 3.3 milliseconds of precision.
Here is a link to an old blog that I wrote when I was an OSIsoft employee:
Though it talks about it from a developers viewpoint, it does talk about how Event Frames have a precision of 3.3 milliseconds, which means that an AFTime or .NET DateTime may have its precision truncated when saving the event frame.
