Single Periodic Task Instead of Continuous?

[u/slow4low]

Doing support/contract work on behalf of my employer, machine I knew nothing about going into it. Had some motion problems with an AB servo, poor programming by the OEM. Studio5000, 1769-L36ERM. PLC controls 8 small assembly stations, organized into their own programs with program scoped tags. These programs are under one Periodic Task, with a period of 30ms. There is only this one task in the PLC. No other continuous or Event Tasks.

What's the purpose in having one periodic task, instead of continuous?

Reading through manuals, I understand the task period and priority level concerns for execution and avoiding task overlap, that a task ignores a trigger reoccurring within one task execution period. But what is the processor response if a Task runs longer than its' programmed Period, and it's the only Task? I'm no longer on site, and never looked at program execution time, unfortunately.

Mostly the question is academic for my purpose, I'd just like to know. As an aside, if processor performance can be assisted by changing to a continuous task, I'd do that. There seems to be some serious lag in the ethernet network, want to clean anything up I can, though not really in the project scope.

Thanks.

[u/janner_10]

It's extremely rare I would use a continuous task, maybe if it's a very small project.

Everything else will be in periodic tasks scheduled for how quick I need them to run.

[u/slow4low → u/janner_10]

Sure, that makes sense. I can't decide if they intended to break stations up into separate tasks, and simply never followed through? Or if there is a valid reason to set a period on a task, when it's the only task. Perhaps they were attempting to free up processor time for background processes like comm's?

[u/janner_10 → u/slow4low]

When using motion, it is wise to sync your periodic task time with the update rate of the motion group.

Same for pid loops, always sit better in a periodic task, then you can sync to the loop update time.

A continuous task is lowest priority and will complete as and when all others have finished, you have no control.

Having no continuous task won't effect Comms, as the SHS also interrupts the continuous task.

[u/gjk-ger → u/janner_10]

Does it really matter for a pid? As long as the pid-block knows the time since last the execution, everything is still calculated correctly.

[u/janner_10 → u/gjk-ger]

Yes for faster loops, from the RW Manual:

The easiest way to execute the PID instruction is to put the PID instruction in a periodic task. Set the loop update time (.UPD) equal to the periodic task rate and make sure that the PID instruction is executed every scan of the periodic task.

[u/gjk-ger → u/janner_10]

I dont see how that contradicts letting it run with arbitrary gaps and letting it know what the gap is. Easiest way, ok may be, but necessary?

[u/drbitboy → u/gjk-ger]

> As long as the pid-block knows the time since last the execution, everything is still calculated correctly

Assuming this is the case is an assumption that is a very common mistake.

***Some*** PLCs have PIDs that "know" what the actual update time is, but many do not. If you find yourself setting very long integration times (or very small Kd gains, e.g. 0.00000xyz) for tuning, this is most likely the problem.

[u/gjk-ger → u/drbitboy]

Obviously the block needs to have a mechanism for that or have a parameter that you need to supply correctly.

I think its worth it though, having the same variables used in both the continuous cycle as well as the time alarms can be a mess if one is not very careful, so id rather have no time alarms (or only those) at all if possible.

[u/Someone4350 → u/slow4low]

Tasks involve context switching which delays things… for motion, it may be an issue. If all stations should run at that same frequency it’s fine leaving it like that.

Maybe the logic is actually too little to run consistently in a continuous task? Not on Rockwell, but I had similar issues on an S7. Going from a PLC that took 40ms to run a program to one that took 3 broke the program due to infinitesimally small numbers being measured/calculated. That PLC had a 37ms idle function put in and worked like a charm (I was lazy).

Being in a periodic task gives you a lot more control over cycle time shenanigans provided you monitor for overlap.

[u/slow4low → u/Someone4350]

Task overlap... I failed to look at execution time and the overlap counter. But can the task overlap counter, increment, if there is only one task in the entire PLC?

[u/Someone4350 → u/slow4low]

It can overlap itself if it takes longer than 30ms.

[u/slow4low → u/Someone4350]

Thank you, this is what I wasn't sure about.

[u/halo37253]

I do everything in Periodic Tasks and this method has been recommended for programmers for decades now.

Granted everything in a single 30ms task is strange. For example I do all of my IO mapping in a 10ms program. No need to go any faster than that when your remote IO racks are not setup to talk faster. My remote 1756 racks for example are set to 10ms.

This allows for known execution times. As well as keeping logic in a time frame that makes more sense.

There is a lot of logic you dont need to run any faster than every 50,250,500, or even 1000ms.

[u/TalkingToMyself_00 → u/halo37253]

I love the organization but the benefits may not be experienced. Depending on the PLC and program size, these processors can execute 1000s of rungs so fast that the machine won’t notice, even in some motion applications. But, my version of small projects might be different than your version. To me, unless it’s actually time sensitive (mostly motion that is very precise) a continuous task meets all expectations.

But this isn’t to say that I won’t start doing more periodic tasks because, I do love the organization lol.

[u/slow4low → u/halo37253]

I do too, ordinarily. Even that I had looked at the execution times, 7 of the 8 stations were idle and unused as I worked on the 1. So it would've been difficult for me to change them all to periodic tasks, set an appropriate period, and ensure I wouldn't induce task overlap.

[u/No_Meet_6364]

Because anytime you do anything motion or time- sensitive than being as deterministic as possible is important.

With a small machine at an instant in time maybe you get away with no issues but stuff can change out in the field with network traffic or say down the road the PLC or serves get upgraded and all the timing changes because a continuous task was used instead of on a set cyclic cycle. This is pretty common going from legacy motion and PLCs to modern.

[u/slow4low → u/No_Meet_6364]

If determinism was the guiding factor, I find it a tad bit ironic. Their sequence logic was anything but deterministic, and that was the cause of the erratic servo behavior.

I wasn't sure how the PLC would handle a periodic task, if that task is the only task. From your response and one other commentors, I get the impression that the single periodic task will always retrigger based on it's period, and not behave as continuous (whether that trigger is honored is my next question). That is good to know, as I wasn't sure.

Someone else in here said that only having one periodic task, and no others, that saidf task can still overlap. As there aren't any other tasks to step on it/get stepped on, I'm now wondering the repercussions of the single periodic task overlapping itself. Does it ignore the trigger during scan and complete, or does it obey the trigger and restart the scan from the top? I'm assuming the former.

[u/BenFrankLynn → u/slow4low]

Your assumption of the former is correct. There's no trigger so to speak, as a periodic task isn't an ISR like an Event task is. The task scheduler will see that it's running still when it is supposed to be started again and will wait until the next period. If it finishes before that next period, no worries really. If it keeps running long enough to trip the watchdog --> problem.

[u/slow4low → u/BenFrankLynn]

Thank you.

[u/RULVFF → u/slow4low]

Check the Logix/Studio 5000 Document, there is graphic showing how things work when overlapping.

One common item are: Stop using Continuous Task in new/retrofit projects, it will be removed in future, If I remember correctly in Processes CPU with P letter it already Removed.

[u/nakednhappy → u/RULVFF]

It's removed if you use the "user plantpax task model" checkbox.

[u/slow4low → u/RULVFF]

Thank you. I saw it, just wasn't sure how it was handled if there was only one periodic task in the PLC. I understand now though.

[u/DeadlyMoldSpore]

Let's say you have a continuous task with a 10% overhead time slice. Now let's say your task executes in 1ms. That would give the PLC approximately 100 microseconds to service communications and all the other overhead it has to perform between scans. This will cause the PLC to jump back and forth a lot. In the above scenario the PLC will bounce back and forth between logic and overhead about a thousand times a second.

Now let's say you only need to scan the logic every 10ms. Assuming it still takes 1ms to scan all the code, that leaves 9ms to service communications and other overhead. In this scenario, it will bounce between the two about 100 times per second instead of about 1000 times per second.

Periodic tasks are way better for comms and overhead.

[u/Tnwagn → u/DeadlyMoldSpore]

This is the perfect response. I understand why continuous tasks are available but with they were a "Enable option" rather than an out or the box option.

[u/slow4low → u/DeadlyMoldSpore]

Thank you.

[u/seekingsanity]

"As an aside, if processor performance can be assisted by changing to a continuous task,"

I wouldn't. Other have already mentioned that it is best if the everything is deterministic. Another issue you didn't mention is if the 8 stations need to be synchronized. If not, then you have another option which is to stagger the execution of each axis to even out the load. Execute a task for 2 axis every 5 milliseconds. It would take 20 ms to get around to all 8 axes. Also, 30 ms seems a little long. I delt mostly with control logix in sawmills where every millisecond matters because a piece of wood could be processed every 2 seconds or less and the 30 milliseconds would be a large part of 2 seconds.

What are the RPI ( requested packet intervals ). Those should be kept short too but making them too short will overload the PLC.

A lot depends on your application requirements.  

[u/slow4low → u/seekingsanity]

Thank you for the response. I see why now, from everyone's help, why changing to a continuous task would be ill-advised. If I could help it, I'd maybe put each station in its' own periodic task.

There is only one motion axis in the entire cell. 5 of 8 stations are operator manual assembly, only 3 are real automation. All 8 stations are independent. They can run one station all day (no point, but they could), or all 8 stations at the same time.

Several RPI's are at 20ms for handheld code readers, 10ms for a handful of Cognex cameras. One suggestion we have made to the customer is to reevaluate those. 10ms on an electric nutrunner (think atlas copco/stanley) that runs once every 90 seconds. 30ms isn't terribly fast, but it's faster than they need it to be.

[u/Verhofin]

Genuine question, except for motion I see all brands using periodic tasks, but why is it so recommended for Rockewell? Is it the IO update? Example, in Siemens most programs, again except motion, run on OB1 no issue, that is continuous.

What is the big difference?

[u/Flimsy-Process230]

With periodic tasks you need to make sure the task execution time is comfortably shorter than the configured period. If the task is scheduled every 30 ms I would not want it routinely taking anywhere close to 30 ms to complete. Personally, I like to see plenty of margin, ideally well under 50% of the period under normal conditions.
If a periodic task takes longer than its configured period you can start getting task overlaps. Logix controllers keep track of this so you should be able to see overlap information in the task properties. If execution gets bad enough to exceed the task watchdog the controller can fault.
What I see more commonly is a Continuous Task handling the normal machine sequence with Periodic Tasks used for logic that actually needs deterministic timing. Higher-priority periodic tasks can interrupt lower-priority execution as required.
Having the entire machine under one 30 ms Periodic Task and no Continuous Task is a little unusual but there is nothing inherently wrong with it. I’ve seen machines programmed that way before. It basically guarantees that the main logic executes on a predictable 30 ms schedule rather than as fast as the processor can cycle it.
I also wouldn’t change it to a Continuous Task because of the Ethernet lag. Ethernet communications are handled by the controller independently of whether your machine sequence is in a Continuous or Periodic Task so changing the task type is unlikely to solve a network problem.
For the Ethernet issue I would look at the network itself first: hardware problems, bad cables or connectors, cable routing/noise, switch configuration or too many devices generating large amounts of traffic can all contribute to poor network performance. I’d check those things along with controller and network diagnostics before changing the cpu task.

[u/slow4low → u/Flimsy-Process230]

Thank you for the detailed response, I appreciate it.

Regarding ethernet, they have a bunch of things that could be optimized. 2 16-pt unmanaged switches without a single spare port, star topology. RPI's set, not crazy low, but lower than they need to be for the application. Cables look good, all STP. Wireway is FULL FULL, so not the cleanest cable runs for ethernet media.