# New DNP3 Driver Beta **URL:** \ **Category:** Ignition Early Access\ **Created:** [October 20, 2023, 4:18pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774 "2023-10-20T16:18:10Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Nicholas\_Rodgers](https://avatars.discourse-cdn.com/v4/letter/n/77aa72/32.png) [@Nicholas\_Rodgers](https://forum.inductiveautomation.com/u/Nicholas_Rodgers)\ **Post date:** [March 3, 2024, 11:51pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/81 "2024-03-03T23:51:23Z")
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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 4, 2024, 12:03am UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/82 "2024-03-04T00:03:30Z")
@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... ---
**Author:** ![markphillips](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/markphillips/32/42086_2.png) [@markphillips](https://forum.inductiveautomation.com/u/markphillips)\ **Post date:** [March 4, 2024, 1:13pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/83 "2024-03-04T13:13:11Z")
> [@Kevin.Herron](#): > > NEED\_TIME Do you have any documentation on the NEED\_TIME bit? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 4, 2024, 1:41pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/84 "2024-03-04T13:41:01Z")
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. ---
**Author:** ![markphillips](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/markphillips/32/42086_2.png) [@markphillips](https://forum.inductiveautomation.com/u/markphillips)\ **Post date:** [March 4, 2024, 2:48pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/85 "2024-03-04T14:48:08Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/b/d/bddfe31931e1481c809a331d6ba038db701d31a8.png) Found it, thanks again for the help. ---
**Author:** ![markphillips](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/markphillips/32/42086_2.png) [@markphillips](https://forum.inductiveautomation.com/u/markphillips)\ **Post date:** [March 4, 2024, 3:24pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/86 "2024-03-04T15:24:23Z")
How do I disable the automatic time sync? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [March 4, 2024, 3:25pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/87 "2024-03-04T15:25:30Z")
That just got merged, it’ll be in the latest nightly release if available. edit: > [@Nightly 8.1 Changelogs - 2024](https://forum.inductiveautomation.com/t/nightly-8-1-changelogs-2024/83608/40): > > Nightly Changelog: 8.1.39-SNAPSHOT-b20240229 Comms Drivers IGN-9298: DNP3: Add a Setting to Disable Automatic Time Sync Added a setting to disable automatic time synchronization. IGN-9291: DNP3: Configurable Delay Before Issuing Read-After-Write After Operate Added settings that allow a configurable delay before issuing read-after-operate commands. Scripting Scripting IGN-9309: Relax PyArgParser to allow integers to be passed for boolean arguments Improved argument handling in some functio… ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [March 5, 2024, 5:19pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/88 "2024-03-05T17:19:38Z")
Looks like an AcRTAC snippet. Glad to know others are testing the new DNP3 driver with RTAC. ---
**Author:** ![Ben\_Walker](https://avatars.discourse-cdn.com/v4/letter/b/278dde/32.png) [@Ben\_Walker](https://forum.inductiveautomation.com/u/Ben_Walker)\ **Post date:** [May 13, 2024, 7:34pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/89 "2024-05-13T19:34:31Z")
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! ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [May 13, 2024, 7:39pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/90 "2024-05-13T19:39:22Z")
If you're talking about the ability to disable automatic time sync, that was released in v8.1.39: > **[Ignition Release Notes for Version 8.1.39 | Inductive Automation](https://inductiveautomation.com/downloads/releasenotes/8.1.39)** > > Fixes, changes and features in Ignition 8.1.39 Also listed in the nightly release notes that @Kevin.Herron linked to above also. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [May 13, 2024, 7:45pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/91 "2024-05-13T19:45:53Z")
Are you sure you are using the new driver? ---
**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\ **Post date:** [May 31, 2024, 11:45pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/92 "2024-05-31T23:45:39Z")
> [@Kevin.Herron](#): > > The "gvi" syntax is also supported, e.g. `g30v2i0`, but any tag addressed in this manner will be read explicitly using the DNP3 READ function call. 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. ---
**Author:** ![tyler.bennett](https://avatars.discourse-cdn.com/v4/letter/t/f04885/32.png) [@tyler.bennett](https://forum.inductiveautomation.com/u/tyler.bennett)\ **Post date:** [May 31, 2024, 11:54pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/93 "2024-05-31T23:54:21Z")
> [@tyler.bennett](#): > > 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? 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). ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [June 13, 2024, 10:08pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/94 "2024-06-13T22:08:14Z")
> [@tyler.bennett](#): > > 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. 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. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [June 14, 2024, 12:14am UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/95 "2024-06-14T00:14:00Z")
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. ---
**Author:** ![jreynolds1](https://avatars.discourse-cdn.com/v4/letter/j/df788c/32.png) [@jreynolds1](https://forum.inductiveautomation.com/u/jreynolds1)\ **Post date:** [August 14, 2024, 9:38pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/96 "2024-08-14T21:38:46Z")
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? ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 14, 2024, 9:41pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/97 "2024-08-14T21:41:29Z")
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. ---
**Author:** ![jreynolds1](https://avatars.discourse-cdn.com/v4/letter/j/df788c/32.png) [@jreynolds1](https://forum.inductiveautomation.com/u/jreynolds1)\ **Post date:** [August 15, 2024, 4:16pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/98 "2024-08-15T16:16:57Z")
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 ---
**Author:** ![msteele](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/msteele/32/77889_2.png) [@msteele](https://forum.inductiveautomation.com/u/msteele)\ **Post date:** [September 18, 2024, 5:49pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/99 "2024-09-18T17:49:30Z")
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.) ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [September 18, 2024, 6:25pm UTC](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774/100 "2024-09-18T18:25:43Z")
We do use the DNP3 timestamp any time it's available. [Previous page](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774.md?page=4) [Next page](https://forum.inductiveautomation.com/t/new-dnp3-driver-beta/80774.md?page=6)