HUGE caveat: none of us posting here know this process; I see the word "Punch" and think "nine fingers - remaining;" YOU NEED TO REALLY UNDERSTAND THIS PROCESS before becoming known as the guy that followed advice from the Internet. Unless the fault is bizarrely intentional to stop the process because an unsafe condition occurred, it is likely that someone made a mistake programming this process.
So, assuming the following will be taken with a dump truck full of salt ...
As long as discrete output
Local:1:O.RangeEn.13 is 0, you can do whatever you want to the accumulator and should will not cause another [
Array subscript too large] fault on Rung 8. How you ensure that bit is 0 (e.g. temporary force), and what that means, and whether it is safe, and remembering to remove however you did it, is your problem.
But since you are back in program mode and the PLC is not running, I suggest fixing the logic to prevent the fault in the first place. The hard part is understanding the process (see caveat above). The canonical questions are
- How long has this current software been running on this process?
- Has this problem happened before?
The easiest way I can see to do that is to move Rung current 9, which RESets the counter, to between current Rung 6 (the CTU that would presumably be the
only place that would increment .ACC's value to 16 in the first place) and Rung 7.
Also, when you move current Rung 9, I would consider removing the [
XIC Local:1:I.RangeActive.13] from that rung i.e. from current Rung 9. The only way the .ACC can become 16 in the first place is on a falling edge of
Local:1:I.RangeActive.13, which means the RESet would
usually occur anyway, because the .DN will also be 1 when .ACC increments to 16. I say usually because there is an obscure, difficult to debug, edge case in some PLCs*, where the
Local:1:I.RangeActive.13 bit could be 0 on current Rung 6, and 1 on later rungs, e.g. on current Rung 9, which would prevent the RESet. In fact, the .ACC could, with an impossible sequence of state for the .13 bit, be incremented well beyond 16.
* I am pretty sure it can happen in ControlLogix (according to Ron Beaufort's bootcamp videos - caveat: IIRC), not so sure about CompactLogix.
And as long as we are on the topic of obscure bugs, I would replace the RESet with a [
CLR L_PunchCounter.ACC], because otherwise the RESet, in addition to putting a 0 into the value of
L_PunchCounter.ACC], would also assign 0 to the value of
L_PunchCounter.EN, which means another falling edge of
Local:1:I.RangeActive.13 (i.e. rising edge of [
XIC Local:1:I.RangeActive.13] would be detected on the next scan by the CTU on Rung 6, even though the value of
Local:1:I.RangeActive.13 did not change.
