Don't forecast. Just cache response sizes per request and iterate to appropriate sizes. Hold statistics on such with your browse results. No need to be perfect, just better.
Can't really get that information from the AgLink library, unfortunately.
Huh. Sorry. 
Also running into slow performance using this driver.
Would it help splitting the tags up between this driver and OPC? That way the slow tags can be subscribed through OPC, and the fast tags split into smaller groups, polling
Yes, that sounds like a reasonable approach to me. Can you share more info about your use case?
i.e-
- PLC Model(s)
- How many tags total?
- How fast are "fast tags"? How many tags do you want to poll at that rate?
- Any other info you think could be helpful for us to better understand how you're hoping to use the driver
We are in the process of migrating the site from another SCADA to Ignition. Both SCADA's are still active, because the client does not trust Ignition's response times yet.
The PLC that responds the slowest to Ignition, a Siemens CPU 1515-2 PN, also has the highest communication load, hovering at about 60%. This load has been reduced a bit by decreasing the poll rate of the other SCADA.
The OPC tags that communicate to this PLC have been split in the following tag groups:
Configuration: 15s Direct Subscribed - 979 tags
Control: 1,5s Direct Subscribed - 196 tags
Diagnostics: 7s Direct Subscribed - 357 tags
Status: 2,5s Direct Subscribed - 200 tags
Switching a valve from auto to manual involves a command tag in the control group and a feedback tag in the status group. Currently it takes less than 5s to switch a valve from auto to manual, which is good, but there are not a lot of activity on site. It can take about 30s with more site activity.
There are a few TickManager "aggregate callback time exceeded tick rate" warnings and "Clock drift, degraded performance, or pause-the-world detected" event warnings on the gateway that I am busy sorting out.
What other optimisations do you suggest? We will switch off the old SCADA when the client can trust to run production with the new one.
What driver are you using, also what hardware is your server running on?
We are using the new "Siemens Enhanced Driver".
The server is running on a Virtual Machine, running on a node on a Penguin Solutions Stratus ztC Edge device (Stratus ztC Edge: Power Digital Transformation at the Edge).
This is a bogus test. Almost all limitations in performance are on the PLC side, with some variation with driver quality. The prior SCADA is undoubtedly impacting Ignition performance. Test them separately. Use lab gear if necessary. (If you don't have lab gear, borrow it, or pay an integrator to test for you with theirs.)
Thanks, this is good use case info!
I don't have many other suggestions for optimization, the PLC is certainly the bottleneck. However, we are currently working on an improvement to the driver to prioritize write requests, which may help with your scenario.