Rslogix5000 scan time improvement

I know that putting coils in series instead of branches and starting a rung with the less likely condition to be true has a good effect on scan time.
What other tips and tricks that will improve the scan time?
Thanks for sharing your knowledge

AB PLC's don't seem to lend themselves nicely to this due to the limitations of accessing data between programs, but sometimes you don't need to run all the logic really fast.

A temperature probe or even the temperature PID can be run at 1 second intervals for most industrial processes... you can move that part of the code to a program that runs in 1 second intervals and that will reduce your program's cycle time... mostly.

tarik1978 said:

I know that putting coils in series instead of branches and starting a rung with the less likely condition to be true has a good effect on scan time.
What other tips and tricks that will improve the scan time?
Thanks for sharing your knowledge

Click to expand...

1. Move code that doesn't need to be scanned at a fast rate to periodic tasks. (as cardosocea suggested). It is not required that the application has a continuous task at all, everything can be programmed into periodic and event tasks.

2. Don't continuously scan program code when it is not needed, e.g. the sequencing logic for a step-sequencer need only be scanned if the sequence is active. I have worked extensively on plant that has "Process" sequences, and CIP or IPC (Cleaning-In-Place or In-Place-Cleaning) sequences. Often these are mutually exclusive, so they don't need to be scanned at the same time.

3. Input branching - place the branch most likely to be true as the top branch. This has a marginal effect, as the lower branches still need to be scanned, in case there are any output instructions on them.

4. Avoid using instructions with a "Control" tag (i.e. Timers, Counters, FALs etc. These have to be 'executed' even though the rung may be false. If you can find another way to do the logic you need, it will most likely be faster.

5. You can mix conditional and output instructions anywhere on the rung. Compare Picture1 and Picture2 - they both perform exactly the same function, but Picture2 will execute faster, and has 2 fewer instructions (Picture1 has 6, Picture2 has 4), that's a 33% saving just on one rung !!


For the uninitiated, the two "tricks" tarik1978 quoted have the following reasoning....

1. "Coils in series" - you are using less instructions in the code. The ladder representation only hints at the fact that the branches are actual instructions that the controller has to scan - such as BST (Branch Start), BND (Branch End), NXB (next Branch. Reducing the number of instructions by not using branches not only speeds up the execution, but also reduces memory consumption.

2. "Least Likely to be true".... - once a rung is evaluated as "false", it cannot be turned true again (until a BND or NXB is encountered), so execution of further conditional instructions does not require the controller to read the states or values of the associated tags of the following instructions, and simply "passes them by" as quickly as possible.

The first question to ask, is: Why do you feel you need to improve the scan time?

If it is truly so very slow that you can't control your process, then little fixes probably won't work, and you need to move to a faster processor, but that is pretty rare.

Just optimizing for the sake of it is almost never worth it, in any programming language.

As above, how much time do you need to shave off?

Whilst it's nice to know how to optimise the code for more efficiency, it's another thing to spend 2 weeks trawling through and changing everything, when time-wise, it would be more efficient to get a faster PLC.

janner_10 said:

As above, how much time do you need to shave off?

Whilst it's nice to know how to optimise the code for more efficiency, it's another thing to spend 2 weeks trawling through and changing everything, when time-wise, it would be more efficient to get a faster PLC.

Click to expand...

I totally agree, don't waste your time on an existing application, it's just not worth the effort.

But if you are starting from scratch, adopting optimisation techniques from the word go can't be a bad thing.

Remember that a single ControlLogix processor can support up to 8 motion axes, and sometimes you will need that extra bit of speed and efficiency offered by optimised code execution.

Thanks Daba it was very informative.
I asked because of new project to control hydraulic cylinders with servovalves, ramp up, ramp down, change of speed 3 times within a single movement.
So I have to optimize the code to avoid issues.(do it right the first time)
By the way the PLC is a CompactLogix L36ERM.

tarik1978 said:

Thanks Daba it was very informative.
I asked because of new project to control hydraulic cylinders with servovalves, ramp up, ramp down, change of speed 3 times within a single movement.
So I have to optimize the code to avoid issues.(do it right the first time)
By the way the PLC is a CompactLogix L36ERM.

Click to expand...

All the techniques discussed are relevant to the CompactLogix, in fact any of the Logix5000 systems.

I don't believe you need to worry about processor speed, your servovalves will be much slower to respond by comparison, probably by a very large factor.

Switch to compactlogix 5069, much faster, including faster io.