Timer Question Logix 5000

PLC is a control logix running logix 5000.

Ok so im simply testing a piece of my logic that has a TON function block. Say you have an input preceding the TON function block, and you set a .PRE of 5000ms, if you turn on the input, the timer will start timing, and once it reaches 5000ms the .DN is set, but i noticed that when the .DN bit is set, the .ACC doesn't stop at 5000 but instead at 5015ms. I know that in the plc world nothing is instant therefore their is a slight delay when transitions occur. So my question is, is that .ACC value 5015 because their is a delay before the PLC can see that the .DN bit is set and stop the .ACC from incrementing or is their another answer to this???

Remember that the timer is 'tested' on each scan. So in your case the previous scan arrived at the timer instruction some time before it reached 5000. On the next scan (at least 15 ms later) the scan again arrived at the timer instruction, saw that the accumulator value was at or over the preset so it set the .DN bit and stopped accumulating time.

Just to revisit how the timer instruction works, it IS NOT accumulating time in-between executions of the instruction. At each execution it takes what the reference time was at the LAST execution, subtracts that from the Current value of the reference time, and adds that difference to its accumulator. It then stores the current value of the reference time into its memory of the LAST execution (for possible use on the next scan). Then it checks to see if the accumulator is at or over the preset.

So the possible error between the preset and the actual time from the instruction's first being enabled until the .DN bit is set is -0/+scan time. In other words it will be at least as long as the preset and up to one full scan time more.

So don't think of a timer as some device out there happily accumulating time waiting for the scan to come around again. It's only an instruction which subtracts, adds, stores and compares numbers. The only actual 'timer' is the reference clock that it checks.

@ Bernie, simply put thanks.

And to build on Bernie's excellent explanation, if the Timer is in a subroutine that has to be called, or in a separate task, that can also add to the overrun. Since the "actual time" continues to run but the Timer instruction has to wait for the scan to call the subroutine and update the .ACC value.

OG

@ operaghost, thanks on the additional info