Let's just go off what we do know.
1) Since it is controlling a sequencer we can say with a reasonable degree of certaintly that it should NOT be counting anywhere near as fast as every other scan.
2) It WILL "run away" in all instances where the RLO prior to the C5:0/CU remains true. (Assuming this code is not being executed in a conditional subroutine and assuming the ACC is not being forced somewhere else)
3) Since the B3:5/1 is a manual pause for the HMI, it is reasonable to believe that the problem is not related to that and assume for our purposes that it always evaluates true. (Otherwise the OP hopefully would have mentioned that the problem only occurs when they go in and out of pause).
4) B3:4/9 MUST be on all the time during the entire sequence or the counter will just get reset before it makes any progress. Ron's point about the reset when going into run mode is taken, but again I would have expected the OP to have made mention whether they were putting the system in and out of run mode or cycling power when the issue is occuring.
That pretty much leaves the comparator.
So the next question is, what is this comparator supposed to do, because based on the descriptions it seems misplaced. Count at all times unless the counter ACC is negative? Well, as far as I knew negative values are not allowed in the ACC of a timer (I even tried and it slapped my hand). So it would seem that this would be on ALL the time with N11:0 set to 0.
Can the OP confirm that N11:0 has always been 0?
Even so, what is the purpose of N11:0 other than to "pause" the sequencer from counting until the timer has been running for a minimum time. In which case as soon as that comparator is satisfied the counter will again start free-wheeling.
With all that being said, the only things that make sense given the information we have been is that this code is probably being executed conditionally whether in a separate subroutine or is being jumped around until the step conditions are satisfied.
This might possibly explain why the C5:0/CU is there. If this code is conditionally executed as I suspect then based on how the code was written it would not be able to properly detect transitions. As soon as the code is scanned again it would never actually count up unless the conditions ahead of it were seen to transition from false to true WHILE that code was executing. So this network forces it to count up at least once so long as all the previous three conditions evaluate true.
That's IF the problem is caused by a free running counter.
So if it is a free-wheeling counter issue then it probably has to do with the code that makes sure this is only scanned conditionally.
The OP also mentions the
"N" data table that holds the "reset" bit
Holds the reset bit for what? Is there a reset on the counter somewhere else? Witholding information is obstruction of justice.
So the counter getting prematurely reset somewhere else is still a reasonable possiblity.
Perhaps the OP could make a screen shot of the cross reference on C5:0 as well as a screen shot of the T4:21 timer code?
Also, what does this comment mean
My first thought was that the values in N11:0 were "zeroed" out, but they're not
N11:0 is ONE value. When you say "the values zeroed out" are you referring to the bits of N11:0?
A screen shot of a cross reference of N11:0 might not be bad idea either.
