Hi Mark, at the time during the Beta testing it was not possible to sync these times. However further into the testing a Time Sync function was added that triggers a time sync to the RTU. The new released driver has this Time Sync function that seems to work as expected. These are outlined in the documentation.
@markphillips
@Nicholas_Rodgers
In the current release, the driver will automatically sync time when the NEED_TIME bit it set by the outstation. There's also the system.dnp.synchronizeTime() function.
I also just merged a new setting that allows the automatic time sync function to be disabled...
1 Like
Do you have any documentation on the NEED_TIME bit?
It's one of the Internal Indicator (IIN) bits defined by the DNP3 spec. They are included in every response header from the outstation.
The outstation sets the NEED_TIME bit (IIN1.4) when it requires time synchronization from the master.
1 Like
Found it, thanks again for the help.
How do I disable the automatic time sync?
That just got merged, itâll be in the latest nightly release if available.
edit:
2 Likes
Looks like an AcRTAC snippet. Glad to know others are testing the new DNP3 driver with RTAC.
Do we have any updates on a possible release for this patch? We are experiencing mission critical DNP3 failures and this patch hasn't shown up in the latest releases (nor on the nightly for .40).
Thanks!
If you're talking about the ability to disable automatic time sync, that was released in v8.1.39:
Also listed in the nightly release notes that @Kevin.Herron linked to above also.
Are you sure you are using the new driver?
What is the "gvi" (group, variation, index) format that can be used in the OPC Item Path property of an OPC tag with the new DNP3 driver?
This "gvi" formatted OPC Item Path (with parameter binding) works under the legacy DNP3 driver but does not work for the new one.
ns=1;s=[{Device Name}]AnalogInput:22:g30v5i22
This revised non-gvi format works with the new driver...
ns=1;s=[{Device Name}]AnalogInput22
...but I am developing a transition path from the old driver to the new driver and am looking to keep our "gvi" formatted OPC Item Paths, at least initially.
These trial and error attempts also failed.
ns=1;s=[{Device Name}]AnalogInput22:g30v5i22
ns=1;s=[{Device Name}]AnalogInput22.g30v5i22
The gvi format for the new driver does not appear to be documented at all. To be fair it was not documented for the legacy driver either but at least could be discovered by looking at the results of the device browser or quick client.
1 Like
I figured it out. This works:
ns=1;s=[{Device Name}]g30v5i22
I had always included the AnalogInput portion with the legacy dnp3 driver as that was what was returned with the device browser or quick client. Apparently not needed for the new driver, perhaps not needed for the old one either (might have to test and see).
2 Likes
I always wondered what that string was for with the legacy driver, since I also created my tags via OPC-UA browse before I parameterized them. I tried the new driver and couldn't get it to work with existing addressing in our UDTs (and didn't have time to troubleshoot when the old one works) but this is inspiring me to give the new driver a fresh try.
1 Like
If you're going to try the new driver I'd encourage you to go all the way and stop using the "gvi" syntax and instead use the syntax you see when dragging tags in from the browse, which will result in data being acquired by either class-based event polling or unsolicited messaging, depending on your configuration. "gvi" syntax is how you retain the legacy polling based behavior that just uses the DNP3 READ function over and over like other protocols.
1 Like
I've finally started testing the new driver and have run into an issue of how OctetString points are displayed as tags. With the legacy driver, an OctetString point could be configured as a string and the hex bytes would be converted to ASCII characters. With the new driver, OctetStrings are converted to an array of Shorts. For example:
OctetString value: 454d505459
Legacy Driver
String:"EMPTY"
New Driver
Short Array: [69, 77, 80, 84, 89]
String: "[69, 77, 80, 84, 89]"
Has anyone else seen this behavior?
It was an intentional modeling choice to give you an actual byte (unsigned, so upsized to signed short) array, although perhaps not the right one. OPC UA has a built-in datatype, ByteString, that is conceptually and semantically the same thing as a DNP3 OctetString, so that's what was used.
It wasn't clear what anybody was even using or doing with the octet string in either format. Presumably something in a script, which would just need to be modified with the understanding that you now have an array of the byte values rather than a string representation.
Thanks for the reply, that makes sense. In our use case, the device sends string values (hostname, mac, hardware/software versions) as OctetStrings that we display in the application. We'll just have to add expression tags to convert back to Strings
Feature request: An option to use the DNP3 timestamp metadata instead of the gateway timestamp..
Goal is history timestamps sourced from the source device and not subject to potential time issues from our gateway (whether system time issues with NTP, clock drift, buffering, etc.)
We do use the DNP3 timestamp any time it's available.
2 Likes