S7-1200 TIA Portal V10.5 I/O Address Mismatch: Root Cause and Field-Proven Fix

A SIMATIC S7-1200 DI module configured with Start Address = 8 / End Address = 8 in TIA Portal V10.5 reads the physical inputs correctly, but the configured byte (IB8) never toggles. The live state shows up on IB1 instead. The CPU keeps running because the user program references IB1, masking the configuration defect. This is a documented V10.5 hardware-configuration compiler bug. The fix is to migrate the project forward and update the PLC firmware; patching V10.5 will not repair it.

1. Problem Description

The machine configuration that triggers the defect:

• CPU: SIMATIC S7-1200 — CPU 1212C (6ES7212-1AE40-0XB0), CPU 1214C (6ES7214-1AG40-0XB0), CPU 1215C (6ES7215-1AG40-0XB0), or CPU 1217C (6ES7217-1AG40-0XB0).
• Engineering: TIA Portal V10.5 with the latest available service pack installed.
• Slot 2: 8-channel digital input module — typically SM 1221 DI 8 x 24 V DC (6ES7221-1BF32-0XB0) — or the on-board DI of the CPU itself, depending on how the project device view is laid out.
• Configured start address: 8.
• Configured end address: 8.
• Observed behavior: IB8 never changes; IB1 reflects the live state of the module.
• User program: reads IB1; the machine runs as designed.
• Online / offline comparison: TIA Portal V10.5 reports "identical" even though the device view shows address 8 and the program resolves to address 1.

The address choice itself is legal — eight digital inputs occupy one byte, and pinning that byte to IB8 is a permitted configuration. The defect is not the address; the defect is that TIA Portal V10.5 fails to commit the new start / end address to the offline hardware configuration (HW Config) database after a manual change, while the program block the user wrote still references the previous address (IB1).

2. Why TIA Portal V10.5 Is the Primary Suspect

TIA Portal V10.5 was the first commercially released version that integrated STEP 7, WinCC, and the S7-1200 tool chain into a single shell. The integration was incomplete in three areas that directly affect I/O address consistency:

1. Split source of truth. The hardware configuration editor and the program editor did not share a unified address model. The S7-1200 plug-in used its own internal address table that occasionally diverged from the central HW Config store, so the address shown in the device view could be different from the address resolved at compile time.
2. No recompile trigger on address change. Manual start / end address changes on a slot module were not always flagged as a configuration change that required a full project recompile. The project was silently re-used with the previous address, and the new value was written to the device view but not propagated to the program blocks.
3. Weak online / offline compare. The Compare online / offline function reported structural identity even when the symbolic-to-absolute mapping for I/O tags differed, because it compared block signatures and not effective address resolution. The user sees "identical" and assumes the project is correct.

Subsequent V11, V13, and V16 releases rewrote the S7-1200 plug-in onto a unified address model and added a forced recompile prompt whenever start / end address values are changed in the device view. V10.5 cannot be patched to that level of consistency; it is fundamentally limited by the architecture that shipped. The SIMATIC S7-1200 Programmable Controller System Manual documents the unified address model that the V10.5 release pre-dates.

3. S7-1200 I/O Addressing Fundamentals

Understanding the default address model is required to recognize when a project is in a non-default state and to interpret the diagnostic results.

3.1 Address assignment order

TIA Portal assigns I/O addresses in the order the modules appear in the device view, starting at byte 0 for the on-board I/O of the CPU and continuing through the signal modules (SM), communication modules (CM/CP), and board I/O. The assignment can be:

• Automatic (default): addresses are assigned contiguously from byte 0 in slot order.
• Manual: the engineer pins the start address of a specific module; the end address is computed from the channel count and the data type.

For a CPU 1214C DC/DC/DC with on-board DI 14 x 24 V DC and DO 10 x 24 V DC, the default mapping on firmware V4.x is:

The reported project has the SM 1221 on Slot 2 manually pinned to start address 8. The original (un-pinned) start address would have been byte 2 because the on-board DI of the CPU occupies bytes 0 and 1. The pin to byte 8 means the engineer deliberately reserved bytes 2 through 7 for other modules (real or planned) further down the rack.

3.2 Symbolic versus absolute access

Every I/O address can be accessed two ways:

• Absolute: %IB8, %I1.0, IB8, I1.0 in LAD/FBD. The address is hard-coded in the block.
• Symbolic: a tag name declared in the PLC tag table (for example Conveyor_Start_PB bound to %I8.0). The tag table stores the binding; the block stores only the tag name.

TIA Portal V10.5 has a known defect in the tag table editor: when a tag's I/O binding is changed and the project is recompiled, the absolute address recorded inside the program block is not refreshed if the tag name is unchanged. The user sees the new address in the tag table but the block resolves to the old address at runtime. This is the exact mechanism behind the IB8-configured / IB1-observed symptom in the field.

4. Root Cause Analysis

The IB8 / IB1 mismatch is a tag-binding cache defect in TIA Portal V10.5, not a CPU firmware defect. The S7-1200 CPU executes the program exactly as the project was compiled, including the wrong absolute address. The discrepancy is in the engineering tool:

1. Engineer opens the device view for Slot 2, changes the start address from 2 to 8, confirms the dialog.
2. The device view writes the new value to the HW Config store and displays it in the slot properties.
3. The PLC tag table is auto-updated to show %I8.0 for the symbolic tag — the binding is correct in the tag table.
4. The user program block contains the old absolute reference IB1 because the compiler cache is keyed on the tag name and not the address. The cache is not invalidated by the address change in V10.5.
5. On download, the program block is sent to the CPU unchanged. The CPU reads IB1, which is the original default address of the module.
6. The online / offline compare compares block signatures; the block signature is unchanged because the block content is unchanged. The result is "identical".

The match row is the root of the diagnostic confusion: every layer except the device view and the tag table agrees, so the user concludes the project is correct. The only way to expose the defect is to bypass the block-signature compare and look at the absolute address inside the program block directly (right-click the contact or coil and select Go to tag, then switch the inspector to Address in the program, or open the block in STL and inspect the operand).

5. Diagnostic Procedure

Use this sequence to confirm the V10.5 tag-binding cache defect on the affected project before doing any migration work.

1. Open the project in TIA Portal V10.5 and go online. The CPU must be in RUN or RUN-P; STOP is acceptable for read-only diagnostics.
2. Open the device view and inspect Slot 2. Note the start and end address shown in the module properties. In the affected project, the start / end are 8 / 8.
3. Open the PLC tag table and inspect the tags bound to the module. The tag binding should be %I8.0 through %I8.7.
4. Force a physical input high on channel 0 of the module. A jumper from the 24 V sensor supply to terminal 0 of the DI is sufficient for a bench test. Watch the CPU online tag table — does %I8.0 go high? It will not, because the binding is decoupled from the runtime address in V10.5.
5. Watch the address IB1 in the online monitor. Bit I1.0 will follow the physical input. This proves the CPU is reading byte 1, not byte 8.
6. Open the program block that references the input and inspect the absolute operand. In LAD/FBD, right-click the contact or coil and select Go to tag — the dialog will show the symbolic tag, not the absolute address. Switch the inspector to Address in the program to see the absolute address. In the affected project, the absolute address is IB1 even though the tag binding is %I8.0.
7. Run Compare online / offline at the project level. V10.5 will report no differences because the block signature is unchanged. This is the misleading result that masks the defect.
8. Export the program block as STL and re-import it into a text editor. Search for IB 1 and IB 8. The block contains IB 1; the device view says IB 8; the tags resolve to IB 8. The mismatch is now visible at the source-code level.

Steps 5 and 8 are the two diagnostic steps that V10.5 cannot obscure. If they confirm the address split, the project is a victim of the tag-binding cache defect and must be migrated to a fixed TIA version.

6. Immediate Workaround (Keep the Machine Running)

If the machine must stay in production while the migration is planned, the fastest non-invasive workaround is to leave the program reading IB1 and correct the device view to match — not the other way around. Concretely:

1. Open the device view, Slot 2.
2. Change the start address from 8 to 1 and the end address from 8 to 1.
3. Open the PLC tag table and re-bind all tags for the module to %I1.0 through %I1.7.
4. Compile the project. The compiler in V10.5 is correct for tag bindings that have not been changed (the binding is whatever the tag table says), so the program blocks will compile against IB1 and the device view will agree.
5. Download the configuration only (not the program — the program is already correct as far as V10.5 is concerned). The CPU receives a consistent configuration and program pair.

This is a workaround, not a fix. The tag-binding cache defect remains in V10.5 and will resurface the next time someone changes an address. Schedule the project migration as soon as the production window allows.

7. Permanent Fix — Project Upgrade Path

The only durable fix is to migrate the project off TIA Portal V10.5. The supported migration ladder, with the version-specific notes that matter for an S7-1200 project, is:

Do not skip steps. TIA Portal does not support arbitrary version jumps during migration; the project must be opened, saved, and compiled in each intermediate version to be portable to the next. The file format is forward-compatible only — a V10.5 project cannot be opened in V16 directly.

7.1 TIA Portal version compatibility matrix

7.2 Migration procedure

1. Archive the V10.5 project. File → Archive → Project. Save the .zap10 archive to a versioned network share; this is the only source of truth for rollback if a step fails.
2. Install TIA Portal V11 SP2 side by side with V10.5. Both versions can coexist on the same engineering station; the project file is opened exclusively by the active version. Do not uninstall V10.5 until the migration is complete and verified.
3. Open the V10.5 project in V11 SP2. The migration wizard runs automatically. Accept the default mapping for CPU firmware, HMI tags, and recipe data. Review the migration log for any warnings about unsupported blocks or libraries.
4. Compile the project in V11 SP2. The compiler rebuilds the tag-to-address bindings from the tag table. Expect the warning Address range adjusted on Slot 2 — this is the migration tool re-aligning the address bindings to match the device view. Accept the adjustment.
5. Compare online / offline in V11 SP2. The V11 SP2 compare engine compares effective address resolution, not just block signatures. Any address mismatch that V10.5 hid will now be flagged.
6. Repeat the migration ladder through V13 SP2 and finally V16. Each step re-compiles and re-binds.
7. Test the migrated project on a bench CPU identical to the production CPU (same order number, same firmware) before downloading to the running machine. The bench test must exercise every DI / DO channel that the project touches; the V10.5 cache defect can leave residual mismatches in modules that were not manually re-pinned.

8. PLC Firmware Upgrade

Even after the project is migrated, the S7-1200 CPU firmware should be brought to a current production-grade version. The baseline target is firmware V2.2 for CPUs that are not yet on V4.x; the current production target is V4.5 (or later, as released by Siemens) for new deployments.

8.1 Determine the current firmware

1. Go online with the CPU in TIA Portal.
2. Right-click the CPU in the project tree → Online & diagnostics.
3. Open Diagnostics → CPU information. The Firmware version line shows the active version (for example, V2.0, V2.2, V4.4).

8.2 Supported upgrade paths

Firmware cannot be downgraded. Always confirm the upgrade target is supported for the exact CPU order number in the SIMATIC S7-1200 Programmable Controller System Manual and in the firmware download entry on the Siemens Industry Online Support portal before starting the update.

8.3 Firmware update procedure

1. Download the correct firmware .upd file from the Siemens Industry Online Support portal (search for the CPU order number, e.g. 6ES7214-1AG40-0XB0).
2. Connect the engineering station directly to the CPU's PROFINET interface. The firmware update is not supported over routed networks.
3. Open the project online in TIA Portal V16 (or the version matched to the new firmware).
4. Right-click the CPU → Online & diagnostics → Functions → Firmware update.
5. Browse to the .upd file and select the active firmware slot (slot 1 for the CPU).
6. Click Run update. The CPU goes to STOP, erases the active firmware, programs the new firmware, and performs a restart. The process takes 2–5 minutes for a V2.2 target and 5–10 minutes for a V4.x target.
7. After the restart, the CPU is in STOP with a clean memory. Download the migrated project to the CPU and perform a CPU reset to factory defaults (MRES) to clear any residual V10.5 configuration data.

9. Verification

After the project is migrated and the firmware is updated, confirm the fix with this checklist. Every item must pass before the machine is returned to production.

1. Device view shows the configured address. Slot 2 start / end = 8 / 8 in the project file. Re-open the project from the archive to confirm the value persists.
2. PLC tag table shows the configured address binding. Tags for the module are bound to %I8.0 through %I8.7.
3. Program blocks reference the configured address. Open each block in STL and search for IB . The address must be IB 8, not IB 1. The Address in the program inspector must show the configured value.
4. Online / offline compare reports no differences in TIA Portal V16 with the new compare engine (which compares effective address resolution).
5. Physical input forces update the correct address. Force a physical input high on channel 0 of the module. The online monitor for %I8.0 must go high within one scan cycle. %I1.0 must remain unaffected.
6. Scan cycle time is within the engineered budget. The V10.5 project on V4.x firmware can run faster than the original V10.5 / V2.x pair. A scan cycle time that drops below 50% of the engineered budget is a sign that a previously broken block (due to the V10.5 cache defect) is now executing correctly; verify the cycle time is intentional.
7. HMI tags resolve to the correct address. Any HMI tag bound to the module must resolve to %I8.0, not %I1.0. Test the HMI screen with a forced physical input.

10. Related Concept — Discrepancy Time in F-Modules

The IB8 / IB1 split is one form of discrepancy between the address the engineer sees and the address the CPU executes. The same conceptual problem appears in a different form in fail-safe (F-) input modules: the safety program expects both channels of a redundant input to agree within a defined window, and flags a discrepancy error if they do not. The diagnostics, the parameter, and the response of the safety program are documented in the official SIMATIC Safety manual collection on the TIA documentation portal.

For a fail-safe analog input module such as the ET 200MP F-AI 8 x I 0/4..20 mA (6ES7536-1MF00-0AB0), the discrepancy time is the maximum allowed interval between the two redundant channel updates before the module raises a discrepancy error. A discrepancy error is handled by the safety program in the same way as a channel fault — the affected channel is passivated, the corresponding safety tag is zeroed, and the F-CPU transitions the affected safety function to a safe state. The exact parameter location in the device view is under the channel properties, Discrepancy group. The default value is 100 ms; it can be reduced for fast-reacting safety functions and increased for sensors with long mechanical actuation times. The full parameter reference is published in the SIMATIC Safety F-Modules manual collection, F-AI 8 x I 0/4..20 mA discrepancy-time parameter reference.

The connection to the V10.5 address mismatch is conceptual, not procedural. Both defects manifest as a silent disagreement between what the engineering view shows and what the runtime executes. The mitigation pattern is the same: trust the runtime, not the view, and verify with a forced physical I/O test before commissioning.

11. Troubleshooting Matrix

12. Common Pitfalls and Field-Proven Caveats

12.1 Do not trust the V10.5 online / offline compare

The compare engine in V10.5 compares block signatures, not effective address resolution. A project with the address split defect compares as identical because the block signature is unchanged. Always verify the absolute address inside the program block by inspecting it in STL or via the Address in the program inspector — never rely on the compare result alone.

12.2 Do not rename tags to force a recompile

Renaming a tag forces a recompile and resolves the address split, but it also breaks every reference in the program, HMI, trace, and recipe. The renaming workaround is more expensive in human time than the migration path. Use it only as a last resort on a machine that cannot be stopped for the migration window.

12.3 Do not skip the bench test

The V10.5 cache defect can leave residual address mismatches in modules that were not manually re-pinned. A bench test on an identical CPU is the only reliable way to catch them. The bench test must exercise every channel of every DI/DO module in the project, not just the affected slot.

12.4 Do not assume a clean install of V10.5 SPx is safe

Service packs patch compiler crashes and dialog hangs, not the underlying split source-of-truth defect. A clean install of V10.5 SP5 on a fresh engineering station will exhibit the same address split if the project is re-created from the same source files.

12.5 Do not downgrade firmware

Siemens does not support firmware downgrades on the S7-1200. A firmware update that fails or that introduces a regression cannot be reversed. Always have a known-good spare CPU on the shelf for the firmware migration window.

12.6 Watch for the on-board DI of the CPU

If the project has the on-board DI of the CPU (for example, the 14 inputs of a CPU 1214C) in addition to the SM 1221 on Slot 2, the address split can affect both. The on-board DI starts at byte 0 by default; if it is manually re-pinned, the same V10.5 cache defect applies. Always verify the address of the on-board DI explicitly when diagnosing the project.

12.7 Mind the PROFINET device name after migration

When the project is migrated and downloaded for the first time to a V4.x CPU, the PROFINET device name on the CPU may not match the name in the new project. Clear the PROFINET device name in the CPU's Online & diagnostics before assigning the new name, otherwise the CPU will keep the old name and the engineering connection will fail with a name-resolution error.

13. Summary Table — V10.5 Defect at a Glance

FAQ