In your Logix driver, that is never less than the desired poll rate. (I don't recall where, but you have shown its calculation from the queue dwell time.)
In my driver, that stat is the time from poll cycle start to last subscription item delivery.
I really wanted to remove Device::getSamplingMetrics and let each driver implementation decide how to best do these diagnostics, but didn't really get around to it in time. Most of ours would probably still use the SamplingMetrics concept but I'd rather not force it on third parties (it is an Optional, though...)
Plus that would put Device even closer to being nothing but a Milo AddressSpace 
I switched to SamplingMetrics when I dropped the driver adapter, but it doesn't expose the actual sampling interval as a value I can supply. The Web GUI does its thing to fabricate it. My actual OPC diagnostic nodes supply precisely what I want.
I'm also not yet competent enough in react and with your gateway web libraries to make my own stats display with histograms. (That would be a nice example....)
I have been evolving the Device interface such that if you are mindful about your implementation, you could build something that was ~90% common code, 5% Ignition Device module code, and 5% "plugin to some Milo-based OPC UA server" code...
2 Likes
Oh, yes! I'm paying attention.
1 Like
Looks like the programmer embedded almost EVERYTHING in every section in one giant UDT. The chances of getting him to change that are close to zero at this point.
For reference, this is a conveyor system, broken out into identical sections. Each section has it's own program, and there's a main program-scoped UDT in each section.
So from what I'm reading, it looks like the best thing for me to do at this point is to make a tag group for each section (kind of like what I'm doing now), and either make each one a direct or a leased at a specific rate.
I only have a few tags in the direct group at this point. I used that group for alarms only. If I put everything in a leased tag group, will the alarms still "work"? I guess what I'm asking is does having an alarm set up on a tag automatically "lease" that tag at that rate? OR would my alarms just not work because there's no other bindings on them?
Or, do I need to just put every section in its own direct tag group for the sake of the alarms?
Outside of the UDT access suggestions above (I.e. for AOI & base tag reads):
Try to set all of your tags to poll as slow as possible / as needed. If history is not enabled, no alarms, and tag values are not displayed on an active screen, then thereās little reason to poll them. Those āscaling and configurationā tags (that are only shown within a popup) are good candidates for leased tags with a 0s base rate.
If there are periods of maintenance (or when certain processes are running) where 250ms is needed, you can look in to Driven Tag Groups for those periods.
According to Leased Tag Groups:
the driving mechanism is whether a Tag is being displayed on an open window or view: generally via a Tag Binding of some sort
So, keep all alarm tags on scan, with a reasonable approach to selecting scan rates for those.