WooshWell if something is critical you wouldn't put the code in a 100ms periodic. You have to have a little common sense on this. Maybe for you then continuous is the way to go.
WooshWell if something is critical you wouldn't put the code in a 100ms periodic. You have to have a little common sense on this. Maybe for you then continuous is the way to go.
Not necessarilly if the PLC in question is a safety controller. But an E-stop was just an example, the same concept holds true for position switches, alarms, etc.
I think we can agree that for a particular section of code, the continuous task will always scan more often than a periodic task. That has to be true, unless you are OK with getting overlaps in the periodic task.My explanation holds true for that as well... Mainly because faults impact cycle time and you probably wouldn't want to depend on the continuous cycle for some things to be checked.
My second thought is that if everything was periodic or event-driven, what is the processor doing for the rest of the time ?
The answer is in the file Maxkling posted, look at the end... it just hangs out playing video games.
I used to be in the same boat, everything continuous. But, then I tried periodic and it has worked out better for large programs. My opinion, there is not really a right or wrong. I also don't think everyone will agree with either side.
Can you point me to where RA states this? I have heard the same, but haven't seen this written anywhere.
Thanks daba, you proved my point!! You aren't going to change my mind or opinion, probably as mine won't change yours...
My main reason to respond to your post was to answer your question on what is the processor doing for the rest of the time? As I said, it's at the bottom. What else would it being doing??
NOTE:
If there is no continuous task, the time slice setting has no effect. All processor time not used for other tasks will be used for background operations.
That document only explains how the SOTS impacts on the running tasks, it does NOT advocate not using a continuous task at all.
But the longer the scan time, the longer it takes to respond to the input. If your program's scan time was 16ms, and it scanned 0.1ms before the input went true, it wouldn't see the input until it had been on for 15.9ms. If the scan time was 5ms, it would only have been on for 4.9ms before it noticed.And, think of an AC-Input module, local or remote...why in the world would anyone ever, under any circumstances, sweep that module any faster than 16mS? If your program executes in 5 milliseconds, you just gather stale information that was never going to update anyway.
That is interesting. Was this on a pre-L8x or 5059-series processor? One reason for a faster scan time on a periodic task could be that it was no longer being interrupted by the system overhead time slice. That could be disadvantageous, depending on the situation.I found out, by experimentation, that if you have a MAIN routine, and you make it run in a Periodic Task, vs. a Cont. Task, it will actually run a wee bit faster. I had a program that went from 62mS down to 58mS.
Let's imagine this scenario, you have a continuous task that scans at a 40ms rate. Should, let's say an IO module or a communication function hang, the cycle time will increase and potentially be outside what you deemed acceptable.I think we can agree that for a particular section of code, the continuous task will always scan more often than a periodic task. That has to be true, unless you are OK with getting overlaps in the periodic task.
Why would you spend thousands of dollars on a processor to have it sitting idle for a percentage of the time ?
Let's imagine this scenario, you have a continuous task that scans at a 40ms rate. Should, let's say an IO module or a communication function hang, the cycle time will increase and potentially be outside what you deemed acceptable