Steve,
I think the 89 is the value from the last good subtraction, and somehow when it hit these specific values the SUB resulted in a value out of the integers range and that caused the fault.
If you see any negative numbers in the counter's accumulator, then it has OVERFLOWED, it is a CTU, not a CTD.
That means you have counted more than 32,767 times before it has been reset.
I think the subroutine is missing the "Seconds = 2" which performs the reset.
What is the AVERAGE scan time of the program, and the MAX scan time, from status registers S:23 and S:22 respectively. If your scan time is very high (and I've seen some good ones!), the subroutine could potentially miss the "=2"
One thing you need to be absolutely certain of - is it overflow on this counter that causes the faulting... Remove the unconditional OTU S:5/0 I got you to put as the last rung, and relocate it to just after the CTU, but make it conditional on Counter.OV You don't need to worry about Counter.UN because it is a CTU instruction. And while you are at it, cross-reference the counter and make sure it is not being used elsewhere.
If the SLC still faults, there's an overflow, or underflow, somewhere else, and we may be looking in the wrong place.