Continuous task and for loop problems

gbautomazione

Member
G
Join Date
Mar 2021
Location
Italy
Posts
5
Good morning everybody.
I have a 5380 ControlLogix with motion and safety and I'm having some issues with a continuous task and for loop (structured text):
I have 100 temperature probes and a cumulative bool signal that must be 1 when all temperatures are in a setpoint range.

I'll explain with some code:

In the same program I have these subroutines:

In a subroutine I have:


Code: 
temps_all_ok := 1; ////----- this was missing

FOR count:= 1 TO 100 BY
1 DO

if temp[count] < setpoint then
    temps_all_ok := 0;
    exit;
end_if;
END_FOR;


In another subroutine I have a ladder program that checks temps_all_ok like this:

  

auto_on           step[0]                          step[0]

----| |--------------| |----------------------|----(U)----|

                                              |  step[1]

                                              |----(L)----|







temps_all_ok       step[1]                          step[1]

-----| |---------------| |--------------------|----(U)---|

                                              |  step[2]

                                              |----(L)---|



sometimes I find step[1] and step[2] latched simultaneously..

It's possible that one routine overlaps the other?

If I put my code in a periodic task >= 10ms the program is working correctly...

I can't figure out what I'm missing.. Maybe the for..loop is not correct?

Thanks for any help
 
Last edited:
cardosocea said:
Why do you use the Exit inside the if?

Where is temps_all_ok used in the other subroutine?
Click to expand...

I've added a line of code that was missing.

I use Exit because once I find at least a temperature out of setpoint, the for loop should break.

The temps_all_ok is set before entering the loop.
In the other subroutine is used in the ladder diagram as you can see.
 
gbautomazione said:
sometimes I find step[1] and step[2] latched simultaneously..

It's possible that one routine overlaps the other?

If I put my code in a periodic task >= 10ms the program is working correctly...
Click to expand...


Welcome to the forum!


The ST looks correct.


Also, if temps_all_ok is 0, then it is possible for step[1] and step[2] to both be 1 at the same time (assuming step[2] was assigned 1 previously, and not re-assigned 0).


We don't know the schedule of the ST and the ladder "subroutines," nor their relative priorities. If the ladder could interrupt the ST, while one of the temperatures (temp[N]) was below setpoint, then it could read contact [temps_all_ok] as 1 when it "should" be 0. One way around this would be to create an ST-local boolean to assign 1 before the loop, and then assign 0 inside the loop when a temperature is found below setpoint, and copy that local boolean to the global temps_all_ok after the loop (see below).


That is just a guess though; you don't say which subroutine you put into the periodic task, but if it is the ST subroutine and it was a higher priority than the ladder, then the ladder would never see the intermediate value (1) of temps_all_ok, which would explain why it works. If both routines are continuous then I don't know if one could interrupt the other.




Code: 
[I][COLOR=blue][B]local_[/B][/COLOR][/I]temps_all_ok := 1; ////----- this was missing

FOR count:= 1 TO 100 BY 1 DO

    if temp[count] < setpoint then
        [I][COLOR=blue][B]local_[/B][/COLOR][/I]temps_all_ok := 0;
        exit;
    end_if;

END_FOR;

temps_all_ok := [I][COLOR=Blue][B]local_[/B][/COLOR][/I]temps_all_okl
 
Last edited:
drbitboy said:
The ST looks correct.


Also, if temps_all_ok is 0, then it is possible for step[1] and step[2] to both be 1 at the same time (assuming step[2] was assigned 1 previously, and not re-assigned 0).


We don't know the schedule of the ST and the ladder "subroutines," nor their relative priorities. If the ladder could interrupt the ST, while one of the temperatures (temp[N]) was below setpoint, then it could read contact [temps_all_ok] as 1 when it "should" be 0. One way around this would be to create an ST-local boolean to assign 1 before the loop, and then assign 0 inside the loop when a temperature is found below setpoint, and copy that local boolean to the global temps_all_ok after the loop.


That is just a guess though; you don't say which subroutine you put into the periodic task, but if it is the ST subroutine and it was a higher priority than the ladder, then the ladder would never see the intermediate value (1) of temps_all_ok, which would explain why it works.
Click to expand...


Both subroutines are called in the same program in a ContinuousTask

MainTask (Continuous)
\___ AutoProgram
\-----------MainRoutine (called by progam)
|----------ST Routine
|----------Ladder Routine

MainRoutine:
-------------------[JSR: ST Routine]--------|

-------------------[JSR: Ladder Routine]---|


So basically it's sequential...

I must say I have also 2 PeriodicTask (10ms each) with one PID function each and 1 Safety Task (20ms)

Priorities:
ContinuousTask: 10
Periodic1: 10
Periodic2: 10
SafetyTask: 10
 
Another possibility, why step[1] and step[2] could appear to be 1 at the same time, is that whatever is being used to monitor those tags is running at 1-2Hz, so it is retrieving values at different times but displaying them at the same time i.e. as if they were retrieved at the same time.


The best way to get help here is to post the entire program in PDF form. Posting the program in binary (.ACD) or XML (.L5X), archived in a .ZIP to attach, will also help if someone wants to try it out, but PDF would be the most universal form.
 
Last edited:
drbitboy said:
Another possibility, why step[1] and step[2] could appear to be 1 at the same time, is that whatever is being used to monitor those tags is running at 1-2Hz, so it is retrieving values at different times but displaying them at the same time i.e. as if they were retrieved at the same time.


The best way to get help here is to post the entire program in PDF form. Posting the program in binary (.ACD) or XML (.L5X), archived in a .ZIP to attach, will also help if someone wants to try it out, but PDF would be the most universal form.
Click to expand...

Unfortunately is not the watch table refresh problem as I also traced both signals.
I can see the cycle going to next phase physically, because I have an actuator movement in the next step, so it's definitely going forward in the cycle steps.

I can ask for the program, as it's from a colleague, but basically the rungs that are causing the issue, are in the form that I posted earlier.

I tried putting the task on period 10ms and the problem is gone.. I can't figure out why at the moment, so if it works like this, I'll tackle the problem later (we have a rushing client as the machine will be put in production by the end of the month and we still don't have a mechanical-complete structure to test on. o_Oo_O)
 
IMHO you would do yourself a great favour by changing the "bit-driven" steps into a numerical sequencer, where a register holds a "step number".

It can only ever be on one step. You use EQU instructions to code your sequence actions.

You can easily step forwards by one step, just add 1 to the step number.

You can easily jump to any step in the sequence, just move the new step number into the step number register.

You can easily include "spare" steps by jumping forwards to (for example) the next 10 (or even 100 !) boundary. The spare steps will be invaluable later if you need to make modifications to the sequence. Don't forget a single DINT can hold 2,147,483,647 positive numbers, you will not run out of step numbers in a hurry !!

Sub-sequences (parallel processing) will have their own sequencer logic.

Outputs can be driven from the sequence(s) using LIM instructions on the step number(s).

You can make this concept as simple or as complex as you want, but the real advantage is you can make the sequencing logic (not the sequence itself) into an Add-On Instruction, called for each sequence. My preferred Sequencer "engine" also prevents the sequence being "forced" into starting, the simultaneous actions of it being on step 0, not running, and the "start" command given, all have to happen in the same scan, otherwise it will not start. This makes it as safe as it can be. With bit logic, it would be easy to set or toggle a sequence bit, and the sequence will start from that bit.

Another advantage, especially during testing, simulation, and sometimes commissioning (!), is that you can place the sequence into a "Hold" state, modify the step number, and bring it out of "Hold" at that point in the sequence incredible time-saver not having to toggle a bunch of bits !

But by far the biggest advantage is that you will always be able to see what step you are on at any time. This makes it great for programmers and maintenance technicians alike.

I started out my PLC life using bit-driven sequencers, and you had to have several peoples wit about you when working with them, especially if you were modifying the sequence actions (steps). When I was introduced to step-numbered sequences, it was a revelation, and I have never looked back.

I think I have an example hashed out somewhere, PM me if you want to see it. If I can't find it, I'll "extract" a simple sequence from a more complex job.

EDIT : You may not be able to change on this job, but think about it for the future, and you may have to convince your colleague !
 
+1 for doing as @daba suggests, at least for the next job. A similar alternative would be to BSL a 1 bit into step[0] initially, and BSL 0 bits after that.



We don't see where step[0] is latched to 1; also we don't know the number of steps e.g. is there a step 4? Without the entire program, we are only guessing.



Since these are all latches and unlatches, the most likely explanation is another latch (or even OTE) that is assigning a 1 to step[1] after the [temps_all_ok AND step[1]] unlatches step[1] and latches step[2]. I am sure you have already done a cross-reference check (many times ;)), but is it possible there is an indirect reference that could affect step[1]?


The only things we can be reasonably sure of are that

  1. the program is doing exactly what it was told to do,
  2. and what you want it to do is irrelevant once it goes into RUN mode.
 
Last edited:
drbitboy said:
The only things we can be reasonably sure of are that

  1. the program is doing exactly what it was told to do,
  2. and what you want it to do is irrelevant once it goes into RUN mode.
Click to expand...

:geek:

I once heard that as "I programmed it to do this, and it's doing that !"
 
Code: 
[FONT=Courier New]auto_on           step[0]                        step[0][/FONT]
[FONT=Courier New]----| |--------------| |----------------------|----(U)----|
                                              |  step[1]
                                              |----(L)----|

   temps_all_ok       step[1]                    step[1]
-----| |---------------| |--------------------|----(U)---|
                                              |  step[2]
                                              |----(L)---|

[/FONT][FONT=Courier New]pump_running       step[2]                       step[2]
-----| |---------------| |--------------------|----(U)---|
                                              |  step[3]
                                              |----(L)---|[/FONT]
gbautomazione said:
... but basically the rungs that are causing the issue, are in the form that I posted earlier.
Click to expand...


Not to put too fine a point on it, but from my own long and painful experience I can say that is almost certainly an incorrect statement, and further that as long as you think it is otherwise, you will continue to do this:

gbautomazione said:
o_Oo_O
Click to expand...


Now, I'm not saying you won't continue to do this o_O once you think otherwise, but at least it won't be for the same reason ;).


ciao.
 

Similar Topics

S
Rockwell Continuous Task
Can anyone explain to me why Rockwell thinks a Continuous task is better than a Periodic task? That is what it defaults to. It may cause your...
Replies
10
Views
2,905
JeremyM
JeremyM
P
timer in continuous task
I have a question in the rslogix 5000 timer. for example, I have a 1s timer in a continuous task. does it mean the timer is not actually 1s but...
Replies
4
Views
1,895
drbitboy
drbitboy
B
Changing a task from continuous to periodic L61?
I've inherited a L61 that was installed last year and the memory usage is well into the red. There is only one continuous task with a scan time of...
Replies
5
Views
3,760
Bob O
B
S
How to create delay in continuous task?(RSLogix5000)
I have a RSLogix5000 project that I need to test for various program sizes, in order to validate its robustness. I want to introduce delay in my...
Replies
14
Views
4,526
Salman S.
S
U
RSLogix5k continuous periodical task deciding
I've heard someone saying I should put as many programs/routines in the continuous task. I also heard others saying use as little continuous task...
2
Replies
18
Views
6,456
proof
P
Back
Top Bottom