DNP3 Buffered Events - Exactly how fast is "cycling through each event quickly"?

Ignition
1

From the user manual (DNP3 - Ignition User Manual 8.1 - Ignition Documentation), it states:
"

Buffered Events

Buffered events can be enabled by setting the Queue Size property on the corresponding Tag Group to a number greater than 1. (See Queue Size on the Tag Groups page.) The number represents the number of buffer events that will be handled by the driver. The queue always keeps the most recent events, dropping older events. For example, if Queue Size were set to 20, and 30 value changes occur on the device while disconnected, then the 10 oldest events would be ignored by the driver.

After recovering from a disconnect, the driver will playback missed events from the driver, and update the value on the corresponding Ignition Tags by cycling through each event quickly, from oldest event in the buffer to the most recent. This value change will trigger value changes in certain systems. Specifically:

  • alarms events (recent evens as well as alarm journal records)
  • Tag History records (when the History Sample Mode is set to "On Change")
  • Tag Events Scripts

Once finished cycling through the buffered values, the Tag will resume showing the live value.
"

Exactly how fast will the old values be cycled through? (can this be added into the user manual? @Paul.Scott )

2

As fast as possible. It’s not staged playback like old school servers do. Think “for loop”.

1 Like
3

Ok, cool!
Does this mean, however, that if there are 10's or 100's of buffered events, and if there are on-value-change events attached to these, that the onChange buffer could become overwhelmed and lots of events will be missed?

4

For tag events, if your scripts execute too slow, yes. Check the missedEvents flag to know.

1 Like
5

Cool, but not for Gateway tag events I assume; these will all fire?
(It's not an issue at the moment, I'm just trying to think of any caveats / things to design for)

6

Yeah those would all fire.

I think it may be unavoidable for tag event scripts, if a single point receives more than 5-6 buffered changes at once (unless the queue size is increased via system property).

There’s an edge case like this for alarm event scripts too - for a single tag if you generate 6+ alarm events and then try to acknowledge all of them at once you can overflow the queue.

2 Likes
7

Cheers, all good info to know!

1 Like