While trying to convert DNP3 communications for an SEL-735 (Schweitzer Power Quality and Revenue Meter) device from using Explicit Reads (GVI syntax addressing) to either Event Based Polling or Event Based Unsolicited Messages I have come across an issue where the tag value is updating frequently but nothing is being added to tag history.
If I switch the tag Value Source from OPC to Memory and manually make changes then tag history is updated. If I switch the tag OPC Item Path to use a GVI syntax address then tag history is updated but when I switch the tag OPC Item Path to use the syntax required for Event Based Polling of Unsolicited Messaging then I see the tag value is getting updated but nothing is being added to tag History.
I have reduced the testing down to a single test tag using the device connection to eliminate other factors.
Ignition v8.1.45
Device: SEL-735
I'm hoping the forum can offer some suggestions on next steps or point me at findings from others with similar issues.
If you have both these things configured, add some logging to a tag change event script on that tag, log the full value, pay close attention to the timestamp.
A tag group is being used with Sampling Interval set to zero (0) and queue size set at a arbitrary large number. Is there anything else significant for the tag group settings? I find the terminology around "MonitoredItem" to be unclear in the manual. Tag Group:
I had not previously tried enabling Back-fill on the Tag Provider. But on your suggestion tried it and it did not change the behavior. Reading the description I don't think I want to leave it on as I'd rather the tags get processed sequentially.
Ah, I see it now. I had been focused on the timestamps relative to each other.
It appears the DNP connection is taking UTC timestamps from the device and recognizing them as Central time. Not sure how to correct that but you've given me an avenue to explore. Thanks!
For further troubleshooting, you can also enable Context Logging for a specific tag name that will increase logging for that specific tag and might give further insight into the decisions Ignition is making. This can be done by doing the following:
Navigate to Status > Logs
Click the gear to bring up the Log Configuration dialog
Click the Context tab
For Key enter: tag
For Value enter the tag name (not the path, just the name. For some reason we only support name which is a separate issue.)
For Set Level select: TRACE
Click Add Level button
This will enable TRACE logging for that specific tag name for all the important loggers related to tags including value changes and history logging.
You're now receiving events from the device, instead of explicitly reading each point, and events typically have a timestamp included with them. The device has to be configured with the correct time.
Yes, I expect you are correct.
I had foolishly thought that the Explicit Read operations previously used also had come with timestamps attached (perhaps not). I had also expected the device was previously being time synced, either through GPS IRIG or by syncing with the DNP master (Ignition).
Its interesting that the device does show the correct "local" time on various status pages when using its configuration tool (SEL AcSELerator).
I'm hunting for the correct status/settings, I'm not in these SEL devices that often.
The SEL-735 device is connected to a SEL-2407 Satellite-Synchronized Clock and every way that I have managed to query the SEL-735 device it appears to show correct time. More precisely is shows the local time (CST), without time zone indication.
My working theory is this...
Observation:
When the current real-world time is 2025-01-30 17:07:22 CST (UTC-6) SEL-735 Ignition shows the DNP events have timestamp 2025-01-30 11:07:22 CST (UTC-12).
Theory:
I suspect the SEL-735 device is timestamping the DNP events with local time (not UTC time), specifically Central time, CST, UTC-6 (six hours less than UTC).
I suspect the Ignition DNP3 driver is expecting UTC timestamps and when the CST timestamp is received Ignition treats it as though it is a UTC timestamp, this makes the event timestamp, as recognized by Ignition six hours off.
When ignition presents the event timestamp, which it thinks is a UTC timestamp it subtracts 6 hours to show the time as a CST timestamp. A UTC-12 timestamp being recognized/presented as a UTC-6 (CST) timestamp.
I did find a UTC_OFF setting in the SEL-735 which defines the offset between UTC and local time. Changing that had no effect on the DNP event timestamps recognized in Ignition.
However I just found that the manual states this... "The UTC_OFF setting defines the offset between UTC and local time, except when the time source is IRIG and the IRIG type (setting TSTYPE) is set to IEEE. If TSTYPE = IEEE, the meter uses the UTC offset hours from the IRIG control bits. In this case, the device requires IEEE C37.118 control bits to be included in the IRIG signal."
The DNP3 spec uses UTC for the DNP3 time base. All timestamps are transmitted in UTC, and all receiving applications expect UTC.
There's no room for misinterpreting the timestamp received from a DNP3 outstation because it's transmitted and received in UTC, but it's certainly possible that it's simply wrong before it's transmitted.
Yes, its unclear to me how this happens but I'm just following the clues in an admittedly unfamiliar area. I'm feeling quite certain the issue is upstream of Ignition. Right now I'm looking into the possible impact of misconfigured dip switch settings on the SEL-2407 Satellite-Synchronized Clock as I suspect something odd is happening where the SEL-2407 is synching time to the SEL-735 and for some unknown reason the SEL-735 is interpreting local time (UTC-6) as being UTC time and timestamping DNP events with a UTC timestamp that is six hours off from what it should be.
