RSL5k - Oneshot from continuous task to timed task

I know Rockwell is trying to steer users into using multiple timed tasks instead of the old standby of having one continuous task as a way of reducing the processor overhead.

So what happens if you energize a oneshot in one task (continuous or not), and then have an XIC contact for the oneshot on another timed task that updates at a different rate? Does the contact simply never get triggered or does the oneshot storage bit "wait" until all tasks have examined the bit?

I'm writing some Logix5000 ladder right now, but don't have a processor handy to test this.

Thanks!

It will absolutely either be triggered, or not, or only triggered sometimes.

If you have something that needs one-shot communications across task type boundaries, then in the triggering task, latch a bit for each 'slave' task to read, then have the slave task unlatch it when it is noticed.

And there is no reason to use timed tasks for everything, or even most things. Use timed tasks were, well, you need a timed task.

Thanks!

Yes, I absolutely prefer having everything in the continuous task unless there is a need to pull it out (PID, etc). I sat in on a training where the rockwell instructors recommended everything be moved to timed tasks so they would only scan as fast as required for the responsiveness needed, instead of constantly. I haven't seen a need for that yet, but I'm not running a chemical plant on one processor or anything.

The basic idea behind using timed tasks instead of continuous is:

Continuous task causes the processor to always run at maximum utilization. This means as you add more instructions to your program, everything else already in the program slows down just a bit. Your program is usually executing way faster than it needs to so this is usually not a big problem. However, at some point some part of your program may start running a bit slower than it needs to. Then you have a problem.

Periodic tasks allow you to not use up all the processor power and let it idle in between executing your task at a rate that is plenty fast for your needs. When you add more instructions to your program, the execution of everything else is completely unaffected. That is until you completely load the processor. It also allows you to segregate things that need fast execution from things that can run slower. This avoids the issue where the entire program has to execute fast enough to suit your most time critical function.

And I agree 100% with what rdrast said about using a latched bit to communicate between tasks. I would not trust a one-shot outside the program it was set in.

rupej said:

Thanks!

Yes, I absolutely prefer having everything in the continuous task unless there is a need to pull it out (PID, etc). I sat in on a training where the rockwell instructors recommended everything be moved to timed tasks so they would only scan as fast as required for the responsiveness needed, instead of constantly. I haven't seen a need for that yet, but I'm not running a chemical plant on one processor or anything.

Click to expand...

And that's why they're instructors and not field engineers/programmers

robertmee said:

And that's why they're instructors and not field engineers/programmers

Click to expand...

There was a thread here a few weeks back where there was a lively discussion on Continous vs time task in logix processor. One gents said that one should NEVER use continous task because that will cause unexpected operation. I was quite surprised at that assertion. I think he work primarily with motion control. Afterward with more thoughts on this, this is what I think...

My own take on this is that often folks speaks on issues with unstated but critical premise. Example, I started in the DCS world and if one program a PLC like they program a DCS, all sort of funky and unexpected thing will happen. I realized that programming in ladder in a continous scanning environment does impose certain "grammer", for example, you can't put OTE in multiple places. A good portion of the folks here came out the PLC5/500 environment where timed task isn't even an option unless you count in STI. We deveoped our own "grammer" to program a certain way as not to cause "unexpected operation" in a continous scanning environment without conciously thinking about it.

just my 2 cents,

Timed tasks are critical for large/intensive programs.

Doesn't apply with the latest firmware but there used to be a 100 program limit for tasks. Once you hit that you had no choice but to used timed tasks. When I was doing big projects in batching it wasn't uncommon to have over 200 programs. So you had to break it up into tasks. We also had some logic which looped through all of the phases and equipment process to constantly check for operation faults and to update equipment status and do checks for product compatibility. This logic was very intensive and did a number to the overall scan time of the PLC it was in the continuous task. This logic didn't need to run at 20ms. Simply moving this logic to a 500ms task allowed the rest of the logic scan time to be reduced greatly.

Timed tasks also allow you to better understand where your CPU intensive logic is. It also helps to ensure you have a good visual of CPU availability for external process actions like communications. The Task Monitor Tool is a tremendous diagnostic, but some performance items will be masked by a continuous task because the CPU is 100% utilized all the time. So it's harder to understand what the logic impact really is on a CPU.

I no longer use a continuous task if I don't need to. Small programs or conversions I might just to maintain original operation but my experience shows an advantage over continuous tasks.

Getting back on topic ever so briefly...............

When the one shot triggers, it affects a tag. Now assuming that tag is a Controller tag and not a Program/Local tag, that tag can be examined in any task/program/routine. Where the tag was made a 0 or a 1 doesn't matter. When you are examining that rung and that XIC, all it cares about is 1 or 0. How it got there is not relevant to the controller at that point in time. It might be to you, but not to the controller.

And now off topic.....

I don't think Rockwell is trying to steer you to use one method or another. Like pretty much any company, they find out what people want and try to provide it if they can. In some applications a continuous task makes perfect sense and you wouldn't want to do without it. But in other instances, it may not be necessary.

In a training class all too often you are getting that person's opinion. Not necessarily that company's opinion. It's not right, it's not wrong, it is just their preference. As a longtime instructor (and programmer and field service) myself, I always tried to show you both sides of a topic and try to point out the pluses and minuses for each. If you asked for my preference, I would tell you what I prefer. For example, I grew up on the concept of the continuous task (before it was ever called that). I would be inclined to always use it. But others might not. It's just my preference based on my background and experience. But I can also see the benefit to what Paully's5.0 nd others are saying.

OG

I have a question: Say you have one continuous task with a number of programs, and one timed task with a number of programs. When the timed task is called, does the continuous totally stop mid-scan until the ALL of the programs in the timed task are finished, and then resume right where it left off?

What if a timed task is running, not finished, and another timed task is called on top of it? Does it remember where it was and come back?

Thanks in advance!

mellis said:

The basic idea behind using timed tasks instead of continuous is:

Continuous task causes the processor to always run at maximum utilization. This means as you add more instructions to your program, everything else already in the program slows down just a bit. Your program is usually executing way faster than it needs to so this is usually not a big problem. However, at some point some part of your program may start running a bit slower than it needs to. Then you have a problem.

Periodic tasks allow you to not use up all the processor power and let it idle in between executing your task at a rate that is plenty fast for your needs. When you add more instructions to your program, the execution of everything else is completely unaffected. That is until you completely load the processor. It also allows you to segregate things that need fast execution from things that can run slower. This avoids the issue where the entire program has to execute fast enough to suit your most time critical function.

And I agree 100% with what rdrast said about using a latched bit to communicate between tasks. I would not trust a one-shot outside the program it was set in.

Click to expand...

Sadly, I did not save a copy of my results, but I converted a ContTask program to a PeriodicTask, and the results (as reported by the processor) seemed to indicate that there was a slight advantage, time wise, to this approach. I repeated my test in both directions and found that I could remove 6 mS from a 64mS scan. This was a ControlLogix, 4MB memory, with bunches of comms, etc., so it may not apply universally. But, my conclusion was that it appeared that the processor was much more efficient at moving between Periodic Tasks then it was always interrupting the ContTask (of the old way). It made me a believer. Of course, once you abandon the ContTask concept, you can actually use the Task Monitor Tool, which shows you in great detail, what is actually going on.

Now that you mention it, switching between periodic tasks quicker WAS one of their points for why it was a better way to program.

My problem is that I like to map all inputs to force a syncronous scan- having only periodic tasks would screw that up, wouldn't it?

rupej said:

I have a question: Say you have one continuous task with a number of programs, and one timed task with a number of programs. When the timed task is called, does the continuous totally stop mid-scan until the ALL of the programs in the timed task are finished, and then resume right where it left off?

What if a timed task is running, not finished, and another timed task is called on top of it? Does it remember where it was and come back?

Thanks in advance!

Click to expand...

Yes, the continuous task will freeze where it is and run the periodic task. The periodic task will run start to finish one time only. Then the scan returns to the continuous task where it resumes where it left off.

If you are scanning a periodic task and another periodic task needs to execute then the priority you assign both determines whether the current task continues executing or if the scan jumps to the higher priority task.

The scan will automatically return to the suspended task and resume.

OG

rupej said:

Now that you mention it, switching between periodic tasks quicker WAS one of their points for why it was a better way to program.

My problem is that I like to map all inputs to force a syncronous scan- having only periodic tasks would screw that up, wouldn't it?

Click to expand...

Typically, I have 3 tasks:

Control module code in one task (everything that will actually have an I/O reference, except PID loops). The first program in that task maps my inputs. The last program in that task maps my outputs.

Higher level code: equipment modules, sequences etc. are in a separate task.

PID loops are in a separate task with its own I/O mapping.

This is very similar to what Rockwell recommends for PlantPax design.

jdbrandt said:

Sadly, I did not save a copy of my results, but I converted a ContTask program to a PeriodicTask, and the results (as reported by the processor) seemed to indicate that there was a slight advantage, time wise, to this approach. I repeated my test in both directions and found that I could remove 6 mS from a 64mS scan. This was a ControlLogix, 4MB memory, with bunches of comms, etc., so it may not apply universally. But, my conclusion was that it appeared that the processor was much more efficient at moving between Periodic Tasks then it was always interrupting the ContTask (of the old way). It made me a believer. Of course, once you abandon the ContTask concept, you can actually use the Task Monitor Tool, which shows you in great detail, what is actually going on.

Click to expand...

I'm guessing here, but the continuous task is hampered by overhead that the timed task is not responsible for. That "system overhead time slice" is stealing time from the continuous task all the time. Continuous is really a misnomer. It's the only task that is being interrupted constantly, even without another user task assigned.