RSLogix 5000 TONR won't work in SFC

Is this a bug in RSLogix 5000, or is there something wrong. I cannot get the TONR command to work in a sequential function chart; I can get it to work in structured text, and even a stored action in an SFC (with attribute of "S"), but otherwise, the TONR command always clears the .ACC bit, even if I specifically set timer enable to true and reset to false before the TONR command.

For example, in a P1 action, I cannot do this
// tmr.TimerEnable:=1; Timer is already enabled earlier
// tmr.Preset:=100000; Preset already set earlier
TONR(tmr);
CycleTime:=tmr.ACC;
tmr.Reset=1;
TONR(tmr);
tmr.Reset:=0;
TONR(tmr);

When you perform a Timer Reset, the Accumulated Value of the timer is always reset to 0. If you do not want the Timer ACC word set to 0, then do not perform the RESET function. ACC is not a bit, but a word value, as far as I know.

I have basically come to the conclusion that TONR is bug ridden inside SFC's and to avoid it. I generally use step timers, but there are times that it isn't practical; in some cases a parallel branch can be used solely for a step timer because of this bug. It appears even with the reset bit off, TONR will reset a timer inside "P1" or "N" actions, but appears to work as expected inside "S" actions. This happens to be Rev. 20 of RSLogix 5000.

Robert, instead of posting your conclusions of a "bug", have you run this through RA tech support?

Could it be that you are doing something you shouldn't, or not doing something you should...

I'd love to help further, but I don't have the licensing for SFC, so couldn't test any of your code. I'm sure there are plenty people on here that could, so if you can post the code you are troubled with (ZIP it first, forum rule), I believe you will get the answers.

Have you checked your Logix5000 Controllers General Instructions Reference Manual, Chapter 3, TONR instructions?

Page 131 shows an example for setting up a Stuctured Text TONR timer. It appears that you are not enabling it correctly. Do not enable the TONR every single scan, but only when some external condition needs timing.

Also, you should only do the TONR Reset when you want the timer ACC value to be reset to 0 (for example, after the Timer DONE bit goes on and you are finished with it), not on every unconditional scan as you are doing. Of course it will reset every time - if you tell it to Reset every scan!

I think you need to think about the difference between a PLC program and your usual old C+ program that runs for a few computer cycles and is done. If you set a timer running, it should run for a real-time period that is independent of the CPU cycle. That means you need some conditional statement to looks to see if it is finished, before you call the RESET function. Otherwise it will be reset every time the CPU cycles through, and will appear to never run at all.

Rather than a bug, I think your TONR is doing exactly what you are telling it to do: Enable, then Reset, all during the same pass! That does make it fairly useless for a timing function.

I have a small demo program that shows the bug. In the first demo, I cannot get cycle time because I try to use TONR inside a "P1" instruction. In the second, I use TONR inside an N action but only run on the first scan when the action is active. It fails also. In the third example, I delay my code one scan (the N action runs only on the second scan when the step becomes active) and the code works.

I tried a timer in a "S" and it always works, even when resetting and letting the "S" step become active. That is, the first scan of an "S" action doesn't have this bug.

I then put in an extra TONR of the same timer that is updated in an "S" action in a "P1" action. This should do nothing but update the timer more often. Instead, it resets the timer. Remove this TONR from the P1 action, and it works fine.

Final conclusion is that P1 and N action on their first scan reset timers regardless of the state of the reset flag.

It may be a 1769-L35E bug instead of RSLogix 5000 bug; I don't have another PLC on site to test it with at present.


(If you wonder why the ScanDelay code before looping back, that is because P1's may not reset if I don't)

P.S. I have sent a message to Rockwell informing them of this bug and the same Zip file.

I do not think there is a bug like this in the RSLogix5000 software, not with a basic function such as timers. The software has been around too long and tested too many times. I do believe however that you have "bugs" in your user programs. The timer functions probably do not work as you assume that they do.

I then put in an extra TONR of the same timer that is updated in an "S" action in a "P1" action. This should do nothing but update the timer more often.

Click to expand...

That is an obvious mistake and incorrect assumption on your part. Every time you restart the SAME non-retentive timer by "calling" or re-activating it, of course it will start over (not "update"). You do not need to have more than one instance of each timer. You must enable or trigger that timer when you want it to start. It will then run till it hits the timer PRESET. Then you need to reset it to 0 (for some retentive types of timers) or deenergize and re-enable to restart timers that are non-retentive.

I don't think there is a bug. I tried a simple timer in a N action and it timed until the .ACC >= .PRE. A P1 action is active for only one scan on a leading edge rise. What am I missing. The code seems to be doing what it's supposed to. Seems like an error in the coding, not a bug with the Logix 5000 software. What's the issue?

What you are missing is try doing a tonr in a P1 instruction where it doesn't reset the timer. An N action will reset the timer on the first scan when that N action becomes active, but then it won't after that. In your case, the N action will reset the timer on the first scan, but using a simple timer where ".ACC >= .PRE" you may not notice or care that it is getting reset on the first scan of the N action.

It is easy enough to get around this. For one thing, 99% of the time, step timers are adequate.

Try this

Step_001
P1
tmr.Reset:=1; // Get it initialized
tmr.Pre:=10000;
tmr.TimerEnable:=1;
TONR(tmr);
tmr.Reset:=0;

TRans:
1

Step_002
N
TONR(tmr);

Tran
Step_002.T>1000

Step_003
Trans
Step_003.T>1000

loop back to step_002

Watch how each loop back, the timer is resetting, then going to one second.

Here's my N action:
Test_Timer.pre:= 10000;
Test_Timer.timerenable := 1;
TONR(Test_Timer);

This resets the timer every time the step becomes active. Even after it loops around. Don't you want the timer to reset? Do you need to use a retentive timer instead?

I though retentive timers didn't reset unless I specifically set ".reset" to 1. I am at home right now, so I can't test any RSLogix stuff here.

For the most part, if I want a timer to reset, I'll use the step timers. I am suspicious there are crossed wired behind the scenes that are resetting step timers that are also resetting timers I didn't specifically request get reset.

Just so no one thinks I am stuck, I have long since worked around this issue. At this point, I am pointing out what I think is a bug; not that I need help working around it.

TONR is NOT a retentive timer. A RTOR is a retentive timer. Well I understand that you coded around it. But you declared it a bug. A programming bug in PLC software, especially with an instruction, is a big deal. I don't think it's a PLC bug. I'm just trying to understand what you are trying to do.

"TONR is NOT a retentive timer."

I didn't realize that. And maybe RTOR will do exactly what I want. I'll let you know when I have access to RSLogix again (tomorrow). So, if TONR is not retentive, why the reset bit? I assumed a normal on-delay timer is impossible in any form of structured text (including SFC action) because it can't be called with a false condition like it can in ladder, and therefore required the TONR, which I assumed was retentive.

The TONR instruction is a non-retentive timer that accumulates time when TimerEnable is set.

The RTOR instruction is a retentive timer that accumulates time when TimerEnable is set.