SIMOTION I/O Update Mechanism and Process Image Reference

SIMOTION separates the physical I/O layer from the user program execution layer by inserting a memory region called the logical address space between the DP/PN ASICs and the application. Every read or write the ST (Structured Text), MCC (Motion Control Chart), or LAD/FBD code performs on a standard I/O variable resolves either to a process image snapshot or to a direct logical address access, depending on the variable's declaration in the I/O Address List. Understanding which path is taken, and when the underlying memory is refreshed, is essential for deterministic motion control and for eliminating race conditions between Background, IPO, and Servo tasks.

This reference consolidates the runtime model, the access rules for BOOL and byte/word/dword variables, the role of Sinamics_Integrated and external CU320 controllers, the equidistant behavior of DP Integrated, and the practical implications for Profibus and Profinet cycle design. All behavior described applies to the SIMOTION SCOUT / TIA Portal programming environment and to the SIMOTION runtime firmware families V4.x and V5.x as documented in the official Siemens manuals.

1. SIMOTION I/O Stack Overview

The SIMOTION I/O model is a four-layer stack:

1. Physical I/O terminals (ET200S, ET200MP, SINAMICS I/O, third-party Profinet/Profibus slaves).
2. DP/PN ASICs on the SIMOTION controller (DP Integrated, PN Integrated, or external CP/IM modules) that cycle the fieldbus and maintain the current state of every configured I/O byte.
3. Logical address space – the memory region in which the ASICs deposit input states and from which they read output states. This is the lowest memory the user program can reach without calling system functions such as _readDriveParameter() or _writeDriveParameter().
4. Process image – per-task copies of selected logical address bytes. Each cyclic task (Servo, IPO, IPO_2, Background, BackgroundTask, MotionTasks) owns its own process image, refreshed at a defined phase of the task cycle.

The crucial property is that the DP/PN ASIC update is decoupled from the user task cycle. Inputs do not change while the task body executes; the value sampled at task start is the value the program works with for the entire task pass, unless the variable is configured for direct (immediate) access.

2. Logical Addresses vs. Process Image

A variable declared in the SIMOTotion SCOUT Address List with an %I or %Q prefix can be assigned to a specific task's process image. When assigned:

• All reads in that task see the process image copy taken at task start.
• All writes in that task update the process image; the ASIC does not see the new output state until task end.

When the variable is not assigned to a process image, every read or write goes directly to the logical address memory. The DP/PN ASIC sees the value at the next bus cycle, and reads pull the most recent value the ASIC has deposited. This is the immediate access mode referenced throughout the SIMOTION ST programming manual.

3. Cyclic Task Refresh Phase

Every cyclic task follows a fixed micro-cycle that, in the equidistant case, is locked to the DP Integrated bus cycle:

1. Input process image refresh – At task start, the configured input bytes are copied from the logical address space into the task's input process image. The read is logically instantaneous; the underlying value's age is one bus cycle at most.
2. Task body execution – ST/MCC/LAD code runs. Reads from a process image variable return the snapshot from step 1. Reads from a non-image (direct) variable re-read the logical address each access.
3. Output process image flush – At task end, the output process image is written back to the logical address space. The DP/PN ASIC picks up the new state on its next bus cycle.

For the Servo task, the Servo clock is the finest granularity. The IPO task reads from Servo results (not directly from I/O) when the Servo-to-IPO ratio is 1:1, which is why an input value cannot change inside a Servo task and changes only at IPO boundaries in a 1:1 Servo-to-IPO configuration when the bus cycle elapses.

4. BOOL Variables and the Byte/Word Default

BOOL variables cannot be assigned to a process image individually. The SIMOTION ST Programming and Operating Manual states: "For data type BOOL, it is not possible to define the process image for cyclic tasks. The behavior defined via an I/O variable for the entire byte is applicable (default: direct access)."

In practice this means:

• Reading or writing a single BOOL I/O variable resolves to the parent byte's access mode.
• If the parent byte is assigned to a task's process image, the BOOL follows the byte and is therefore process-image based.
• If the parent byte is not assigned to any process image, the BOOL defaults to direct access.
• If multiple BOOLs share the same parent byte, all of them share the same access mode – you cannot have a process-image BOOL and a direct BOOL inside the same byte.

5. Fixed Process Image of the Background Task

SIMOTION reserves a special fixed process image for the BackgroundTask. All variables whose address begins with % and that are declared as I/O variables default to the BackgroundTask's fixed process image, including BOOL variables. This is the single exception to the rule above.

Practical consequences:

• Every standard I/O variable on a SIMOTION controller is, by default, accessed via the BackgroundTask's process image at task start and flushed at task end.
• The value seen by a BackgroundTask read is the snapshot taken at the start of that BackgroundTask pass, not the live logical address.
• Other tasks (IPO, Servo, MotionTask) must explicitly assign a variable to their own process image to get snapshot semantics in those tasks. Without such an assignment, a variable in those tasks defaults to direct access (subject to the BOOL rule above).

6. Reading from Sinamics Integrated and External CU320

When an I/O variable is mapped to a Sinamics drive – either Sinamics_Integrated (on D4xx and P320/P430 controllers where the SINAMICS is on the local PCI/PCIe bus) or an external CU320 on Profibus/Profibus – the same logical-address and process-image rules apply, but the bus profile differs.

6.1 Sinamics Integrated (Onboard)

Sinamics_Integrated shares the SIMOTION CPU's local bus. Reads from a variable without a process image assignment are processor-level memory reads, not fieldbus transactions. Each access is a direct load from the drive's telegram buffer; the SIMOTION runtime does not stall waiting for a bus cycle because there is no fieldbus in the loop. The CU on its own (faster) update clock can change the underlying word between two consecutive bit-level reads of the same byte, which is generally irrelevant for typical control loops but worth noting if the code performs multiple reads of overlapping addresses in one task pass.

6.2 External CU320 on Profibus/Profibus

For a Controller Extension (CX) or an external CU320 connected via Profibus or Profinet, every direct read of a single bit or byte triggers a full bus request for the configured telegram. Profibus/Profibus are not deterministic by default; determinism must be configured using equidistant mode (isochronous) on both the master and the slave, and the connected I/O must support isochronous operation.

Optimization for external drives:

1. Assign the parent WORD/DWORD to the consuming task's process image. The DP/PN ASIC keeps the latest telegram data in the logical address space; the process image captures it at task start, and the program masks individual bits from the snapshot.
2. If process image assignment is impossible (for example in StartupTask or ShutdownTask, where the address list is not yet fully evaluated), use a single read at the top of the task into a local DWORD, then mask bits from the local copy.
3. Avoid patterns that read the same bit repeatedly inside a loop; a local cache eliminates redundant bus traffic.

7. Equidistant Bus Behavior

Equidistance is a property of a specific bus interface, not of Profibus or Profinet as protocols. In a SIMOTION device:

• DP Integrated is the only onboard interface that must operate equidistantly. It is the clock source for the entire SIMOTION device: Servo, IPO, and Background tasks all derive their cycle phase from the DP Integrated clock.
• PN Integrated, PN External, and DP External CPs/Ims can be configured for isochronous mode but are not required to be. Without explicit configuration they behave as standard, non-deterministic Profinet/Profibus channels.
• Connected I/O must also support clocked / isochronous operation. A bus master set to equidistant mode still produces non-deterministic behavior if a slave drops or reschedules its telegram.

The general rule: a 1 ms Profibus/Profibus cycle configured equidistantly updates I/O at 1 ms; configured non-equidistantly, the cycle time is approximate and jitter is unbounded.

8. Sampling vs. Reaction Time

Bus cycle time and user program reaction time are different quantities:

• Bus cycle time defines how often the logical address space is refreshed from the physical terminals. A 1 ms cycle gives you a 1 ms sampling grid.
• Reaction time is the time from a physical input change to a corresponding output change in the application. Even with a 1 ms bus cycle, the reaction time floor is T_bus + T_servo + T_ipo + T_background in the worst case, because the input must propagate through every task that reads it.

Configuring a "faster" bus cycle (e.g., 250 µs) shortens the sampling grid but does not shorten the worst-case reaction time below the sum of the consuming task cycles. Faster bus cycles also increase CPU and bus load proportionally; the SINAMICS telegram limits typically cap useful bus cycle reduction at 250 µs for standard telegrams.

9. Oversampling I/Os

SIMOTION supports oversampling I/Os for applications that need a finer sampling grid than the bus cycle provides. With oversampling, the SIMOTION runtime samples a configured I/O point multiple times within one bus cycle and buffers the samples for the Servo or IPO task to consume.

Key properties:

• Oversampling increases sampling rate, not reaction time. The reaction time floor remains bounded by the task that consumes the oversampled buffer.
• Oversampling is supported on PN interfaces on SIMOTION V4.4 and later, with a maximum oversampling factor that depends on the firmware version and the CPU class (D4xx vs. P320 vs. P430).
• Oversampling requires that the consuming task (typically Servo) be configured to a cycle time that matches the oversampling factor divided into the bus cycle. For example, a 1 ms bus cycle with a 4× oversample factor feeds a 250 µs Servo task.

10. Intermediate Memory Snapshot Pattern

The common engineering question is: can I read the I/O once at the start of each task and rely on the snapshot throughout the task body? The answer is yes, provided the variable is assigned to that task's process image or read into a local variable at the top of the task. The pattern is:

// At the top of BackgroundTask, IPO_1, or Servo_1:
// Read entire input word once into an intermediate DWORD.
// Then mask individual bits from the snapshot.

// For the BackgroundTask (BOOL defaults to fixed process image):
myInputDword AT %ID0 : DWORD;   // assigned to BackgroundTask process image

// For the Servo/IPO task, either:
//   a) assign the DWORD to that task's process image, or
//   b) read it directly at task start:
IF firstCycleInTask THEN
    cacheDword := %ID0;   // single direct read, then mask
END_IF;

// Use cacheDword.bit0, cacheDword.bit1, ... in the rest of the task.

Two rules follow:

1. The intermediate memory value is identical to the corresponding I/O value only at the moment of the snapshot. It can become stale as the bus cycle advances during the task body, but within one task pass the snapshot is consistent.
2. The value visible in the Servo task is effectively constant within a single Servo pass; it can only change in the IPO task when the Servo-to-IPO ratio is not 1:1 (i.e., the IPO task receives an aggregate of multiple Servo results).

11. Direct Access Pitfalls in Startup and Shutdown

The Address List is evaluated when the SIMOTION runtime initializes the cyclic tasks. In StartupTask and ShutdownTask, the process image may not be fully wired. Code that runs in those tasks must therefore use direct (logical-address) access or, preferably, read into a local variable at the top of the task to ensure a consistent snapshot.

Avoid patterns such as:

// BAD: reads the I/O multiple times, each read can hit a different bus cycle
IF %I0.0 THEN
   IF %I0.1 THEN
      ...
   END_IF;
END_IF;

// GOOD: single read into a local, then bit logic
local := %IB0;
IF local.0 AND local.1 THEN
   ...
END_IF;

12. Commissioning and Verification Checklist

1. In SIMOTION SCOUT / TIA Portal, open the Address List and confirm which variables are assigned to which task's process image. Pay special attention to BOOLs, which inherit the parent byte's assignment.
2. For each task, verify in the Task Configuration that the Servo, IPO, and BackgroundTask cycle times are integer multiples of the DP Integrated bus cycle (the equidistant clock source).
3. Use the Trace function in SCOUT to record both the process image value and the direct logical-address value of a single bit side by side. A clean trace shows the process image lagging the direct value by exactly one bus cycle and never changing within a single task pass.
4. For external CU320 drives, enable the isochronous mode in the PROFIdrive telegram configuration and confirm in the drive parameters (e.g., p0922, p0978) that the slave reports isochronous operation without diagnostic warnings.
5. For oversampling, verify in the task trace that the consuming Servo task is being triggered at the oversampled rate and that the buffer indices advance correctly across task passes.
6. Stress-test the application by injecting a high-frequency toggling input and confirming the program observes a consistent snapshot within a single task pass (no torn reads across multiple bits of the same byte).

13. Troubleshooting Matrix

14. Practical Recommendations

• Assign the whole I/O region you consume to the task that consumes it. Do not mix process-image and direct access for variables that participate in the same control decision.
• For high-speed inputs read in the Servo task, overlay a DWORD from a Sinamics_Integrated telegram and unpack the bits at task start. Avoid reading individual bits directly when the parent is on an external bus.
• Keep BOOLs out of the Address List; declare them as AT % overlays of a BYTE/WORD/DWORD that you have already assigned to the desired task.
• In StartupTask and ShutdownTask, cache any I/O value into a local at the very top of the task body before any branching logic.
• Document the task assignment of every I/O variable in the project's HMI or commissioning notes; it is the single most common source of "why does this input behave differently in the Servo task than in the Background task" questions during commissioning.