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.
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