Studio 5000 TON timers in FOR loop in ST

[musterhere]

Hi, I'm quite new to Rockwell PLC and currently trying to implement the following

if Sw1 then
for i:=1 to 20 by 1 do
xEnable := 1;
bit := bit + 1;
if delay.DN then
xEnable := 0;
end_if;
end_for;
end_if;

delay.TimerEnable := xEnable;
delay.PRE := 5000;
tonr(delay);

So once the Switch is on the variable bit should be incremented gradually with each step having 5 second delay, but running the code makes the bit increment straight up by 20 without any noticeable delays. Could someone please explain how does Studio 5000 implement the programs and how should I reorganize the code to achieve what I want?

 

[joseph_e2]

Loop through it in your mind and see that your bit +=1 instruction happens every loop independent of the timer status. Try moving that line into the "if delay.DN" statement.

Edit to add:
Note that the loop isn't going to pause while the timer is timing, rather it's going to execute a bunch of 20 times back to back. Look at doing a "while" loop instead of a for-next loop.
While bit <20
If delay.DN then
bit+=1
xEnable :=0
end while

Something like that.

 

[Aardwizz]

First off, Your bit:=bit+1 isn't in the delay.DN If-Then nest.
So, yeah, it's going to count to 20 immediately.

Second, you're For-Next loop isn't affected by the timer being done, so what will happen is that it will loop 1-20, update the timer. Then next scan it will loop 1-20, update the timer some more. And so on.

When the timer it done, it will loop 1-20, adding 1 to the bit each time so that it will wind up at 20, and setting xEnable:=0 each pass. Then it will clear the TimerEnable bit, clearing the .DN bit and .ACC and start all over again.

[EDIT: Looks like joseph_e2 beat me to the same answers]

 

[joseph_e2]

Loop through it in your mind and see that your bit +=1 instruction happens every loop independent of the timer status. Try moving that line into the "if delay.DN" statement.

Edit to add:
Note that the loop isn't going to pause while the timer is timing, rather it's going to execute a bunch of 20 times back to back. Look at doing a "while" loop instead of a for-next loop.
While bit <20
If delay.DN then
bit+=1
xEnable :=0
end while

Something like that.

Actually, a while loop is probably not a good option if it's waiting for a timer to finish that's outside the loop. If you want "bit" to increment once per delay.DN, then you don't need a loop at all. Just something like this:

If delay.dn AND (bit <20) then
bit+=1
xEnable :=0
End if

 

[drbitboy]

Hi, I'm quite new to Rockwell PLC and currently trying to implement the following

if Sw1 then
for i:=1 to 20 by 1 do
xEnable := 1;
bit := bit + 1;
if delay.DN then
xEnable := 0;
end_if;
end_for;
end_if;

delay.TimerEnable := xEnable;
delay.PRE := 5000;
tonr(delay);

So once the Switch is on the variable bit should be incremented gradually with each step having 5 second delay, but running the code makes the bit increment straight up by 20 without any noticeable delays. Could someone please explain how does Studio 5000 implement the programs and how should I reorganize the code to achieve what I want?

Background

PLC programming is primarily about time, and the scan cycle is the clock; when something happens is more important than what happens.

If you don't know what the scan cycle is, watch this video series.

General

The code above, and the fact that you are new, suggests you need to understand the scan cycle a bit better. It is very different from "conventional" programming; do you have any other programming experience? Is this an assigment for a course?

Specific

As noted by others, the code above, does not make sense in a PLC: the FOR loop simply counts to 20 on every scan cycle (when the value of Sw1 is 1), so that happens once every millisecond or so, and the eventually timer expires after 5s, and is disabled on the next scan cycle (again, when Sw1 value is 1).

Just as an example, the TONR instruction on the last line is evaluated (executed) once per scan cycle, and that is the only time when the delay.DN bit's value can change from 0 to 1. So the IF delay.DN THEN ... logic does not need to be inside the loop (even if the loop was necessary) because delay.DN cannot change in the loop.

Also, there is no code in your example to reset the TONR, so the timer will run to expiry after 5s (5000ms), whether or not the value of Sw1 is 1, and then never run again. because the value .DN will be 1, which will make the value of xEnable 0, which wil; disable the timer but leave the value .DN at 1. I think you may have meant to use TON, where the timer resets when its IN parameter (somewhat, but not exactly, analogous, to the .TimerEnable attribute of the TONR structure). That is, unless you want the TONR to only accumulate time when the Sw1 value is 1.

See the behavior of the TONR instruction here*; see the behavior of the TON instruction here*. There is also an interesting article about the TONR instruction here.

* N.B. none of those are @OkiePC-safe links.

But again, none of this will make sense until the scan cycle and its implications are fully understood. If this is part of a class and the syllabus has not yet covered the scan cycle, then the syllabus should be corrected to do so. One implication is that the .DN bit of the "delay" structure cannot change until and unless the TONR instruction is evaluated**; another is that loops within scan cycles are rarely necessary, especially if they depend on inputs***, and the TONR is effectively an input here, to change; it is better to use the scan cycle as a de facto loop.

I suggest you watch the video series mentioned above, and watch it repeatedly until you can cite the narration before @Ron Beaufort says it.

** that is not true in all PLC brands, but it is true in Logix.
*** that is not necessarily true in Logix, but it is true for most other PLC brands, including non-Logix Allen-Bradley PLCs.

 

[APS_Programming]

My understanding is that you would like a number to increment by 1, every 5 seconds up to 20? Once counter reaches 20 should it reset to 0 or stay at 20? If I understood the problem you trying to solve then you don’t need loop. Please define the problem you trying to solve.

 

[Aardwizz]

Background

PLC programming is primarily about time,

I disagree with that statement. Time is the worst way for a PLC to control something. Using time has an inherent assumption that an specific event takes the same amount of time to occur consistently. From almost everything in our daily lives, we know this is a false assumption.

If you find yourself using Time to control, you need to ask yourself, "where am I going wrong?". Sometimes the answer is:
• They don't make a sensor to detect that.
• They do make one, but I can't fit it in the space / environment / budget.

So you compromise and control by time. But then you forget that you've made a bad assumption and move on. Never forget your assumptions, in any aspect of your life: they'll come back to bite you. Too many people vote based on assumptions that have been proven to be false, but because they forgot that they had made those assumptions, they disbelieve the fact rather than change their behavior. But that's a different soapbox.

We use timers in the PLC because even the scan time of the PLC isn't consistent. Even using timed interrupts doesn't guarantee perfect beats: interrupts with higher priorities and even the length of the code in the timed task can add msecs between "fixed" times.

Milliseconds (or smaller) is the unit of time for the PLC, while seconds and even minutes are the human-scale of our thought. Summing msecs is too hard for us, so we lazily use TONs to do the work for us. Lazy is fine: I work very hard to be lazy. But because PLCs do what we say and don't care or know about what we want, we have to be scrupulously honest with them and ourselves about what is supposed to happen when. And that means recognizing our compromises, assumptions and laziness.

</rant>

 

[drbitboy]

I disagree with that statement. ...

</rant>

Perhaps you misunderstood what the phrase means.

By saying it's about time, I am saying that, to understand what a PLC does, one needs to understand that when something happens is more important than what happens. When I use the that phrase "PLC programming is primarily about time," it is usually followed by "and the scan cycle is the clock;" in other words I am am referring, not to some absolute measure of time, but to the relative order of events.

Pick a random 100 "why does this not work" threads on this forum. Almost all of them will involve the OPs misunderstanding when events are are occurring.

 

[drbitboy]

If you find yourself using Time to control, you need to ask yourself, "where am I going wrong?".

</rant>

I absolutely agree with this. I have coded a lot of things in my career, and anytime I have had to add a time delay to make something work, I have felt it was a very unsatisfactory workaround to whatever the real problem was that could not be addressed.

 

[vagabondengineer83]

Hi, I'm quite new to Rockwell PLC and currently trying to implement the following

if Sw1 then
for i:=1 to 20 by 1 do
xEnable := 1;
bit := bit + 1;
if delay.DN then
xEnable := 0;
end_if;
end_for;
end_if;

delay.TimerEnable := xEnable;
delay.PRE := 5000;
tonr(delay);

So once the Switch is on the variable bit should be incremented gradually with each step having 5 second delay, but running the code makes the bit increment straight up by 20 without any noticeable delays. Could someone please explain how does Studio 5000 implement the programs and how should I reorganize the code to achieve what I want?

Here's an easy way to do what I believe you're trying to do, but in LAD format because it's easier to do it in LAD than in ST I believe, but that may just be personal preference. Add a MOV instruction to assign a step dependent timer preset if you'd like.