Rockwell Continuous Task

[sparky66]

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 code to run as fast as possible, but it doesn't guarantee that it will run the same every time. Isn't the point of a deterministic system the consistency it provides? What if a subroutine gets called occasionally? That means the rest of the code runs at different time intervals.

 

[harryting]

Search and you shall find tons of discussion on this topic. No, I don't think Rockwell ever said such thing AFIAK.

However, the way your framed question does make me want to jump in.

- why wouldn't a code "run the same every time"?
- why wouldn't you want to run the code "as fast as possible" well, it's more like repeat as often as it can? I can think of lot of instance where that's desired.
- A subroutine is a subroutine that you call as needed. I don't see how that's related to "rest of the code runs at different time intervals".

 

[sparky66]

I am really referring to the time interval between scans. If you have a main program that takes 2ms to run, but it occasionally calls a subroutine that takes 1ms to run, then the main program time interval is now 3ms instead of 2ms. I don't know of all the ramifications of that, but I think code that relies on EIP could be affected. EIP has an RPI that is periodic, but the code that uses it isn't. That doesn't seem right to me.

 

[rupej]

I am really referring to the time interval between scans. If you have a main program that takes 2ms to run, but it occasionally calls a subroutine that takes 1ms to run, then the main program time interval is now 3ms instead of 2ms. I don't know of all the ramifications of that, but I think code that relies on EIP could be affected. EIP has an RPI that is periodic, but the code that uses it isn't. That doesn't seem right to me.

This is a debated subject. But in your example, the same issue happens whether the main subroutine is continuous or periodic.


One thing to consider is that the periodic task has a risk of being called again before it finishes, if its period is set too low and it gets interrupted. That can't happen with a continuous task.

 

[sparky66]

This is a debated subject. But in your example, the same issue happens whether the main subroutine is continuous or periodic.



One thing to consider is that the periodic task has a risk of being called again before it finishes, if its period is set too low and it gets interrupted. That can't happen with a continuous task.

Not if you set the period correctly.


I am not a Rockwell expert, but priority setting would determine interruption of a task. It a period is set too low, and it doesn't finish in the right amount of time, it should watchdog. It is fine to get interrupted as much as needed, but the periodic portion needs to be consistent. It should easily come in and out of that task before it finishes. That is not a problem.

 

[Ken Moore]

Siemens PLC's have the same setup.
Unless you purposely place code in periodic OB's, it all runs in one continuous OB .

PCS7 is different, all logic runs in a periodic OB by default.

 

[travispedley]

I avoid async IO by using a mapping subroutine for all I/O. That guarantees it doesn't change during the scan, no matter the cycle time.
Call Input Mapping
Call Code
Call Output Mapping

 

[drbitboy]

I am really referring to the time interval between scans. ...

It may cause your code to run as fast as possible, but it doesn't guarantee that it will run the same every time. Isn't the point of a deterministic system the consistency it provides? What if a subroutine gets called occasionally?

Ah, now we get to the root of it.

What was the original raison d'etre of the PLC; was it to provide a time-deterministic system, or was it to model and replace a physical relay process at GM Hydramitc with response times of 100ms or better?

If the spec is 100ms or better, why do we care if the scan time is 2ms or 3ms?

Sure, now that PLC scan times are down in the ms range, people will try to use PLCs to control faster processes, but I suspect that is not what most PLCs are doing. And if the process is too fast e.g. some motion control applications, PLCs cannot cut it*, and a different approach, hardware, and software, are required.

* at least not without special motion-control add-ons, which operate in, or at least closer to, real-time, outside the scope of any continuous and periodic tasks, while those tasks take on a supervisory role wrt the add-ons instead of directly controlling the proces.

 

[rupej]

EIP has an RPI that is periodic, but the code that uses it isn't. That doesn't seem right to me.

RPI periods aren't exact or consistent either, so it's a moot point. They are also asynchronous to the program scan.

 

[jstolaruk]

but it occasionally calls a subroutine

These raise the air on the back of my neck and gives me a shiver.

 

[JeremyM]

A duplicate of a another tangentially related topic here showed up on Reddit, so I’m going to copy/paste my response:

If messaging code is properly conditioned, the task it resides in won’t matter.

We generally put application/process/device logic in the continuous task, maximizing its I/O exposure. While Class 1 connections occur at RPI or greater, it never hurts to catch and respond to IO updates as fast as possible, especially from the backplane.

I also avoid buffering because it subjects the system response to a scan time that grows with complexity and, ironically, adding buffering routines.

System utilities (Modbus TCP handlers, system configurators, diagnostics, stuff like it) stuff tend to sit in a 10ms or so periodic task.

The hardware is built for 24/7 100% use, may as well dive in!