This sounds familiar! I had this once during development / testing of a project where I had accidentally set a periodic task to 20ms that should have been 200ms - plc didn’t have overhead time to deal with comms.
Generally what the load factor means is that the number of requests are taking a percentage of time based on your scan class to complete. Anything over 100% means it’s taking longer to process all of your tags at the desired scan rate. For example, if I have a 1000ms scan class and it takes 50 requests to get all the data and it shows 50%, then it means the device is responding with the 50 requests in roughly 500ms (50% of the scan class desired rate). If this is exceeded, you will get random overlays, event triggers (i.e. alarms), and all kinds of weird things you don’t want.
The brand of PLC will dictate how to deal with these things. For an AB PLC, as others have mentioned, setting the main task to periodic and slowing it down gives more time to overhead processing (there is a way to adjust overhead time as well). For other brands this might be different. In a Modicon PLC, for example, each PLC cycle allows a certain amount of overhead to communications, so to increase communications, you want MORE cycles, and thus, cyclical operation may be better, or at least a faster periodic rate. In some cases, adding additional comms cards helps alleviate the CPU burden.
We employed the prime number thing at one point (and didn’t turn it back off), but the ultimate resolution was to just create additional scan classes and allocate higher priority tags to the faster rates with the others to slower or on demand scan classes. This fixed our issue and kept our CPU utilization (on the PLC) down.
As an FYI, we are scanning an L73 processor for ~38k tags, with 50% at 1s scan and the others at 2, 5, and on demand. On an M580, we have some systems with ~15k tags at roughly 40% load factor, but another M580 with ~8k tags and a 60% load factor - this is all dependent on time spent processing logic and number of cycles it can achieve between them (9ms vs 15ms), as well as the number of request Ignition needs to make to cover the address space of the tags (35 vs 60). For a Modicon system, the Mean Response Time is indicative of the cycle time of the processor (whether it be periodic or cyclical).
To improve the load factor, at least for Modbus devices, is to pay attention to the number of requests and see if you can lower that number. This might mean remapping your addressing in the PLC to pack the data together as best as possible.
4 Likes