TIA V17, CPU 1516-3 PN/DP on a tray sealer. Added a recipe compare FC two weeks ago at the customer's request and since then the CPU stops about twice a day. Buffer, newest first:
"CPU goes to STOP mode. Cause: maximum cycle time exceeded twice in one cycle"
"Time error. Maximum cycle time exceeded. OB 80"
"Time error. Maximum cycle time exceeded. OB 80"
The new FC runs a FOR loop over 4000 recipe entries every scan, in OB1 with the rest of the recipe code. I raised the max cycle time from the default 150 ms to 300 and it still stops, just less often. The customer wants 6000 ms so it never stops, which I'm not doing.
Is the FC really that slow, or is the HMI loading the CPU? They added a second panel around then and I'm out of ideas past that. Is 4000 entries a scan too much for OB1, or am I missing something about the panel?
Online & diagnostics, Cycle time. What does it show for shortest, current and longest? Post the three numbers. And what's in the loop body, a UDT compare or a few Ints?
Leave 6000 alone. That's not a limit, that's a blindfold.
Shortest 41 ms, current 88 ms, longest 312 ms. Before the FC the longest used to be around 60. The loop body compares a UDT of 12 members per entry, so 4000 UDT compares each scan. Second panel is on the other interface and the traffic looks the same as before.
There is your 300 ms, the loop, not the panel. 4000 UDT compares in one scan is a lot of work in OB1 and it lands on top of everything else, which is why it only overruns now and then.
Two ways. Move the FC into a cyclic OB with a slow cycle, OB30 at 500 ms, if the compare does not need to be scan fresh. Or leave it in OB1 and chunk it: a static index, 200 entries per scan, wrap at 4000. Same trick on every platform, the task cycle is the budget. Then set the max cycle time from your real longest plus margin.
Longer version with the numbers is here: https://plctr.com/understanding-plc-scan-time-and-cycle-time/
Chunked it, 250 entries per scan with a static index, so a full pass takes 16 scans, which is fine for a recipe compare. Longest cycle is 71 ms after a day, max cycle time back to 150. No STOP since.
So it was my own FC all along, 4000 UDT compares every scan sitting in OB1 on top of everything else. Spreading it over scans sorted it, and the default cycle time was never the problem.
One thing I still don't have straight: the buffer says twice in one cycle, but the two OB80 entries are seconds apart. Not sure how that counts as one cycle. Thanks carav9 and hkraus.
71 ms down from 312. That OB80 pair puzzles me too.