Configuring SIMOTION D435-2 I-Device with IM151-8F in TIA Portal

David Krause14 min read
SiemensTIA PortalTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

1. Problem Overview

Engineers who upgrade a SIMOTION D435-2 project that historically exchanges I/O with an IM151-8F PN/DP ET200S station (acting as an I-Device) often find that the I-Device linkage is dropped during the Step7 V5.x → TIA Portal migration. The classic GSDML-based I-Device transfer areas (submodules 1000..1003 etc., 1 byte in / 1 byte out) that previously mapped a SIMOTION output area, e.g. PQB258, to a physical 4DO module at QB38 in the ET200S, no longer survive the import. In addition, the I/Q direction logic in TIA Portal (I ← Q or Q → I) is counter-intuitive for engineers used to the classic Step7 view, which leads to configuration attempts that the software blocks with messages such as "This address is already being used".

This article documents the correct I/O direction model, the migration limitations, and three field-proven workarounds: (a) a TIA-only reconfiguration, (b) a parallel Step7 + TIA approach using the HMI proxy, and (c) replacing the I-Device coupling with a direct ET200S PROFINET interface module on the SIMOTION.

2. System Context and Hardware

Component Catalog / MLFB Role
SIMOTION D435-2 6AU1435-2AD00-0AA0 (typical) Higher-level controller, runs SCOUT/SCOUT TIA project
IM151-8F PN/DP CPU 6ES7151-8FB01-0AB0 ET200S station with integrated CPU, used as I-Device
ET200S 4DO module 6ES7132-4BD30-0AA0 (or -4BF00) 4 digital outputs physically mounted on IM151
PN/PN coupler 6ES7158-3AD10-0XA0 Cross-network PROFINET data exchange
TP1200 Comfort 6AV2124-1MC01-0AX0 HMI panel, programmable only in TIA Portal (WinCC Comfort)

The key constraint driving the whole discussion is that the TP1200 Comfort can only be engineered in TIA Portal, but the IM151-8F I-Device I/O transfer area concept is not fully equivalent between Step7 V5.x and TIA Portal. Migrating the IM151-8F I-Device configuration into TIA therefore requires the GSDML to be regenerated, the project to be re-projected, or an alternative topology to be adopted.

3. I-Device Data Direction Model

The most common source of confusion in both classic Step7 and TIA Portal is the apparent inversion of the I/Q direction when defining transfer areas. The rule is identical in both tools:

  • An output area on the I-Device side (the producer of data) is presented as an input area on the IO controller side (the consumer).
  • An input area on the I-Device side (the producer of status) is presented as an output area on the IO controller side (the writer).

Concretely, in the working Step7 configuration discussed in the source thread, a 4DO module on the IM151-8F is mapped to the SIMOTION PQB258 (1 byte out, default length for a 4DO). When the SIMOTION writes a bit in PQB258, the corresponding bit on the ET200S 4DO module (Q38.0..Q38.3, the byte behind the now-disappeared "QB38") toggles. From the I-Device viewpoint the transfer area is a Q slot; from the SIMOTION IO controller viewpoint the same slot is consumed as an I. TIA Portal exposes the same asymmetry in its "Transfer area" dialog: the user picks I <- Q to publish a controller output to the I-Device, or Q -> I to read an I-Device input back to the controller.

Directional shorthand used in TIA Portal:
• I <- Q  = write controller output bytes to I-Device inputs.
• Q -> I  = write I-Device output bytes to controller inputs.
A physical Q->Q link (one PLC's Q driving another PLC's Q) is achieved only by mapping the I-Device transfer area back onto physical output modules of the IM151 interface; it is not a Q↔Q exchange at the protocol level.

4. Why Migration Drops the I-Device

Step7 V5.x I-Devices are exported as a GSDML file. TIA Portal's migration tool recognizes the IM151-8F CPU as a third-party PN device only when imported via the GSDML; it does not carry over the I-Device slot configuration that lived in the Step7 project on the controller side. As soon as the SIMOTION SCOUT project (or the Step7 SIMOTION sub-project) is migrated, the link to the IM151-8F transfer area is severed, and a "rebuild" attempt in TIA is blocked because the address proposed (e.g. QB38) is flagged as already used by the still-present ET200S 4DO slot.

Symptoms observed in the field:

  • Project migration finishes without errors, but the IM151-8F shows up as a generic PROFINET device, and the I/O transfer area is missing.
  • Re-importing the GSDML produces a duplicate device, and the address book now contains two conflicting entries for the 4DO slot.
  • Compiling the TIA project fails with "Address Q38 is already assigned" or, when the user accepts the next free byte Q43, the TIA compiler accepts the configuration but the hardware on the IM151-8F has no module at Q43 — outputs never toggle.

5. I-Device vs. Shared Device — What Each Solves

Function I-Device Shared Device
Purpose Exposes pre-defined I/O transfer areas from the I-Device to one (or more) higher-level controllers as a process image. Allows multiple IO controllers to share the same physical I/O modules of one station by partitioning the slots.
Module addressing Transfer areas are mapped to bytes in the IO controller; physical slots of the I-Device are hidden. Each controller is granted a subset of physical slots; the same slot cannot be claimed twice.
When used in this context Wanted behaviour: SIMOTION writes to PQB258, ET200S 4DO at QB38 follows. Alternative behaviour: SIMOTION and another controller each own different ET200S modules directly, no I-Device CPU needed.
Tool support in TIA Available for S7-1500/ET200SP CPU and SCALANCE, but limited for ET200S class devices. Available for S7-1500/ET200SP and selected IM151 versions.

If the engineering goal is simply "SIMOTION drives the 4DO on the ET200S station", the cleanest solution is not an I-Device at all, but a direct PROFINET connection from the SIMOTION to an ET200S interface module (IM151-3 PN HF or IM151-1 PN). The IM151-8F CPU becomes redundant. This is the path recommended by Siemens support for SIMOTION D4x5-2 projects migrated to TIA Portal.

6. Three Workarounds Compared

# Approach Project split HMI coverage of IM151 Risk
A Re-engineer the I-Device transfer area in TIA Portal, keep one consolidated project. TIA only (SCOUT TIA / TIA multi-project) Yes, integrated Higher — TIA may not offer the same transfer-area granularity that Step7 V5.x did for the IM151-8F.
B Keep the Step7 project with the I-Device GSDML, build a thin "HMI proxy" S7-1500 in TIA, route tags through a PN/PN coupler. Step7 + TIA, PN/PN coupler Yes, via proxy Medium — two projects, version sync risk.
C Drop the IM151-8F CPU, replace it with an ET200S interface module (IM151-3 PN HF or IM151-1 PN) on the SIMOTION PROFINET. TIA only Yes, integrated Lowest — standard SIMOTION → PROFINET IO device, no I-Device semantics.

7. Approach A — Re-Projecting the I-Device in TIA Portal

Use this approach only when the IM151-8F must remain a programmable station (i.e. it carries its own logic or local HMI tags that the HMI needs to read).

  1. In TIA Portal, open the multi-project that contains the SIMOTION D435-2 device.
  2. Add the IM151-8F as a PROFINET device using the GSDML file of the IM151-8F (Devices & Networks → Install GSDML). Do not search for it as an S7 CPU — the GSDML represents the I-Device, not the CPU.
  3. Open the IM151-8F device view, navigate to the slot index, and configure a 1-byte output transfer area (default is enough for a 4DO module). The slot number becomes the I-Device side number; the address on the I-Device is fixed (Q38 in this case) and not editable from the controller side.
  4. In the SIMOTION device view, add the IM151-8F as a PROFINET IO device and select the transfer area defined in step 3 as an input area on the SIMOTION side. The address proposed by TIA may differ from PQB258; if PQB258 is hard-coded in the SCOUT program, set the SIMOTION-side address back to 258 in the I/O addressing dialog.
  5. Compile both devices (SCOUT TIA + WinCC) and download.
Address conflict mitigation:
If TIA rejects the original address because it collides with the device's own physical output, do not accept the next free address. Instead, route the transfer area through a PN/PN coupler or remap the SCOUT program to the new address and update all HMI tags in lockstep.

8. Approach B — Step7 + TIA with HMI Proxy and PN/PN Coupler

This is the path of least disruption when the IM151-8F I-Device has been working for years in Step7 and the SIMOTION logic still expects the legacy PQB258 mapping.

  1. Keep the Step7 V5.x project with the IM151-8F I-Device and the SIMOTION D435-2 SCOUT sub-project.
  2. Export the IM151-8F configuration as a GSDML ("Export I-Device GSDML") and re-import it on the SIMOTION side in Step7.
  3. Add a small S7-1500 (e.g. CPU 1511-1 PN, 6ES7511-1AK02-0AB0) in TIA Portal as the "HMI proxy". Expose the HMI-relevant tags from the SIMOTION side as PROFINET transfer areas on a PN/PN coupler (6ES7158-3AD10-0XA0).
  4. Connect the TP1200 Comfort to the S7-1500 proxy, not directly to the SIMOTION. The TP1200 reads the proxy's process image, which in turn is fed from the SIMOTION via the PN/PN coupler.
  5. Any time the Step7 project name changes, the proxy must be re-linked to the new HMI tag prefix — this is the source of the "bug" risk noted in the field; plan a naming convention that is stable across Step7 save-as cycles.
Pitfall: When the PN/PN coupler is used to pass SIMOTION → IM151-8F traffic, the coupler must be placed on a separate PROFINET subnet, not the same one that hosts the I-Device link. Otherwise, the I-Device and the proxy will compete for the same IO controller role.

9. Approach C — Direct ET200S Coupling to SIMOTION (Recommended)

This is the topology Siemens application engineering recommends for SIMOTION D4x5-2 with ET200S expansion. The IM151-8F CPU is replaced by an interface module; the SIMOTION becomes the IO controller for the ET200S.

  1. Replace the IM151-8F PN/DP CPU with an IM151-3 PN HF (6ES7151-3BA60-0AB0) or IM151-1 PN (6ES7151-1BA02-0AB0) interface module, depending on the backplane width. Power modules (PM-E 24 V DC) must be retained.
  2. Insert the existing 4DO module at the same slot position it occupied behind the IM151-8F; the I/O address is recomputed by the SIMOTION PROFINET configurator and will likely shift from Q38 to the next free byte on the SIMOTION side, typically Q0..Q3 for the first 4DO on the first PROFINET device.
  3. In SCOUT TIA (or TIA multi-project), add the IM151-3 PN HF as a PROFINET IO device of the SIMOTION. Configure the device name and IP address on the interface module either via PRONETA or by writing the topology in TIA and downloading.
  4. Add the TP1200 Comfort to the SIMOTION PROFINET as before. Tags from the 4DO module are exposed as standard SIMOTION I/O, fully visible in WinCC without any proxy.
Module Order number (MLFB) Function
IM151-3 PN HF 6ES7151-3BA60-0AB0 ET200S PROFINET interface, recommended for D4x5-2
IM151-1 PN 6ES7151-1BA02-0AB0 ET200S PROFINET interface, lower cost, no DI/DO on the IM
PM-E DC 24 V 6ES7138-4CA01-0AA0 Power module feeding the backplane
4DO DC 24 V / 0.5 A 6ES7132-4BD30-0AA0 The 4DO module, retained from original build

10. Configuring the Transfer Area Length

A 4DO module requires one transfer byte. If multiple 4DO modules are exposed to the SIMOTION through the same I-Device, the transfer area must be widened:

Number of 4DO modules Transfer area length Typical SIMOTION start address
1 1 byte out PQB256 or PQB258
2 2 bytes out PQB256
5 (case in the source thread) 5 bytes out PQB256
8 (8 × 4DO = 32 bit) 4 bytes out PQB256

Length must be a whole number of bytes; bit-packing is not permitted at the transfer-area level. If the application requires a 16-bit or 32-bit group, reserve the next free byte so that word alignment is preserved on the SIMOTION side (Word 256, Word 258, etc.). Misalignment produces inconsistent reads when the SIMOTION samples the input area faster than the I-Device updates it.

11. Verification Procedure

  1. With the SIMOTION in STOP, use the Watch table in SCOUT to write a test pattern to the mapped PQB range (e.g. PQB258 = 16#A5).
  2. Switch SIMOTION to RUN. Read back the same byte from the I-Device's physical output: in the IM151-8F, use a VAT in Step7 to monitor QB38; in the IM151-3 PN HF, monitor the device's actual output byte via the SIMOTION I/O diagnostics.
  3. Cycle the power on the ET200S station. After re-boot, the SIMOTION should re-establish the AR (Application Relationship) within the PROFINET watchdog window (default 3 × 250 ms = 750 ms). If the AR fails, the affected slot turns red in the SIMOTION diagnostics.
  4. From the TP1200, force a bit on one of the 4DO outputs and confirm the same bit reads back as a status on a screen with a status indicator.
  5. Check the SIMOTION diagnostic buffer for entries with ID 502 (PROFINET IO device failure) or ID 503 (PROFINET IO device returns). Repeated entries with rising frequency indicate the AR is flapping and the topology needs to be re-checked.

12. Troubleshooting Matrix

Symptom Likely root cause Action
"Address is already in use" when configuring the transfer area in TIA. Physical module is still assigned that address in the I-Device view. Remove the duplicate from the device view, or accept the TIA-proposed address and remap the SCOUT program.
Output does not toggle, but no diagnostic entry. Direction reversed: SIMOTION is reading instead of writing. Confirm the transfer area slot is an output on the I-Device and an input on the SIMOTION side. Reverse the assignment if necessary.
TP1200 loses variables after a Step7 save-as with a new project name. HMI proxy tag prefix changed. Re-link the HMI tags in the S7-1500 proxy and use a stable HMI tag naming convention.
AR (PROFINET) goes up and down repeatedly. Watchdog timeout too tight, or two IO controllers on the same I-Device without Shared Device configuration. Increase the PROFINET update time on the I-Device slot to 1 ms or 2 ms; if a second IO controller is present, configure the device as a Shared Device and assign each slot to one controller.
Migration drops the I-Device link. Step7 V5.x I-Device GSDML is not re-imported into TIA. Re-import the GSDML, or migrate to direct PROFINET (Approach C).
SIMOTION does not see the IM151-8F after download. Device name or IP not assigned on the IM151-8F. Use PRONETA to assign device name and IP; or download via the TIA topology editor.

13. Notes on the SCOUT / TIA Multi-Project

For projects that include both SCOUT (SIMOTION) and WinCC (TP1200) engineering, Siemens recommends a TIA multi-project: the SCOUT TIA device and the HMI live in the same portal session so that tag changes propagate automatically. The legacy "HMI proxy" trick — keeping the Step7 SIMOTION project separate from the TIA HMI project — is supported but adds a synchronization step that has to be repeated every time the SCOUT or Step7 project is saved with a new name. For long-term maintainability, migrating to direct PROFINET (Approach C) removes this manual synchronization entirely.

Official documentation references for the underlying concepts:

14. FAQ

Why does the I/O direction in TIA Portal appear inverted (I ← Q, Q → I) when configuring an I-Device?

Because the I-Device exposes its own process image to the higher-level controller, an output produced by the I-Device is read by the controller as an input, and vice versa. The shorthand I ← Q in TIA means "controller writes its outputs to the I-Device inputs", and Q → I means "controller reads the I-Device outputs into its inputs". This is identical to classic Step7 V5.x.

Can an IM151-8F PN/DP CPU keep its I-Device role when the rest of the project is migrated to TIA Portal?

Yes, but the I-Device GSDML must be re-installed in TIA, the transfer area must be re-defined, and the SIMOTION-side address may need to be remapped because TIA rejects a transfer-area start address that collides with the device's physical output. If the original mapping is hard-coded in the SCOUT program (e.g. PQB258), TIA will offer a different address and the SCOUT program must be updated in lockstep.

What is the cleanest way to give a SIMOTION D435-2 control of an ET200S 4DO module without keeping an IM151-8F CPU?

Replace the IM151-8F with an IM151-3 PN HF or IM151-1 PN interface module, connect it directly to the SIMOTION PROFINET, and add the 4DO at the appropriate slot. No I-Device semantics are needed; the SIMOTION becomes the IO controller and the 4DO becomes a standard PROFINET slot with a normal output address (typically Q0..Q3 for the first 4DO).

Is the HMI proxy with a PN/PN coupler still supported when migrating to TIA Portal?

Yes. The TP1200 can be programmed only in TIA, so a small S7-1500 (e.g. CPU 1511-1 PN) is added in TIA as an HMI proxy, and a PN/PN coupler (6ES7158-3AD10-0XA0) exchanges tags between the SIMOTION/Step7 subnet and the TIA subnet. The downside is that any rename of the Step7 project requires the proxy to be re-linked.

How many 4DO modules can one I-Device transfer area carry?

The transfer area length is a whole number of bytes, so a single transfer area carries up to eight 4DO modules (8 × 4 bits = 32 bits = 4 bytes). If more than eight 4DO modules must be exposed, additional transfer areas must be defined; each area starts at the next free byte on the SIMOTION side and is word-aligned to avoid read inconsistency.

Back to blog