Cycle time for a controller

Just something I was thinking about today... Are there any general requirements about cycle times for industrial controllers? What should be considered as safe? Where I something have problems with is that I always try to choose the controller to use in an application as economical as possible ( lets say i'm looking I can have the required memory with that controller, then communication possibilities and sometimes the amount of instructions / ms ).

I was today programming on a siemens 414-2 DP and was notifying that I was having a run cycle time of about 32 ms which looks nice? Another Siemens controller 315-2DP I was busy on had a run cycle time of 76 ms which was kinda much in my eyes - however that reaction of the controller still occures in 152 ms in worst case scenario, faster than me on a monday morning ;-) ( Long cycle time 'cause of lots of calculations and loops with pointers ).
It this fast or slow ? Other controllers I work with are Allen Bradley Mitshibusi & OMRON which gives me mostly very low cycle times ( lets say 10 ms ) as I use those mostly for easier programs. B&R controllers have the adventage of constant cycle times you can set.

Would you think it would make sense to choose a faster CPU just to reduce your cycle time?

Just my thoughts,
Flukie

As is often the case, the answer is "It depends."

You first have to look at the process you are trying to control. In my case I have a very slow process, and if my response time gets to a couple of seconds (although this has never happended) it wouldn't effect the accuracy of the control. On the other hand, if you are doing high speed positioning or packaging if you have a response time approaching 100 ms it could mean trouble.

Bear in mind that even in high speed applications most of the logic (alarms, operator notification, etc.) can stand a response delay of several hundred ms. Most PLCs let you use an interrupt routine for time critical portions of the logic, and you can let the rest of the scan run longer.

There is no advantage to using a faster processor if the process or machine response doesn't require it. It is easy to get into a "faster is better" mind set, but the end user doesn't pay for CPU cycle times. They are buying machine function or process operations.

Flukie,

as Tom stated: it depends. It depends largely on the output interfacing. If you are using relays, I wouldn't worry, because relays have activation times which can easily reach 50-60ms. I for me don't worry until there's a need to. And you mostly know soon enough banghead !

You could revert to the new AB controllers if there is an IO cycle issue. The CompactLogix and ControlLogix controllers are asynchronuous controllers. The IO cycle is not synchronised with the program cycle. I know that for the CompactLogix series the IO are refreshed every 2ms, independant of the program cycle time. The IO's are simply refreshed with the values calculated at the time of the refresh. It's a bit awkward at first, but I have learned to live with it.

Kind regards,

Jean Pierre Vandecandelaere

Flukie,

I am in agreement with the first two. It always depends. One thing that most scan times is dependant on is the size of your program...yes size does matter in this case...lol.

With many PLC manufacturers, they provide you with basic instructions that they state have a specific scan - say 5 micro seconds for a normally open contact. For complex instruction that they have provided one key or line of code, the scan time would be longer.

Also mentioned previously, was the response time of your outputs and output devices. PLC relay outputs are rated from on to off or off to on at 8-15 ms. Solid state outputs are much faster, in most cases 1 ms or less.

If you have a long program that takes 50 ms to process, the response time of the outputs is not as important. If you are using an interrupt, then your output response time would be more important.

Our controllers offer a scan rate of 5-15ms / 1K compiled ladder code. If your program length is 3K compiled - it will complete one scan in 15-45ms (depending on the controller)

There are ways to improve your scan time through efficient programming. I'm not certain about most manufacturer's programming software, but we provide the commands "jump if zero" and "end jump". This allows you to tag portions of your program that are not always used, in essence, a sub routine. If the PLC sees a zero in the register associated with the jump command, it will bypass that section of code until it sees the "end jump" instruction. This method will improve your overall scan time. Using the jump command effectively, can give you the minimum scan time for your application.

God Bless,

Stephen Luft

Cycle time - AB shines

I am not so sure what is meant by 'constant cycle times' on B&R
controllers? For example if your ladder logic requires only 2 ms of processing time and your B&R cycle time is set for 10 ms, does that
mean that B&R processor will not begin next ladder scan until 10 ms
expires? That makes no sense to me. How can that be advantageous?
What happens if the required ladder processing time is larger than 10 ms?

Mr. Luft's suggestions relating to jumps within the ladder program
are in essence referring to an 18 year old technology.
I am not saying that there is anything wrong with that approach,
however the state of the art controllers have a better way of
optimizing your controller's scan times.

AB's Logix5000 will allow you to assign priorities to your tasks
and set up tasks as scheduled or unscheduled.
Scheduled tasks can be periodic or continuous. Periodic tasks
can be set-up for scan times as low as 1 ms.
In other words, your mission critical ladder can be scanned every ms.
You can also allocate more or less time for processor overhead
tasks. It's called 'time slice' setpoint.
In some instances you may need more processor overhead time for example to deal with lots of network data coming in.

Logix5000 is a leading edge technology processor allowing you unparalleled flexibility in customizing your application and optimizing processor's performance.

The bottom line is that you should also use AB for most complex programs and not just for "easier programs" as you put it.

Try it, you may like it.

You bring up an interesting point about the AB 5000's.

There was a discussion recently trying to determine what possible use having I/O coming in the the logic asynchonous to scan was.

But what you are saying about assigning tasks (which I read as subroutines, as I know them under 5/500) as having different scan rates, means that if a bit is set in one task, and used in two other tasks, I can't be sure of my scan order, and (a bad programmer - not me) could inadvertanly create scan races, and all sorts of problems.

This would be especially true of one-shots, which are not one-SHOTS, but one-SCANS. If the task that sets a one-shoted coil is updated twice, before the task that uses it is updated, then the later task will never see that bit being ON (Scan 0ne will set the bit, Scan Two will reset it).

I understand why AB made the 5000 the way they did - essentially to allow more than one STI program file, and the IIN (Immediate Input) instruction.

But once a can of worms is opened, it's hard to convince all the worms to get back inside.

If programmers start thinking of playing with the frequency of updating tasks ("Mission Critical"), then all heck is going to break loose when those tasks interact.

FULL DISCLOSURE STATEMENT: I've never actually used a 5000, so I really don't know what I'm talking about. In my ignorance, I may have gotten something wrong. If so, enlighten, not flame, me.

About scan(cycle) time

I have some experience in chemical industry, artifical fertilizer producing company. I worked as the head of the electrical and pneumatical maintenance team as an electrical engineer . Why am I stating this?
The only reason is that I have met problems on field which were caused by the inconvinient (to long) scan time. The signal's period we wanted to count(!) was about 10 ms which altered. I am telling again the period was 10 ms. And the scan time was about 15-20 ms. The solution was a modul that lived for itself and could manage counting with such a speed (and much faster). And this conception is nothing new. A understand that someone would like to know the manufacturers name but I can't state it's name and it is inrelevant for this issue.
The industrial needs for the scan time are at most 100 ms. This is not a standard nor it is an apsolutely exact statement. Just trust me.
If the PLC's scan ime is greater because the program is so complex and of course that is usualy the only cause then there are many solutions. The simplest way for a programmer especially for an automatian is if the company ,which requires PLC approach, has enough money and he or she simply says the solution is more CPUs. Thats how we could achieve scan time with less than say 30 ms in most difficult cases. This is so simple. The other solution is putting in special counter modules for application where necessary. Omron for example has modules which count signals at even 500 kHz and process them with interrupting technique. And this is again nothing new.
But there is a trick which are not told to too much people. In a PLC's scan time there are included many other things besides program processing and I/O reading/refreshment. One of these things are that say by deffault setting (and this can be altered of course) 25% of cycle time is spent for the serial port communication handling. If you dont need peripherial communication for a suppervisory program (i.e. SCADA programmes) then set it to 0%!
I say, too that this subbjest is negotiable. But if you have cycle tame of more than 100 ms then the solution can, could, would and usually is a faster CPU. And my oppinion is that if you had hundred and something more miliseconds of scan time with that Siemens PLC then it is possible that something (the hardware) is malfunctioning. Or the programming concept you used is a bit wrong (I even declare it is very bad, sorry ,nothing personal).