Use the search feature to view Kepware's repository of more than 500 Knowledge Base articles. Narrow your results or type your query into the search field below.

Alternatively, if you are unable to find a solution, we have an additional resource - our PTC eSupport Portal . If you are prompted to log into the eSupport Portal, you can use your My Kepware credentials. Need a My Kepware account? Create one here .

Search Solution Results By:
View All Solutions

Kepware Knowledge Base: Solution

The OPC Timestamp of a .Value Tag Reflects the .Timestamp Sub-type of the Point

Last Update: 3/18/2021

The OPC timestamp will be obtained from the DNP .Timestamp when present.

A valid DNP timestamp will only be received with an event update if the DNP server device is configured to supply an Event Poll, Unsolicited Message, or Class 1, 2, or 3 poll (which are caused by a client application writing to an Object 60 Tag). For those types of updates, the OPC timestamp of the .Value Tag will reflect the .Timestamp if the DNP server device delivered a valid timestamp with the update. For other types of updates (such as Integrity Poll or Explicit Reads), the .Timestamp will be reset to 0 (which may display as a date in 1899).

Explicit DNP reads done for the .Explicit sub-type do not affect the .Timestamp; however, in 4.x versions of the server, the driver will automatically do explicit reads for .Value items that are not returned in the device's response to an integrity poll. For example, an integrity poll and timestamp-bearing DNP update are being used for the same point. When an integrity poll shows that the point's value has changed since the last value received from the device, the .Value tag's OPC timestamp will be set to the time when the response to the integrity poll was received. When the next update comes in with a DNP timestamp, that DNP timestamp will again be put into the OPC timestamp.

Note: Since DNP explicit reads do not return a valid timestamp, the .Explicit Tag's OPC timestamp is handled differently from that of the .Value Tag.

If a non-zero .Timestamp field's displayed output is incorrect, it is most likely due to the following:

  • The Display DNP .Timestamp setting (located in the DNP Advanced Settings tab of Device Properties) is set to UTC instead of Local Time (or vice versa). This device property was added in server version 4.280.435.0.
  • The OPC server computer setting (located in the Windows Date and Time control panel) specifies the wrong time zone. This setting matters because when the Display DNP .Timestamp parameter is set to Local Time, the DNP Driver must do a time zone conversion on the timestamp received from the device (because all times in DNP are expressed in UTC).

Note: Per the OPC DA specification, OPC timestamps are always in UTC. The OPC client must convert the timestamp to local time. If the .Timestamp field is non-zero (that is, if the date is not in 1899), but the OPC timestamp of the .Value Tag doesn't match the .Timestamp, it is most likely caused by one of the following:

  • The Display DNP .Timestamp setting (located in the DNP Advanced Settings tab of Device Properties) is set to UTC instead of Local Time.
  • The OPC Client computer is set to the wrong time zone.
  • The OPC Client and server computers are set to different time zones.

See Also: Does the OPC Timestamp Reflect the DNP Point's Event Time of Occurrence?