PLC Debugger Behavior: Why Tag Values Update at Scan End

Overview: The PLC Scan Cycle and Debugger Visibility Model

PLC debuggers operate under fundamentally different constraints than software IDE debuggers for desktop applications. When a programmer places a watch on a tag in TIA Portal, Logix Designer, or CODESYS, the displayed value reflects the state of that tag at the conclusion of the most recent complete scan cycle — not its value at the precise moment a particular line of code executes. This behavior is not a defect; it is a deliberate architectural choice rooted in the determinism requirements of real-time industrial control.

The execution model defined in IEC 61131-3:2013 specifies that PLC programs execute cyclically, with each cycle consisting of three primary phases: input scan, program execution, and output scan. Within this model, the runtime system maintains a consistent image of all input and output points for the duration of program execution. This process image is what makes program logic repeatable and deterministic.

When an engineer sets a breakpoint or hovers over a variable in the IDE, the request must travel from the programming workstation, through the engineering interface (typically Ethernet/PROFINET/EtherNet/IP), to the PLC's runtime kernel, which then captures the requested tag value and returns it to the IDE. Doing this after every line, every network, or every instruction would violate the deterministic timing guarantees that the PLC architecture is designed to provide. This end-of-cycle visibility model is the same behavior across virtually all PLC platforms on the market today, from low-cost micro-PLCs to high-end process controllers, and it cannot be changed without breaking the real-time guarantees the controller was designed to deliver.

PLC Scan Cycle Architecture: Input → Program → Output

The classical PLC scan cycle consists of the following phases, executed in a continuous loop until the CPU enters STOP or a fault condition:

1. Input Scan (T_in): The CPU reads the state of all physical input modules and copies them into the process input image (PII). For a Siemens S7-1500, this corresponds to the input image partition (IPE) of the process image; for Allen-Bradley ControlLogix, the equivalent is the input data tags as configured in the produced/consumer model.
2. Program Execution (T_prog): The CPU executes the user program sequentially, operating exclusively on the process image rather than directly on physical I/O. This is critical for determinism — the program sees a stable view of inputs that will not change mid-execution.
3. Output Scan (T_out): The CPU writes the process output image (POI) to the physical output modules, energizing or de-energizing field devices.
4. Communication / Housekeeping (T_comm): Time slice for handling engineering requests, peer-to-peer communication (PROFINET, EtherNet/IP, EtherCAT), and other background tasks including the operating system's internal scheduling.

The total cycle time is given by:

T_cycle = T_in + T_prog + T_out + T_comm

For a typical S7-1516 with 256 DI / 256 DO and a 150 ms configured cycle monitoring time, expect T_in ≈ 0.5 ms, T_out ≈ 0.5 ms, T_prog ≈ 5–15 ms (program dependent), and T_comm ≈ 1–3 ms. Total cycle time commonly lands in the 8–25 ms range for typical machine-control applications.

Cycle time is monitored by the PLC's watchdog. If T_cycle exceeds the configured maximum (the S7-1500 "Cycle monitoring time" parameter in the CPU properties dialog), the CPU enters STOP with SF (system fault) LED and a diagnostic buffer entry citing "Cycle time exceeded" with event ID 16#4542. The diagnostic buffer also records the actual cycle time and the time of occurrence, which is invaluable for post-fault analysis.

Why Debuggers Display End-of-Cycle Values

Capturing and transmitting a tag value to the IDE is not a zero-cost operation. Consider a tag read operation from the engineering station:

T_read = T_request + T_processing + T_response

Where:

• T_request: Network round-trip time from IDE to PLC (typically 1–10 ms on a 100 Mbit/s PROFINET network, higher on routed or wireless connections).
• T_processing: Time for the PLC's communication OS to locate the tag, format the response, and queue it (typically 0.5–2 ms depending on tag complexity and PLC CPU load).
• T_response: Network round-trip for the response payload.

If a program contains 100 network segments and the IDE requested a tag value after every network, the additional time burden would be:

T_debug_overhead = N_networks × (T_request + T_processing + T_response)
= 100 × (5 + 1 + 5) ms
= 1100 ms

This would extend a 10 ms program execution cycle to over 1100 ms — a 110× slowdown that would cause the cycle watchdog to trip immediately and force the CPU into STOP. Beyond the timing impact, the IDE would need to maintain a logical mapping of "this tag is on line 247 of network 12 in OB1" — a task that becomes intractable as soon as conditional execution, loops, and function block calls are involved. The PLC's runtime does not maintain per-line execution context in a form accessible to external tooling, and adding this would require invasive changes to the runtime kernel that would compromise deterministic execution.

For these reasons, every major PLC vendor has converged on the same architecture: the IDE queries tag values at a configurable interval (typically 250 ms minimum, 1000 ms default), and the response reflects the tag's state at the most recent cycle boundary. The cycle boundary is a well-defined synchronization point that all participants in the engineering communication can reference unambiguously.

Vendor Implementation: Siemens SIMATIC S7-1200/1500 (TIA Portal)

In the SIMATIC S7-1200 Programmable Controller System Manual and the equivalent S7-1500 system manual (entry 109751799 on the Siemens support portal), Siemens documents the watch table (Beobachtungstabelle) and force table (Steuertabelle / Forcetabelle) as the supported mechanisms for online monitoring.

Watch Table Behavior

Watch tables in TIA Portal display tag values from the process image, refreshed at a configurable rate (default 1000 ms; minimum 250 ms in firmware V16+). The "Monitor with trigger" option allows conditional capture based on a tag value, edge event, or periodic time interval. The displayed values correspond to the PII/POI snapshot at the most recent cycle boundary, not at any intermediate point within the cycle.

The "Modify" function writes a value to the PII or POI for the next cycle only — the modification takes effect at the next cycle, not immediately within the current cycle. This is by design and ensures that program execution within a single cycle is not interrupted by external writes.

Force Table Behavior

Force tables (introduced in TIA Portal V13) operate at the I/O level, bypassing the process image. A forced input will appear in the PII with the forced value regardless of the physical input state. Forces are stored retentively in the CPU and survive power cycles — they must be explicitly removed before commissioning or they can cause dangerous machine behavior at the next startup. The TIA Portal force table UI displays a clear visual indicator (red highlight) for any active force, and the CPU diagnostic buffer records each force activation and deactivation with operator identification if user administration is configured.

S7-1500 Cross-Reference and Program Info

The "Program info" → "Cross-reference" feature provides static analysis of tag usage. It does not require online connection and shows every location in the program where a tag is read or written — a powerful complement to online monitoring for offline code review and for identifying unused tags.

For S7-1500 with firmware V2.9 and later, the "Trace" function captures cyclic data at the CPU's native sampling rate (down to 0.1 ms) into on-board memory, then transfers it to TIA Portal for visualization. This is the recommended method for high-speed event capture, since it does not require runtime IDE polling and therefore does not extend cycle time.

S7-1200 Specific Limitations

The S7-1200 (firmware V4.0 and later) supports basic watch tables but does not support the full force table functionality of the S7-1500. The S7-1200 also lacks the native trace function; for high-speed capture, an external data acquisition system is required.

Vendor Implementation: Allen-Bradley ControlLogix/CompactLogix

Logix Designer (formerly RSLogix 5000) exposes tag monitoring through several mechanisms, each suited to a different debugging scenario:

Quick Watch

Right-click a tag in the ladder logic or structured text editor and select "Monitor" — opens a tag property window that polls the controller at a configurable rate (default 1000 ms; minimum 250 ms on Logix Designer V33+).

Trend Chart

The Trend object in Logix Designer plots tag values over time. Sampling rate can be set as low as 1 ms on ControlLogix 5580 controllers with firmware V33 and later. The trend polls the controller's tag database directly via CIP messaging; on Logix Designer V33+ with a 1756-EN4TR module, polling overhead is roughly 5–15 ms per tag per sample, which can extend effective sample rate beyond the configured value on busy networks.

Tag Properties and Data Context

Double-clicking a tag element opens a properties dialog showing the value, quality, and timestamp. The timestamp reflects the last time the tag was updated in the controller's tag database — which may not align with any particular line of code execution. For tags driven by a periodic task, the timestamp advances at the periodic task rate; for tags driven by an event task, the timestamp advances only when the event fires.

Cross-Reference

Similar to Siemens, Logix Designer provides offline cross-reference (Ctrl+E) and online cross-reference. The online cross-reference is updated by the controller and reflects the current program state, including conditional branches not taken during the last cycle.

The Logix 5580 controller architecture stores tags in a tag database that is asynchronously updated by tasks. A tag may be updated by a periodic task, an event task, or a motion planner — Logix Designer cannot know which task most recently updated the tag without explicit task cross-referencing, which is why the tag timestamp is the most reliable debugging reference.

Breakpoint Handling and Single-Step Execution

Most PLC IDEs do not support true single-step execution in the way a desktop debugger does. The exceptions are limited and vendor-specific:

• CODESYS (3.5.16 and later): Supports breakpoints in online mode. When the breakpoint is hit, the affected task is paused, and the IDE displays current tag values. However, this only works for the task in which the breakpoint is set, and other tasks (faster cyclic tasks, event tasks, motion tasks) continue running. Watchdog timers in the running tasks must accommodate the pause.
• TIA Portal V17 and later (S7-1500 only): Breakpoints are supported in SCL (Structured Control Language) but not in ladder logic or FBD. When a breakpoint hits, the OB/task is paused; the IDE displays the current local variable values. The PLC's task watchdog is automatically suspended during breakpoint hold, but the hardware watchdog continues to run.
• Logix Designer: Does not support breakpoints in any language. Single-step is not available.

Why Single-Step Is Rare in Production PLCs

Single-step execution in a real-time control system is hazardous because:

1. Other tasks continue running: A paused motion task may miss its servo update window, causing following error faults. On a Siemens S7-1500 with TO (Technology Object) motion, missing a servo update window generates an MC_Halt with error ID 16#8001.
2. Outputs retain last state: The POI is not updated while the program is paused, so any safety-relevant output stays in its last commanded state. For a normally-closed E-stop circuit, this is typically safe; for a normally-open contactor driving a motor, the motor may continue running indefinitely with no program logic executing to turn it off.
3. Watchdog timer: Most PLCs have a configurable watchdog that forces a STOP transition if a task exceeds its time budget. A breakpoint pause would trip this watchdog unless the IDE automatically extends the timeout (which CODESYS and TIA Portal do, but this masks the real timing behavior).
4. Process state inconsistency: Physical processes (temperature, pressure, flow, level) continue evolving while the program is paused. When execution resumes, the program sees a process state that has drifted significantly from the state at the breakpoint, often producing unexpected behavior.

Debug vs. Run Mode Behavioral Differences

A subtle but critical point: a PLC running with an attached debugger is NOT in the same state as a PLC running normally. Specifically:

Compiler Optimizations

When debugging is active, some compilers disable certain optimizations (dead-code elimination, constant folding, inlining) to preserve the logical correspondence between source code and executed code. For a Siemens S7-1500, this can extend cycle time by 5–15% on average programs; for very tight loops, the overhead can exceed 30%.

Watchdog Behavior

Some platforms (CODESYS, TIA Portal SCL breakpoints) automatically extend watchdog timers when breakpoints are set, to prevent the breakpoint pause from tripping the watchdog. This means the watchdog timeout you observe in debug mode is not the same timeout that applies in production. Always verify production timing with the watchdog set to its production value and no breakpoints active.

Memory Layout

In debug builds, additional memory is allocated for variable descriptors, breakpoint tables, and trace buffers. This can change the absolute addresses of variables — relevant when interfacing with absolute addressing in OPC UA servers, fixed-address HMIs, or other tools that read memory at known offsets. On Siemens S7-1500, the optimized block access checkbox in the block properties affects memory layout significantly; debug builds typically use non-optimized access for breakpoint support, while production builds typically use optimized access for performance.

Timing-Dependent Code

If your program contains code that depends on execution timing (a free-running counter increment, a pulse width measurement, an integrator with a fixed time step), the cycle extension from monitoring will cause that code to behave differently. Always validate timing-dependent logic with the debugger disconnected and any active watch tables closed.

Hardware Watchdog

Some PLC CPUs have a hardware watchdog (separate from the software task watchdog) that will reset the CPU if no program activity is detected within a configurable window. This is independent of debug state and protects against total firmware hangs. On Siemens S7-1500, the hardware watchdog defaults to 500 ms but is configurable from 100 ms to 60000 ms. On Allen-Bradley ControlLogix, the equivalent is the "Major Fault on Watchdog Timeout" parameter; default behavior is to enter a major fault and STOP the controller.

Variable Initialization Differences

Some platforms reinitialize all variables on every STOP-to-RUN transition; others retain their last value. When debugging, you may stop and start the CPU multiple times; this can mask or expose initialization bugs that would not appear in production where the CPU may run for weeks or months between stops.

Watch Tables, Force Tables, and Trigger-Based Monitoring

Trigger Configuration

Trigger-based monitoring captures a tag value at a specific event, not at a specific time. Common trigger types:

• Tag value: Capture when tag X equals value Y (or a defined range).
• Edge: Capture on rising or falling edge of tag X.
• Periodic: Capture at a fixed time interval (independent of PLC cycle).
• Instruction breakpoint (limited platforms): Capture when a specific instruction executes.

A trigger-based capture does not extend cycle time because the trigger check is performed by the PLC's communication OS, not by the user program. The communication OS has its own time slice (T_comm in the cycle time formula) that handles this check without interfering with program execution.

Sampling Rate vs. Cycle Time

Sampling rate and cycle time are independent. A PLC with a 50 ms cycle time can sample a tag at 1000 Hz if the sampling is performed by a dedicated high-priority task or by the CPU's trace buffer (Siemens S7-1500 Trace, Allen-Bradley Sequence of Events).

For Logix Designer trends, the maximum sustainable sample rate is approximately:

f_max ≤ Available_comm_time / (CPU_overhead_per_sample × N_tags)

Where CPU_overhead_per_sample is approximately 0.05 ms on a 1756-L82E controller, and Available_comm_time is the portion of the communication time slice not consumed by I/O updates (typically 2–10 ms per cycle on a 50 ms cycle).

Force vs. Modify Distinction (Siemens)

Modify writes a value to the process image (PII/POI). The value is consumed by the next cycle's program execution and does not persist beyond that cycle unless the program writes it back to a retentive tag. Modify is non-retentive: a power cycle clears it.

Force writes to the physical I/O driver and bypasses the process image. The forced value persists across power cycles and survives STOP-RUN transitions until explicitly released. Force is retentive and must be removed via the force table UI or by formatting the CPU.

On Allen-Bradley ControlLogix, the equivalent distinction is between "Toggle Bit" (modify, non-retentive) and "Force I/O" (force, retentive, I/O-level). The Logix Designer UI uses different icons (yellow vs. red highlight) to distinguish these states.

Performance Impact Calculations and Timing

Cycle Time Extension from Online Monitoring

When a watch table is active, the PLC must perform tag value reads at each sample. The additional cycle time is approximately:

ΔT_cycle = N_tags × T_tag_read

Where T_tag_read is the time to format and respond to a single tag read request. For a Siemens S7-1516 with 50 tags in a watch table, T_tag_read ≈ 0.02 ms per tag, so ΔT_cycle ≈ 1.0 ms per sample cycle. This is in addition to the normal sample interval and applies to every cycle in which the PLC services the watch table request.

Network Bandwidth Calculation

Tag read requests and responses consume network bandwidth. Each request/response pair for a single 4-byte tag is approximately:

• Request: 24 bytes (header + tag name)
• Response: 32 bytes (header + tag value + status)

For 50 tags at 1000 ms sample interval on a 100 Mbit/s PROFINET network, the bandwidth utilization is:

B = (N_tags × Bytes_per_transaction × 8 bits/byte) / Sample_interval
B = (50 × 56 bytes × 8 bits/byte) / 1 s
B = 22,400 bps = 0.022% of 100 Mbit/s

This is negligible on a dedicated engineering network but can be significant on a shared plant network where multiple engineering stations are polling. On a 10 Mbit/s legacy PROFINET network, the same workload consumes 0.22% — still negligible, but additional stations and longer polling intervals can quickly add up.

Storage Implications for Native Trace

Trend data captured on the PLC (S7-1500 Trace, ControlLogix Sequence of Events) is stored in a circular buffer. The default buffer size on S7-1500 is 512 KB, which at 4-byte tags with 0.1 ms sampling holds approximately:

N_samples = Buffer_size / (Tag_size × N_tags)
For 10 tags at 0.1 ms sampling:
N_samples = 512,000 / (4 × 10) = 12,800 samples = 1.28 seconds of trace data

If longer captures are required, increase the buffer size (up to 4 MB on S7-1518) or reduce the sampling rate. For multi-second captures at high sampling rates, offload to a higher-capacity storage medium — the S7-1500 supports an SD card up to 32 GB for trace storage, though SD card write speed may be the bottleneck for high-rate captures.

Best Practices and Alternative Debugging Techniques

Recommended Debugging Workflow

1. Offline analysis first: Use cross-reference, program info, and static code review to verify logic before connecting online. Cross-reference analysis catches 60–70% of common logic errors without any online activity.
2. Simulate in offline mode: TIA Portal PLCSIM and Studio 5000 Logix Emulate allow full program execution without hardware. Simulation supports watch tables, force tables, and most debugging features but does not support the exact cycle timing of physical hardware. Validate cycle timing on the real PLC before commissioning.
3. Watch tables with triggers: Capture only the events that matter, not the entire cycle. Configure trigger conditions that fire on the specific state change or value you are investigating.
4. Trace for high-speed events: Use the PLC's native trace for sub-millisecond analysis. Trace captures to on-board memory and does not extend cycle time.
5. HMI/SCADA trending: For operational debugging, the HMI trend is more effective than the IDE trend because operators can see it and correlate it with their observations. HMI trends also persist across power cycles if logged.
6. Code instrumentation: Add status tags that the program sets when it enters specific states. These can be displayed on the HMI without any IDE connection. Common patterns: state machine state numbers, fault codes, last-transition timestamps.
7. Data logging: For intermittent faults, log critical tags to a CSV file via the PLC's web server (Siemens S7-1500 supports data logging to SD card via the WebAPI) or a separate data acquisition system.

When End-of-Cycle Visibility Is Insufficient

If you need to observe values within a single scan cycle, the only reliable methods are:

• PLC native trace (Siemens Trace, Rockwell Sequence of Events, B&R Runtime Trace, Beckhoff TwinCAT Scope)
• Oscilloscope on physical I/O (for analog signals)
• High-speed digital data logger (for fast digital events)
• External data acquisition (a Beckhoff EK1100 with high-speed analog input, a National Instruments CompactDAQ, or similar)

These methods sample at rates determined by their own hardware, independent of the PLC cycle. They are the only reliable way to verify sub-cycle timing-dependent behavior.

Recommended Watch Table Configuration

For minimal cycle time impact:

• Limit watch tables to 20–30 tags
• Use the longest acceptable sample interval (typically 1000 ms for human observation)
• Use trigger conditions to capture specific events
• Close the watch table window when not actively debugging
• Use "Monitor value only" mode (disable "Monitor all" or "Modify" if not needed)
• Use "Monitor all" mode only during commissioning, not during normal operation
• Disable the watch table's "Update automatically" option if you only need to see values on demand

Recommended Force Table Procedure

1. Document the force in the commissioning log (tag name, forced value, reason, operator, timestamp)
2. Verify the operator understands the implication of the force
3. Limit force duration — most plants have a hard rule that forces must be removed within 8 hours or the operator must re-authorize
4. Before removing the force, verify the actual physical state matches the expected state
5. Record the force removal in the commissioning log
6. Verify the CPU reports zero active forces before production run

Cross-Platform Considerations

When migrating code between vendors (Siemens to Allen-Bradley, or vice versa), be aware that scan cycle behavior differs:

• Siemens S7-1500: Single cyclic task (OB1) by default; multiple cyclic tasks (OB30–OB38) possible for time-deterministic partitioning
• Allen-Bradley ControlLogix: Multiple tasks always; periodic task rate defines cycle equivalent
• Beckhoff TwinCAT: Task cycle defined by EtherCAT distributed clocks; sub-millisecond deterministic
• B&R Automation: Multiple tasks with priority-based scheduling

The end-of-cycle debugger visibility behavior is the same across all platforms, but the cycle structure that determines which tags update at which rate differs significantly.

Frequently Asked Questions