is Siemens also undocumented? or just the older models? Not that I really care much for Siemens - we don't use them much over in Aus, that I've come across anyway
All of it is undocumented, and the ānewā S7 Plus stuff is extra undocumented and not publicly reversed anywhere that I can find (open source, anyway). Their official line on interoperability is āuse OPC UAā. (and ditch your old hardware in the process)
The trouble with this though, is that their onboard OPC-UA servers have a relatively small tag limit 
I certainly wouldn't be able to read 10k tags from one of them. Some of our large AB PLCs we're reading upwards of 15k, so that's a bit disappointing from Siemens
Yeah, but you can get around it if youāre willing to put up with some inconvenience (aggressively use structured types and the corresponding derived tag dance in Ignition) or put tags you need at a slower rate into a polled Tag Group.
1 Like
v7.9 had a "Load Factor".
v8.1 has an "Overload Factor". 0% Overload is normal.
2 Likes
I think he was just comparing AOI vs UDT performance of the Logix v21 driver on 8.1.x, not doing something across versions or drivers.
Yes, but @tashby posted some v7.9 screenshots, and Nick is talking like the metric is the same. Not.
I must admit that I like reverse engineering. (:
1 Like
Haha, yeah. It may or may not be a productive use of time depending on circumstances. But it is fun 
You're right, I didn't appreciate the difference. So 0% overload is really <=100% load factor?
I assume that 100% overloaded is when the tags are taking 2x the nominal scan rate to return? (i.e. ActualSamplingInterval = 2x scan rate)
1 Like
Yup.
1 Like
Wow. Checked my email and saw a bunch of chatter on this topic.
Figured Iād share some stats of what Iām seeing on a production PLC for regular AOI access. This is on an L33ER with some messaging to other PLCās. Also it has some Modbus comms to a couple pumps and Ethernet I/O to some analyzers on it. Doesnāt seem like a ton of tags though. It is talking to a Cloud server, so Iām sure thereās some delay involved with that as well.
We are working on a similar project in a couple months and have changed our AOI instructions to be more UDT based at the PLC level so we arenāt accessing AOIās directly. If I remember, Iāll post how that one looks under similar circumstances. It will be to the same Cloud server.
So if my āOverloadā in v8.1 terms is saying 139%, then that means my āLoad Factorā in v7.9 terms is actually 1,390%??
No, there isnāt quite a straight line between the old load calculation and the new overload. Part of the reason it was replaced was that it wasnāt a reliable or sensible calculation, especially when concurrent requests were > 1.
Gotcha. I know we use it as a gauge of sorts to see how well data is communicating. Not sure if thatās recommended or if some other metric is considered a better gauge for adjusting settings to be more optimal.
āoptimalā is up to you.
Really, just look at two things:
- what is the requested sampling interval?
- what is the reported actual sampling interval?
You decide whether the difference is okay or not. Thatās really it.
2 Likes
OMG!! You are polling your devices across the internet? That would explain the response times in hundreds of milliseconds.
Don't do this. PLC query/response protocols are extremely sensitive to network latency. It doesn't take a ton of tags to crush your comms when your OPC driver isn't local.
Buy a $1000 base Ignition license (OPC with the popular drivers) for each facility and make OPC client connections from the cloud.
We do have an Ignition Edge PC in the panel with Touchscreen running there as well that I forgot about (itās been a couple years). They had intended that to be a backup if they lost internet connection to the site as they primarily monitor/control everything remotely. I realized I still had those tag groups in the edge as direct and faster rates. I slowed them down and made them leased which certainly brought the cloud stats down significantly.
I think the thought was that if the Touchscreen/PC was to die or crash or something, they would completely lose their remote connection if it was using that as a local OPC connection and thought it would be better to not have that extra point of failure. Things would be fine with the UDTās at the PLC level I believe. Is there some type of device that would just act as an OPC driver locally that our Cloud server would connect to other than a PC in the panel? Could I still create tag configurations from the Cloud Gateway/Designer?
Iām noticing that the Overload percent is basically just a calculation of those variables. So checking your Overload value is the gauge for that. Unless Iām missing something.
Combining these into one group at the same rate will likely help a bit (hopefully allow combining some requests to reduce total number of requests):
