about periodic tasks

chad k

Member
Join Date
Aug 2005
Location
edmonton
Posts
16
In an AB documentation explain the periodic tasks, the following is listed:
"In the past the function of a periodic task was accomplished by placing multiple copies of some select code within the continuous task. The code was placed at appropriate intervals so that the input would be detected and outputs controlled."

can anybody help me out to understand this?

Thanks a lot!
 
Consider a standard ladder logic program. During execution it takes 50ms to complete 1 scan. But you have an operation which must be evaluated at least every 25ms.

So you could put the logic into a subroutine and call the subroutine twice during the scan execution. Another way would be to place the complete code twice in the main ladder at spaced intervals (this second is directly what is being described in your quote).

In either case in order for the routine to have fresh data you would use any "immediate input" functions which wer available and any "immediate output" functions to make the results available in a timely manner.

The "Periodic Task" is one which is called based on a time clock and interrupts the operation of the main scan. So it fulfills the function of the multiply called subroutine.
 
thank you for your reply.

It is the "immidiate I/O" concept light me up. I guess it is I/O that is configured not restricted by the regular scan time. is this right?

thanks again.
 
At least in Allen Bradley SLC500 and AutomationDirect a copmmand is available to cause an input to be re-read at the moment of the instruction's execution. There are also output instructions which do the same, an immediate update. The take a lot of extra CPU time an in some cases do not update the image that the rest of the ladder sees. But this is necessary for possibly multiple instances of the same code (either by multiple copies or multiple calls of the same subroutine) so that the code isn't just doing exactly the same thing - making its multiple call pointless.

In a machine we made which applied glue based on an encoder count a subroutine which did an immediate update of the encoder count for inputs and an immediate update of the glue solenoid as an output was called multiple times.
 
In an application in a SLC500 where we are counting gear teeth with a proximity sensor the following code can be found in four places in the program.



--------------------+-IIM------+-
|SLOT I:3.0|
|MASK 08h|
|Len 1|
+----------+

I:3/3
---] [--------------+-CTU------+-(CU)
|C5:8 +-(DN)
|PRE 48 |
|ACC 0 |
+----------+





By placing this code four places in the program we don’t miss any gear teeth, however if it was only once we would miss teeth. Note that the CTU instruction can appear more than once operating on the same address. By placing it in four places and performing an immediate IO update for the proximity switch we can detect the true-false-true transitions and increment the counter ACC accordingly. (if you don’t understand why this works look up the instruction and refer to the .CU bit)



In a Controllogix PLC I have two options. I could configure the IO module for a fast update rate and place the code just once in a periodic task executing at a rate that is faster than the gear teeth can pass the proximity switch or, better still, I can place logic in an event task which will be executed by an event generated by the IO module every time the input changes state.
 
Last edited:
Alaric said:
In an application in a SLC500 where we are counting gear teeth with a proximity sensor the following code can be found in four places in the program.



--------------------+-IIM------+-
|SLOT I:3.0|
|MASK 08h|
|Len 1|
+----------+




Note the Mask function in the IIM instruction. This is important if you have several inputs that need to be monitored. If you place all of the inputs on a single input card, you can check part of, or the whole card, without having to use two or more IIM instructions. In one case, I had to move inputs/outputs in order to allow a single IIM / IOM (output)each.

Placing the same logic, in multiple places will work, but the STI is a much more powerful tool. It makes sure that your selected code is processed at a regular timed interval that you can set, with of course some restrictions.

Funny thing, during a Rockwell Software Training session, the instructor pointed out what an STI was, then told us that we would not likely ever use one, or see one used. Famous last words. Several years later, I did find one, and then used one in a different program to solve an issue that had nagged me for seven years. If you have a time critical situation, consider the STI. With SLC500, you only get one, but with care, it can work wonders.

 
Hey Bernie,


Spray Lines are fun aren't they? My first real projectin the plywood world as changing out a flying say, and rewriting the saw logic. :D
 

Similar Topics

Curios on the thoughts of using Continuous vs Periodic tasks. . The old SLC-500's mostly only had Continuous tasks. . The Compact & Control...
Replies
49
Views
13,791
Hi everyone, Suppose I have a periodic task to trigger some communications, and in this task I have a pointer that iterates for each...
Replies
3
Views
1,304
The original file uses a STI and I/O interrupts {micrologix1500}, but when I create them as a periodic tasks in studio5000 I get warnings routine...
Replies
3
Views
1,263
Hello, Monitoring my system with the Studio5000 Task Monitor I see a yellow banner "Continuous Task is present, resulting in 100% CPU...
Replies
78
Views
34,953
Hello. I'm trying to figure out if it is better to have multiple PID loops in 1 periodic task, or have several (5) periodic tasks? I'm thinking 5...
Replies
4
Views
3,610
Back
Top Bottom