PLC I/O Mapping vs Direct Input Addressing: Scan Time Trade-offs

Overview: Why the I/O Data Path Matters

Every PLC executes a deterministic scan cycle: read the physical input modules into the input image table, execute the user program, write the output image table to the physical output modules, and repeat. The CPU consults the input image (process image of the inputs, PII) during the program scan, not the live module registers. This isolation is what makes ladder logic deterministic, but it creates a recurring engineering question: should logic reference the raw I/O addresses (peripheral access) directly, or should the program copy inputs into internal flags/words at the start of the cycle and consume the copies downstream?

This article compares both techniques on the dimensions that actually matter in production: scan-time cost, memory footprint, code maintainability, commissioning ergonomics, and diagnostic clarity. Platform-specific notes focus on Siemens S7-1200/S7-1500 (TIA Portal) and cross-reference Allen-Bradley ControlLogix/CompactLogix behaviour where the contrast is instructive.

PLC Scan Cycle Refresher

The classical four-phase scan, documented in every fundamentals text, runs continuously:

1. Input scan — the CPU reads each input module and refreshes the dedicated input image area in memory.
2. Program scan — the CPU evaluates the user program from top to bottom (or per OB1 priority), reading the input image and writing intermediate results to the output image and bit memory (M), data blocks (DB), or temporary locals (L).
3. Output scan — the CPU writes the output image to the physical output modules.
4. Housekeeping — communication, self-diagnostics, and OB1 cycle-time accounting.

The PLC scan fundamentals reference from AutomationDirect describes the same structure used by every modern controller: the input image is the canonical read source during the program scan, and the output image is the canonical write target. Anything that bypasses this image is by definition immediate or peripheral access.

Direct (Peripheral) I/O Addressing Explained

Direct I/O addressing means the program reads the physical input register of the module itself, mid-scan, rather than the value latched into the image table at the start of OB1. In Siemens terminology this is peripheral access and uses the %I qualifier for inputs and %Q for outputs, with the access flag appended:

• %IW0:P — peripheral (immediate) read of input word 0
• %I0.0 — image-table read of input bit 0.0
• %IB0:P — peripheral read of input byte 0

The Siemens SiePortal peripheral addressing reference confirms the semantics: "Peripheral addressing accesses the individual registers as immediate reads (inputs) and writes (outputs) so the value is accessed at the point" of program execution. Allen-Bradley Logix Designer exposes the same concept through :I (input) and :O (output) immediate tags, while the IOT (Immediate Output) instruction in RSLogix 500/5000 forces an immediate write.

The trade-off is real and measurable:

I/O Mapping Methodology

I/O mapping — sometimes called image mirroring, buffering, or internal I/O — is the practice of copying physical input bits or words into a dedicated data block (or marker area) at the very top of the program scan, then referencing the copy in all downstream logic. The same technique is applied to outputs: the program writes to a buffer, and a dedicated output section copies the buffer to the physical %Q addresses.

Typical S7-1500 architecture in TIA Portal:

// "IO_Map" data block (DB100)
// Inputs (BOOL)
DB100.IB0_Mirror    : BYTE   // mirrors %IB0
DB100.I0_0_Run      : BOOL   // mirrors %I0.0
DB100.I0_1_Stop     : BOOL   // mirrors %I0.1

// Outputs (BOOL)
DB100.Q0_0_Motor    : BOOL   // pre-output

// Top of OB1 (cycle)
       L     %IB0:P                    // peripheral read
       T     DB100.IB0_Mirror          // copy to buffer
       U     %I0.0:P
       =     DB100.I0_0_Run
       U     %I0.1:P
       =     DB100.I0_1_Stop

// Mid-program logic references DB100 only
       U     DB100.I0_0_Run
       UN    DB100.I0_1_Stop
       S     DB100.Q0_0_Motor

// Bottom of OB1 (output flush)
       U     DB100.Q0_0_Motor
       =     %Q0.0:P

The same pattern is achievable in ladder with the MOVE (S7), MOV (Logix), or XIC/XIU followed by OTE blocks.

Scan-Time Impact Analysis

Per-instruction timing for a 1500-series CPU is documented in the Siemens "S7-1500 CPU Performance" function manual and S7-400 timing tables (a historical baseline still cited in literature):

Worked example. Copying 100 input words into a virtual I/O map on an S7-400: 100 × 80 ns = 8 µs for the loads/transfers, plus 100 × ~1.5 µs = 150 µs if peripheral reads are used. The first figure is negligible against a 10 ms cycle; the second is ~1.5% of the cycle budget. On an S7-1500 the absolute numbers shrink, but the ratio is preserved: a fully-mirrored I/O map adds microseconds, not milliseconds, to a typical OB1.

Conversely, the image-table read of the same 100 words is essentially free once the image has been refreshed at the start of the cycle. The image refresh is bounded by the module's update time (1–5 ms for PROFINET, faster for local backplane) and is incurred once per cycle regardless of how many tags are referenced.

Memory and Performance Trade-offs

I/O mapping has a deterministic cost: a one-to-one memory footprint proportional to the number of physical channels mirrored. A 32-point digital input module mirrored bit-for-bit into a DB costs 32 bits of work memory. A 16-bit analog input mirrored word-for-word costs 16 words. For a typical machine of 256 DI / 256 DO / 64 AI / 64 AO, the bill is roughly:

Even the smallest S7-1500 CPU (CPU 1511-1 PN) ships with 150 KB of work memory; 320 bytes is 0.2% of budget. Memory pressure is therefore not a valid argument against mapping on any modern platform.

The genuine performance considerations are:

• Image-table access time is constant and bounded. Peripheral access time varies with the bus (PROFINET IRT update time, PROFIBUS cycle, local backplane). For deterministic, time-critical interlocks, the image is the safer source.
• Coherency. A multi-word read of %IW0:P and %IW1:P executed back-to-back can straddle a module update, returning values from two different bus cycles. The image table is refreshed atomically per slot, eliminating the split-read hazard.
• OB1 jitter. Each peripheral access is asynchronous to the program scan; bursts of :P accesses can extend the worst-case cycle time. Image-table access is synchronous.

Platform-Specific Implementation Notes

Siemens S7-1200 / S7-1500 (TIA Portal)

The process image is partitioned (PIP — Process Image Partition) by default. I/O mapping can be implemented either as:

1. Manual MOV block at the top of OB1 — the most explicit approach; visible in the code; easy to break-point in.
2. Assigned PIP update in the I/O assignment — bind a subset of %I addresses to a PIP and force an update at the start of the cycle. Slightly faster, less obvious in code review.
3. Data type consistency in TIA Portal (PLC tags with HMI visibility) — the recommended modern approach; the tag table is the I/O map and is shared with the HMI/SCADA layer.

For modules that demand sub-cycle freshness — high-speed counters, SSI encoders, fast interlocks on safety-relevant machinery — the appropriate tool is hardware interrupt OB (OB40 in S7-1500) or the module's hardware latch, not :P reads sprinkled through OB1.

Allen-Bradley ControlLogix / CompactLogix (Studio 5000)

Logix tags are already symbolic; there is no image-table concept in the Siemens sense, but there is a controller-scoped tag database. Direct references to Local:3:I.Data.0 and a mapped Motor_Run_Input alias produce identical machine code, but the aliasing is a free renaming facility, not a copy. I/O mapping in Logix practice means either:

• Tag aliases in the controller scope (no copy, just a name), or
• Programmatic copy in a periodic task (Map task) with a watchdog for data freshness, or
• Use of produced/consumed tags for peer-to-peer mirroring across controllers.

Logix designers frequently use the :I and :O immediate modifiers, but the multi-slot coherency caveat is the same: a program that reads AnalogInput[0].I followed by AnalogInput[1].I can be torn across a RPI boundary.

Best-Practice Architecture for I/O Mapping

1. Mirror all field I/O at the boundary. Create a single DB (e.g. IO_Map) with one symbolic tag per physical channel. The PLC tag table and the HMI tag table should reference these symbols, not the raw %I/%Q addresses.
2. Document the mapping. Maintain a spreadsheet or TIA Portal PLC tag table export that lists: tag name, slot/channel, signal type, sensor/actuator ID, P&ID reference, and functional description. The cost of producing this once is trivial; the cost of reverse-engineering a non-documented map during a midnight callout is enormous.
3. Use the mapping as a test harness. When you need to inject a value for a test (simulate a sensor stuck ON, force a permissive), you can write to the mirror DB and the logic downstream accepts it without disturbing the physical wiring. Add a watchdog timer for any I/O you force during commissioning to ensure the force is cleared before hand-off.
4. Use the mapping for portability across machines. When the same program is reused on a second machine with a different slot assignment, change the L %IB0:P / T DB100.IB0 line in one place instead of editing every rung.
5. Decide consciously where the image boundary lives. A well-named DB100 "IO_Map" is the canonical boundary. Below it lives raw hardware; above it lives process logic. Code review should reject any raw %I/%Q reference above the mapping section.

Diagnostic and Online-Testing Benefits

The operational value of an I/O map becomes obvious during commissioning. With a mirror in place, an engineer can:

• Monitor a single buffer DB to see the live state of every input on one watch table screen, instead of scrolling through a slot-by-slot list.
• Forcing a value into the mirror simulates a sensor without a hot stick on the terminal block. The downstream logic — including any motion or safety paths that depend on the value — exercises as if the real device were active.
• Compare the mirror to the raw image in two watch tables; a divergence between the two is a precise indicator of a stuck-at, a wire break, or a filter mismatch.

For a new sequence under test, an engineer can wire new logic in parallel to the mirror, drive it with simulated values, and remove the parallel logic once the production logic is proven — without ever editing a working program in place. The mirror is the buffer that makes iterative, non-destructive online editing safe.

Pitfalls and Maintenance Concerns

I/O mapping done badly is worse than no mapping at all. The common failure modes are:

Verification Procedure

After implementing an I/O map, verify it in the following order:

1. Static check — in TIA Portal "Go to>Cross-reference" or Studio 5000 "Cross Reference", confirm no raw %I/%Q reference appears above the mapping section in OB1/MainTask.
2. Image-vs-mirror compare — open two watch tables: one for the physical image, one for the mirror DB. Force each input ON and OFF at the terminal block. The two views must track within one OB1 cycle.
3. Cycle-time check — read the OB1 cycle time from the diagnostic buffer. The mirror should add microseconds, not milliseconds, to the previous baseline.
4. HMI parity check — every HMI tag tied to a mirrored input must update at the program scan rate, not at the bus rate. If HMI is configured to read raw %I directly, fix the HMI tag list.
5. Force-clear audit — search the project for any forced tag in the mirror DB; verify each force is in a documented test and has a removal plan.

Recommendations and Decision Matrix

The general rule: map for clarity and maintainability, override the map only where the application physics genuinely demand sub-cycle freshness, and document every override. The few microseconds saved by avoiding a map are almost never the binding constraint; the maintainability cost of unmapped code is almost always the binding cost.

FAQ