Using a DNP3 device for the first time and I'm seeing data update each time it does a class 1 poll however it's not backfilling the data on my trend line for data between polls.
I'm changing the value in the RTU every ~5 seconds. When I drop my class 1 poll rate to 5,000ms I see the data correctly whereas when I increase it to 30 second polls I miss a lot of values. I can't figure out how to properly make the events work
The first two bumps are with 30s class 1 polling, the third set is 5s class 1 polling.
Sounds like you are expecting buffered events to work with Class 1 polling. I'm not fully up to speed on that, but it looks like there are target device Sequence of Events settings that are required:
I had missed the enable backfill option in the realtime tag provider but unfortunately enabling it didn't change anything. The dnp3test is used throughout so not #2 either.
This is just a dummy VM I spun up for a quick test so lacking tools. Will install wireshark tomorrow and get a dump to check the events are coming through. I''m not sure if it matters but I also don't have an database set up as I was expecting to just use the internal history setting. Is there any limitation as a result of that? I can install SQLExpress if necessary just thought I'd ask before wasting time on it if it's not necessary.
Missed seeing this. I did follow the manual and set the queue size per the documentation and the device is a DeltaV FB3000 which does support sequencing events back.
Confusingly now this morning its working properly and backfilling data. All I've done is just reset the trial and check it again without any changes. So perhaps something yesterday fixed it but needed to be reset first. Does making changes to the real time tag provider on the gateway page require a reset? The only other change I made was to the queue size and sampling in the tag group settings.
Device connection - DNP3 Destination address is default 1 on the FB3000 while Ignition is 4
Device connection - Increased to 30s just for longer scans to test
Real time tag provider enable backfilling under advanced properties
Tag group set Queue size to >1, documentation suggests 100 though I'm still not clear if it's 100 events per tag or 100 overall queue size. the FB3000 device has a default event queue of 1456 per type. We have ~250 points in the map so need to figure this out.
Tag history settings must be set to On Change. Using tag group does not backfill data at all.
FB3000 Software config - set Analog Input scan period to 5s (I believe this is the update rate for pushing the events)
A few more questions I'm not sure if it's worth creating a new thread for.
In my DNP3 mapping on the device, I can configure my G30 tags as a 16 bit int with flag or 16 bit int without flag. The documentation indicates my status flag will show if this value is healthy, comm loss, internally forced, etc. I'm wondering if this status flag is accessible anywhere or a limited to internal to the DNP3 driver? These only come through during the integrity poll so they likely won't be of much use anyways but I'm trying to check if the flags could have any value.
Strings - I got working by specifying the GVI address directly, it doesn't look like the driver can auto discover it which is mildly annoying for consistency of not being able to maintain 'String1' as an address but functionally seems fine so far. The removal of the aliased points section from the legacy driver is frustrating though as I can't add in an alias for these strings.
Lastly it seems writing values are not bidirectional reads? We had an AnalogOut set as an integer index to set commands. For example 0 = normal 1 = bypassLow 2 = bypass Low and High. What I found is if the RTU clears these when the timer expires Ignition doesn't see the update. Ignition only sees the update during the read after write that I have set to 1,000ms. Though I suspect this is an issue with my end device not sending an event rather than Ignition not handling the AnalogOut updating in the device.
No, and the only flag that really gets looked at is the “Online” flag. When flags are included and this flag indicates the point is not online you’ll end up with a Bad_OutOfService StatusCode.
It’s not really a driver limitation; DNP3 does not include OctetStrings in the integrity poll, which is how the discovery/browsing is populated.
Not sure what this means, but you already discovered the solution. Writes aren’t writes, they’re select and operate or direct operate commands, and if your outstation isn’t configured to send the corresponding kind of event when one of the outputs change you need to enable that setting to read it afterwards.
One more question now that I've got some wireshark captures. The RTU has a setting for it's rate at which it creates analog input events, when I had temporarily set that to zero I noticed that Ignition no longer updates its tags via class 1 or 2 polling but it does update via integrity poll which works as I expected. However I noticed that Autosol was still updating it's tags outside it's integrity poll which I didn't expect.
Looking through the captures I notice that Autosol does a static read of only the analog inputs. Is this possible within Ignition? When I look through the system.dnp command list I only see demandPoll for the events. Is there a parameter for the classList I can use to only read the AnalogIns or BinaryOuts?
If you create tags using the "GVI" syntax they are read statically using the DNP3 Read command. But then you lose the event-based updates.
You could also issue a system.opc.readValues scripting call where you construct the list of OPC Item Paths and use GVI syntax. But these won't update your other tags.
Ah that's fair. Is there any easy way to get the gvi values if my points are already available in Ignition via the browse devices menu? Or do I need to manually create the list of gvi syntax for each tag?
That's what I'm trying to do to learn. The hypothetical scenario I'm trying to consider:
Say I have a RTU in a very low bandwidth situation. It's set to scan it's analogIn's every minute and generate a class 1/2/3 event. We poll it every 15 minutes and it backfills correctly. If the operator logs on and clicks a button to launch system.dnp.demandPoll class 1, I only get the stale data from the RTU's last scan of it's inputs. Which say is ~15 seconds old. They click the button again 30s later and the values don't update as the RTU hasn't generated any new events since it only generates events every minute.
Now in my DNP3 map I have the clockSeconds set as AnalogIn0 group 32 event and the same tag in AnalogIn1 set as a group30 event. What I'm trying to test is the best way to get the live values when they click demandPoll. I thought putting the tag as a group 30 would have provided the static (live) value each class poll but that's not the case. I know I can get the current value via integrity poll but since we poll a lot of alarms through the BinaryIn map, if I can force a static read of only the analogIns then that saves us a fair bit of bandwidth versus doing the full integrity poll.
It's a niche scenario, but with some remote sites via shared radio towers we have more care towards bandwidth so I'm just trying to figure out what can and can't be done at this point before things leave the lab.
I think I'll have to. My confusion just comes from the below screenshot where Ignition and Autosol both issue a OBJ60 read commands when doing class polls however Autosol also is able to issue a OBJ30 read to target only the static AnalogIn values without events whereas I don't think the Ignition driver can do that.
Switching to the legacy DNP3 driver addressing fixed this for me. Using the gvi address it polls the static values of the commands so we properly read back the value when the RTU changes the value. Less efficient than doing it via events. I did find the alternative is I could duplicate the tag in the AnalogIn map to do event readbacks that way but then it ends up being a bit messy for maintaining things as things get added/removed over time.
I do wish the Aliased points function of the legacy DNP3 driver wasn't removed. Not being able to rename the gvi path for these commands makes it the blacksheep of the tag map now but it's functional so now just a documentation problem.
