# Issues with DNP3 Driver reconnection **URL:** \ **Category:** Ignition\ **Tags:** ignition79, ignition80\ **Created:** [April 24, 2020, 8:41am UTC](https://forum.inductiveautomation.com/t/issues-with-dnp3-driver-reconnection/34187 "2020-04-24T08:41:48Z")\ **Posts on this page:** 1\ **Showing post:** 10
**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:** [August 30, 2023, 2:54am UTC](https://forum.inductiveautomation.com/t/issues-with-dnp3-driver-reconnection/34187/10 "2023-08-30T02:54:25Z")
Exciting to hear there will be a new DNP3 driver! It's our go-to for SEL RTAC to Ignition, at least until SEL/Codesys updates their OPC-UA metadata implementation _or_ we decide to take the 61850 plunge. Any chance the new driver will allow [bit-level DNP3 addressing](https://forum.inductiveautomation.com/t/bit-level-addressing-in-dnp3-possible/75175/1) similar to the Modbus implementation? Right now we have to pull in the register in as a counter and then break it apart into binary expression tags with `getBit()` which can be a performance drag. We haven't seen the specific bug mentioned here, but we have encountered two other DNP3 oddities in the past: - We route bitpacked registers from RTACs to Ignition as counter objects since we were getting floating point error even when the object type was an int. - A colleague was reminding me earlier today about how Ignition's DNP3 polling is all over the map in no discernable order - they are not clean requests to inspect in wireshark like we'd have from most other DNP3 devices. --- _[View the full topic](https://forum.inductiveautomation.com/t/issues-with-dnp3-driver-reconnection/34187)._