DNP3 Status Flags

Hi Guys,

Ignition Version: 8.1.25 running on windows server 2022.
RTU Device: Brodersen RTU32M (

Background: I have a RTU that is acting as a DNP3 slave device. I have a single binary input configured and I can successfully read this bit in Ignition. So far so good.
From the RTU documentation it says "The DNP3 protocol handles the time stamps and the following status bits: ...." it goes on to list the status bits of which bit 0 has the description "user definable".

My issue: There is some related data for most of my tags that would be really useful if I could just "encode" it into this "user definable" status bit. This would be better rather than creating a another DNP3 point for this information. However I cannot see where this information comes in with ignition. I have selected the "WITH_FLAGS" in the ignition driver under the advanced properties but I don't see this information anywhere. I don't see anything in the ignition documentation about what "flags" it supports, just that there are flags.

I was hoping it would come in as a property of the tag but I don't see it:

I have looked through the documentation and there does not appear to be any DNP3 functions in the scripting language to "pull" this data. There are DNP3 related functions but nothing for pulling the "definable" status flags:

Here is my driver config showing that WITH_FLAGS has been set:

Is this a thing with DNP3 where not all implementations are fully compatible or have I just completely miss-understood?

Thanks in advance :slight_smile:

The settings are just about which variation are default. The flags are not available via the driver, unfortunately. Off the top of my head, the only one the driver will look at is the Online flag, and it process that by setting bad quality if the point is offline.

Thanks Kevin,

I have an answer now and I can move on, thanks.

For anyone else with this issue in the future. I have decided to change the BOOL into an INT and encode the related data directly into the value. This while maybe not as efficient, it is cleaner and has the benefit of allowing ignition to trend this data and alarm data directly on the value of this tag. If I used a second distinct tag it could get messy.

For example if this BOOL represented a switch state and the extra information showed if the switch had toggled since last read, I could encode this information into bit1 of the INT:

  • The INT value of 0 (Bit0=0, Bit1=0) is “Switch Open”
  • The INT value of 1 (Bit0=1, Bit1=0) is “Switch Closed”
  • The INT value of 2 (Bit0=0, Bit1=1) is “Switch Open - Toggled” (Closed and re-open at least once since last read)
  • The INT value of 3 (Bit0=1, Bit1=1) is “Switch Closed - Toggled” (Opened and re-closed at least once since last read)