The I/O image table, also called the process image, is a block of PLC memory that holds a copy of what the field inputs and outputs are doing. Rather than reaching out to a physical terminal every time it needs an input, the controller reads from this copy, and rather than driving a physical output the instant logic changes, it updates the copy and pushes it out later. The image table is refreshed at fixed points in each scan, which makes the controller's view of the world consistent from top to bottom of the program. That consistency is a feature, but the way it decouples the program from live I/O surprises new RTU programmers.
I/O Image Table in one line: A PLC I/O image table, or process image, is a reserved area of controller memory holding a snapshot of every field input and output. The PLC copies real inputs into the input image at the start of each scan and copies the output image out to real outputs at the end, so the program runs against a stable frozen copy rather than live signals.
The process image is really two tables. The input image, called the PII in Siemens terminology, holds one bit or word for every physical input point. At the very start of each scan the controller reads all its input modules and copies their states into this table, so the input image becomes a photograph of the field taken at that instant. The output image, the PIQ in the same terminology, holds one bit or word for every physical output point, and the program writes its results here rather than directly to the modules.
During the logic-solving portion of the scan, every contact the program examines reads from the input image, and every coil the program energizes writes to the output image. The physical modules are not touched at all during this phase. This is deliberate: it gives the whole program a single, unchanging set of input values to work with, so a signal cannot appear to have one value on rung 5 and a different value on rung 200 within the same scan just because the field flickered in between.
At the end of the scan the controller copies the entire output image out to the physical output modules in one update, and the field devices finally see the results the program computed. Only then does the next scan begin by refreshing the input image again. This read-once, write-once discipline is what makes a conventional PLC scan deterministic and repeatable, and it is why the image tables sit at the center of how any ladder or structured program actually interacts with the world.
Working on a frozen copy instead of live I/O solves a real problem. If the program read each physical input at the exact moment it encountered that input in the code, a fast-changing signal could take on different values at different points in the same scan, and logic that compares two inputs, or that uses one input several times, could produce inconsistent or even self-contradictory results. Freezing all inputs at scan start guarantees that the entire program sees one coherent picture of the field for the duration of that scan.
The same reasoning applies on the output side. Writing outputs continuously as logic resolves would let an output flicker on and off several times within a single scan as intermediate results churned, chattering a real coil or valve. Instead the program settles the output image to its final values and pushes them all out at once, so each physical output changes at most once per scan and only reflects the finished result of the logic. This makes machine behavior cleaner and easier to reason about.
The cost of this scheme is a built-in delay between the physical world and the controller's knowledge of it. An input that changes just after the scan-start read is not seen by the program until the next scan captures it. An output the program computes is not applied to the field until the scan-end write. For most process control these delays are trivial next to the process time constants, but they are always present, and they are the mechanism behind the timing behavior that catches people out.
The classic surprise is a physical input that changes in the middle of a scan and is simply not noticed until the following scan. Because the input image was frozen at scan start, any change that arrives after that read is invisible to the program running right now; it only appears when the next scan re-reads the inputs. A programmer who expects a fast pushbutton or a short pulse to be caught the instant it occurs can be baffled when the logic seems to ignore it, when in fact the pulse simply came and went between two input reads.
This is exactly why edge-detection and one-shot instructions exist, and why very fast signals belong on hardware that does not depend on the scan, such as high-speed counter channels or interrupt inputs. It also explains why a pulse must be held true for at least one full scan to be guaranteed seen: anything shorter than a scan can fall entirely inside the window when the inputs are not being read. Understanding the image table turns these from mysterious intermittent bugs into predictable, designed-for behavior.
On a remote RTU at a wellsite the effect is the same but the stakes can feel higher, because problems are harder to observe from a distance. A short contact closure from a level switch or a status pulse from a meter must be conditioned to last long enough to survive a scan, or captured by hardware, or it may never enter the input image at all. New RTU programmers who assume the controller is watching the field continuously, rather than sampling it once per scan, write logic that works on the bench with a slow finger on a switch and then misses real, fast field events. Knowing that the controller lives on a frozen copy is the fix.
The input image is the copy of all physical input states that the PLC reads in at the start of each scan, and the program examines this copy rather than the live terminals. The output image is the copy of all output states that the program writes to as it runs, and the PLC pushes this copy out to the physical outputs at the end of the scan. In Siemens terms these are the PII and the PIQ.
Using an image table gives the whole program a single consistent snapshot of the field for each scan, so an input cannot appear to change value between two rungs in the same pass. It also lets outputs settle to their final values and update just once per scan instead of chattering as logic resolves. The trade-off is a small, predictable delay of up to one scan between the field and the controller.
Because the controller only samples its inputs into the input image once per scan, at the start. A pulse that goes true and false entirely between two of those reads never makes it into the image table and is never seen by the program. To catch fast events, hold the signal true for at least one full scan, use an edge-detect or one-shot instruction, or route it to a hardware high-speed or interrupt input that does not depend on the scan.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.