Ladder Logic 105: PLC Scanning

PLC Scan with RPI
PLC Scan with RPI

In my last post on PLC Memory Organization, I mentioned that I had not really covered how scanning actually works in a programmable controller. This is certainly a topic that needs to be discussed for an understanding of PLC programming, no matter what platform you may be using.

All PLCs worldwide, with the exception of one (that I know of…) handle scanning in the same way. First, the CPU reads the physical inputs into a memory table, usually called the “input table”. This table is then used as the program is evaluated, rung by rung. In my Ladder Logic 104 post I discussed the various other types of registers that are used in different platforms; these registers are updated as the logic is processed left to right on each rung and top to bottom within each routine. This includes updating an output table, which will later be used to drive the physical devices connected to the PLC.

In my other post on scanning, I illustrated how the program might call different subroutines for different purposes. As you can see from that example, it can be important in what order routines are called; depending on where memory registers and output tables are updated, the physical outputs could be delayed by up to two scans in the example shown.

In any case, the program meanders through the different routines as they are called, returning to wherever they were called from and eventually ending up at the end of the original cyclic routine. (Quick note on that: most programs use an initial cyclic routine that is used to call all of the other routines. In Siemens, this is OB1. For the A-B SLC/Micrologix platform it is LAD 2, and in the A-B ControlLogix platform it is usually called “Main Routine”).

The reason I say “most” programs is that some programs don’t use a continuous program at all, they use programs that run on a periodic basis instead. This is pretty rare, most programs use a continuous program configuration that runs as fast as it can.

So after executing all of the code, evaluating the logic and updating all of the tables (except for the input tables, which were written at the beginning of the scan), the resulting output table or register contents are written to the physical outputs. This is illustrated by the diagram at the top of this post: 1. Read Inputs to Table, 2. Evaluate Logic, and 3. Write Output Table to Outputs.

How long does this take? Well, that depends on the platform (speed of the processor), how much code there is in your program, and the types of instructions you used. Sometimes programmers will make use of loops in the program or make repetitive calls to the same routines. All of this has an effect on the total scan time. There is usually documentation available indicating the execution time for different instructions, but you would never try to add up all of your code to make an estimate. It is simply available for reference.

Most programs I have written have varied from as short as 10-15 milliseconds to as long as 70-80 milliseconds. If the scan time is much longer than about 50 milliseconds (for a machine control project) I start looking for a more powerful processor or ways to make my code more efficient. Beyond 50ms the effect on output reaction starts to be noticeable; for a process control project this may not matter.

In the diagram at the top of this post the scan time is shown as 56ms; this is a pretty big program. But what are the marks labeled A, B and C? As I mentioned before, scanning works the way I described for every platform I know of, with one exception. The Allen-Bradley ControlLogix platform works on a producer-consumer model, where input cards produce information for CPU(s), and the CPU produces information for the output cards. The CPU can then be said to “consume” information, and the output cards consume from the CPU. The production and consumption of information is scheduled within each I/O card by setting what is known as an RPI, or “Requested Packet Interval”.

In the diagram at the top of the post, the RPI is set at 20 milliseconds. This means that the program will get a couple of updates from the physical inputs each scan, and will update the physical outputs twice per scan also. This is typical for digital I/O; analog inputs are usually set at 100ms or more, while analog outputs are also usually updated more slowly than digital also. As you can see, the updates happen at different points within the scan cycle, which varies in duration quite a bit anyway.

So do you think you have a pretty good handle on scanning? Below is an exercise from the Automation Training manual I use when doing PLC training.

What is the state of Output 2?
What is the state of Output 2?

The question in the training manual asks “Will Output 2 Ever Turn On?” There are basically three answers I get; it will never turn on, it will always be on, or it will briefly flicker every scan. If you read this post carefully, you will be able to figure out the answer.

Because I don’t get that many comments on my posts, I am not going to answer this here. If you think you know, leave a comment! Hint it is not as simple as it looks.

* 17 January 2016: Click here for the Solution


Electrical Engineer and business owner from the Nashville, Tennessee area. I also play music, Chess and Go.

33 Comments on “Ladder Logic 105: PLC Scanning

  1. Hello Frank, congratulations for the post!
    “Output 2” will never on, due the logic will be updated before it write to output.

  2. Hi Frank. Excellent post, as the last. The answer to your question: Output 2 is always on. Whenever scan the rung where is the output 2, output 1 is always on, so the end of the scan always writes a ‘1’ in the output 2. Here a link with more information about the cycle scan.

  3. For most processors, output 2 will always be on after the first scan.
    For early Modicon compatible processors it will always be off.

  4. Output 2 will turn on but it will depend completely upon the processor and scan times as well as priorities (i.e. ControlLogix RPI).

  5. Since executing the ladder logic is step two of the four steps of the scan cycle the ladder will change each output as it scans each rung from top to bottom. The first rung will latch on output 1. The second rung will turn on output 2. The third rung will unlatch output 1, but it will not effect output 2 because it has already been turned on in rung 2. After the last rung is scanned the PLC will execute step 3 of the scan cycle and write the outputs to the output cards and output 2 will turn on and stay on. At least in the older PLCs.

  6. If scan left to right and top to bottom, then Output 2 will never turn on. Never use such unpredictable logic in your programm 🙂

  7. It depend on the PLC. Some PLC do the reading of each first instruction in each rung and after that the second and so on and first at last update the flag in the end of the rung.
    Some PLC’s execute 1 rung and then update the output and after that go to the next rung and update the output.
    Most vil read the inputs. After that it will execute the first rung and update the output flag. When all rungs is executed the output flags is send to the physical outputs.
    If you read the program in the pic. 1 rung set the output flag 1
    in rung 2 the output flag 1 will tell output flag 2 to go on.
    In rung 3 output flag 1 will always go off.
    Now we are at the end of the program. Output flag 1 is off and Output flag 2 is on. The flags is written to the physical output.
    So Output 1 is off and Output 2 is on.
    The PLC will read the inputs. None used in the program.
    Then it again set output flag 1 and output flag 1 set output flag 2 and after that output flag 1 is again set to off.
    Physical outputs is updated – and nothing change.
    But nothing is general.
    You have to read the manual for the PLC you use.

  8. The answer is that it depends.

    On a Siemens processor the Inputs are read before you start the scan logic and the outputs are written after the scan completes, unless you use a PIW or PQW.

    However, with a Rockwell Compact Logix, all of the IO is written immediately and read live, thus the output would flicker for a very very small amount of time (possibly so small it would be undetectable), but hypothetically, if an interrupt grabbed priority between rungs 2 and 3 it could stay on for longer.

    Overall I believe you article to be fairly good, however, you make assumptions that all hardware makers handle IO the same, which is not the case.

  9. Physical input is copied to input flags
    then execution of the program rung for rung.
    Output is activating output flags during executing
    When program is executed the output flags is copied to physical output

  10. Don’t be confused between physical out and output flag.

    Physical out will be write at the end of cycle scan.
    But output flag is write at the same time when processed by logic.

    So, in this example:
    – physical out 1 is always OFF
    – output flag 1 is ON between rung 1 and 3
    – physical out (and output flag) 2 is always ON (after the end of first scan cycle)

  11. So, I loaded this into a small test bench plc and found that strangely output y2 stayed “on” along with reset. No flicker.

    ———-set y1
    — y1 ———-y2 “on”
    ———————rst y1 “on”

  12. As long as program cycle allowed to be done normally as painted in the picture at the beginning of the article (read input, calculate logic and then write output) the state of output1 is always “Off” whereas output2 is always “On” (without any flicker!)
    But it’s possible (not so easy) to make CPU busy enough to obtain flicker on Output1 or Output2 (!!!) if the CPU has forced to terminate the cycle (instead finishing it) randomly before first or second or third branch of ladder we will obtain flicker on Output1 or Output2 (so easy 🙂 )

  13. Ahhh, I cut my teeth on Modicon 184’s and 384’s solved line by line then 984’s which were network by network.

    The output should always be on after the first scan.
    However, I would like to point out something that has been frowned upon by many people for years, Latching outputs.

    Why is it that people would use these instead of proper logic is a mystery to me.

  14. If all command are written in the same network at a older Quantum-CPU:
    Output 2 is allway off:
    From my work with Quantum-CPU and Modsoft I remember that within one network the command execution starts with the leftiest column top down and continues with second column top down and so on.
    That means than at execution moment of the 1. cell in the 2. row the value of the output1 is still off ==> Output2 ist off.

    But if in the same CPU the 1. and 2. rows are in different networks than the output2 is allways on.

    The behavior on other platform may differ.

  15. Tested out on a Panasonic FP0-C32 using FPWin Pro V6. If I program it properly (with each rung in its own network), then I get the standard result: Output 2 is always ON.

    However, if I stuff all 3 rungs into 1 network (BAD, BAD – FPWin gives 2 warnings), then Output 2 is always OFF.

    Of course, use separated SET and RESET like this is bad practice – but this is one way to show why.

    I do use Set/Reset in many standard programs, because I want to be able to pause the PLC program and maintain state, and using Set/Reset lets me do that. But I keep the set/resets in the same network, next to each other.

  16. Technically, at least for most PLCs, Output 2 will be off until Rung 2 is evaluated. At that point output 2 will turn on. It will then remain on until the PLC is reset. This is assuming the output 2 is not using a memory retentive memory address.

    I rather despise set and reset instructions. Especially when not grouped together. Give me a sealing diagram.

    As for scanning order, didn’t the old Modicons scan top to bottom, left to right?