RSLogix TON ACC value more than preset.

[spandy16]

I am using RSLogix Emulate 5000 to test my program. There are several timers in my application. Whenever I run my program, ACC in one of the TON timer jumps directly or increments to a value which is more than the Preset value. And this happens randomly. Whenever I restart my program and Emulator, TON seems to function normally and after some time same problem occurs. What can be the reason behind this?

 

[Ron Beaufort]

DISCLAIMER: I don't ever use the Emulator software – but you'll occasionally see this same effect even while using a "real" processor ...

here's the reason:

the TON "timer" doesn't run/advance/tick EXCEPT when the processor executes the TON rung ...

so ...

think of what will happen if the TON has (for example) an ACCUMULATED value which happened to be just a tiny bit less than the PRESET ... if the processor's scan takes "extra" time to get back around to executing the TON rung again, then the TON will add "more than enough" time to the ACCUMULATOR ... this will give exactly the sort of "overrun" condition that you've described ...

in MOST cases, this type of "overrun" won't cause any problems ...

BUT ...

I've helped debug several systems over the years where the programmer had used an EQU (Equal To) comparison instruction based on the timer's ACCUMULATOR value – rather than using the timer's built-in Done bit ...

this can create havoc when the processor happens to take just a little bit too much time to "come around again" and "service" the TON instruction ... and worst of all, the condition will usually be highly intermittent/random in nature – and thus extremely hard to spot – unless you're specifically looking for this type of problem ...

.

 

[spandy16]

DISCLAIMER: I don't ever use the Emulator software – but you'll occaisionally see this same effect even while using a "real" processor ...

here's the reason:

the TON "timer" doesn't run/advance/tick EXCEPT when the processor executes the TON rung ...

so ...

think of what will happen if the TON had (for example) an ACCUMLATED value which happened to be just a tiny bit less than the PRESET ... if the processor's scan takes more time to get back around to executing the TON rung, then the TON will add "more than enough" time to the ACCUMULATOR – giving the sort of "overrun" that you've described ...

Thanks for this information. So it might happen that the ACC value overruns the PRE value. Actually in my program I have made a calculation task based on the ACC value of TON timer.

Output = Target * (ACC/PRE)

I want the output to increase till the target value in preset time. So if the ACC value is not precise enough to PRE value my output will be more than target value.

 

[Ron Beaufort]

I'm not 100% sure that I'm following your logic – but from where I sit, it certainly looks like you MIGHT be setting yourself up for some intermittent/random malfunctions - based on the result of that division operation ...

you might want to consider putting a "clamp" rung on the Accumulator's value JUST BEFORE the "math" rung that you've described ...

.

 

[TConnolly]

It looks like you are using a timer to ramp an output.

The solution is simple, immediately before the multiplication put the following in

GRT MyTimer.ACC MyTimer.PRE MOV MyTimer.PRE MyTimer.ACC

 

[spandy16]

Thank you Ron for this idea!

 

[spandy16]

Thanks TConnolly.