Resolving TIA Portal Offline Ladder Network Comparison Alignment

When two engineers edit the same Function Block (FB) in TIA Portal across disconnected offline sessions, the integrated offline / offline block comparison often mis-aligns networks in the left and right viewports. The block editor splits what should be a single paired comparison into two independent "different" entries, even when the F-LAD / F-FBD / F-STL network content is logically equivalent. This article documents the underlying matching behavior, the concrete scenarios that cause the splitter to fire, and the field-proven workarounds that simulate a manual "synchronize from here" command in TIA Portal V15, V15.1, V16, V17, V18, and V19.

1. Problem Details: When the Comparator Splits a Network

The TIA Portal block comparison tool (menu Tools → Compare → Offline/Offline) is designed to align networks in two project blocks by structural equivalence. The editor walks both blocks network-by-network, applying a matching heuristic that is undocumented in the public Siemens knowledge base. When the heuristic decides that the network under the left cursor cannot be paired with the network under the right cursor, it terminates the alignment and treats the remaining content on both sides as unmatched.

Typical user-visible symptoms:

• The status bar reads Different for a network whose textual content appears identical to the engineer.
• The left and right scroll bars desynchronize; the highlight color (default light orange) disappears on the right side.
• Subsequent changes on both sides are reported as two separate delta blocks instead of one.
• The compare tree in the project navigator shows the FB as a single node, but the editor pane has split the comparison into two comparison levels.

Reports of this behavior span at least TIA Portal V10.5 through V19, indicating that the matching algorithm has not been fundamentally reworked across that window. Engineers who maintain long-lived FBs in versioned libraries are the most exposed, because the comparator runs every time two revisions are opened side-by-side.

2. Root Cause: How the Heuristic Decides "Same Network"

Siemens has not published a formal specification of the comparator's alignment function. Field observation and Siemens support escalations (entry ID 109752153 in the Industry Online Support, plus a number of closed advisories) point to a structural signature that includes the following signals, evaluated in order:

1. Network number — a network labeled Network 5 on the left will not match a network labeled Network 7 on the right, even if the logic is identical and the surrounding context is congruent.
2. Title / comment text — when the network title bar text differs in length, casing, punctuation, or trailing whitespace, the comparator may treat the network as distinct.
3. Element count and topology — a contact added in a different column of the LAD network, a coil moved from the rightmost column to a branch, or a parallel contact converted to a series contact alters the internal segment signature.
4. Variable references — a renamed tag, an IEC timer instance re-instantiated under a different DB, or an explicit literal replaced by a constant tag breaks the signature even if the runtime behavior is unchanged.
5. Comment block alignment — multi-line network comments that exist on only one side, or that are ordered differently, can disqualify a network from matching.
6. Open/closed branches and connectors — even a single MCR dependency or unconnected branch label changes the segment hash the comparator uses.

Once any one of these signals diverges, the comparator abandons the current pairing and continues scanning independently on both sides. From that point on, the two views are no longer in lockstep, and the engineer cannot recover a paired view without a workaround.

3. Trigger Matrix: What Splits the Comparison

The table below summarizes common conditions that cause the comparator to break alignment, and the engineering rule that prevents the condition in the first place.

4. Solution A: Force Align Using a Shared Reference Rung

The most reliable field-proven workaround is to deliberately insert a known, identical reference rung into both blocks. The rung must be present on both sides, must be inserted at the same logical position, and must be removed after the comparison has been completed.

4.1 Procedure

1. Open both offline blocks in TIA Portal. Close any other open editors to avoid auto-save conflicts.
2. In Block_Left, insert a new network at the top of the editor pane.
3. Title the network exactly // CMP_ANCHOR_DO_NOT_COMMIT. Use a distinctive string the project search can locate.
4. Add a single normally-open contact driving a discarded tag. The tag must be declared in both blocks' interface (or in a shared PLC tags table) so the compiler does not flag an unresolved symbol.

   // CMP_ANCHOR_DO_NOT_COMMIT
         |      
      ---| |-----( )---   "cmp_anchor_bit"
   

5. Re-compile Block_Left. Confirm no warnings in the inspector.
6. Repeat steps 2–4 in Block_Right, copying the title, contact, and coil verbatim. The tag cmp_anchor_bit must already exist on this side as well.
7. Open Tools → Compare → Offline/Offline and select the two blocks. The comparator now has a guaranteed top-of-block match and will treat subsequent networks as a paired sequence until the next signature divergence.
8. Walk the comparison to the section of interest. Note the network number on each side so you can resume the review after a break.
9. Before saving either block, delete the anchor network on both sides. Confirm the delete with Ctrl+Z undo rehearsal to make sure the deletion does not pull adjacent networks out of order.
10. Recompile both blocks. Diff again with no anchor: the comparator should still split at the same point it did before, but the engineer has now documented exactly where the split occurs.

5. Solution B: Split-Screen Comparison Without the Highlighter

When the comparator cannot be coaxed into alignment at all (e.g., the two blocks have no common network at all), the secondary workaround is to abandon the integrated comparison tool and use the editor's two-pane mode with manual scrolling.

5.1 Procedure

1. Open Block_Left in the editor. Drag the editor tab to the right edge of the workbench until the docking overlay appears. Drop the tab on the right half to create a side-by-side pane.
2. Open Block_Right. Drag its tab into the right pane.
3. Disable the automatic synchronization option if it is enabled (Window → Synchronize Editors).
4. Use the network navigator (the dropdown above the LAD/FBD view) to jump manually between networks. The split is now visual rather than algorithmic, so the engineer is in full control.
5. Add a marker comment on the network where the integrated comparator splits, and replicate that comment on the corresponding network of the other block. This gives a hand-rolled anchor.

This approach loses the integrated compare/sync highlighter, the network-difference marker, and the side-by-side scroll. It gains total control over what is being compared. It is the approach most commonly used by senior commissioning engineers who have long since given up on the integrated tool.

6. Solution C: Use External Text-Level Diff with TIA Portal Export

For program blocks that can be exported to text, the comparison can be moved outside TIA Portal entirely. This is the most reliable approach for long-lived libraries.

6.1 Procedure

1. Install the Siemens S7-SCL source export add-in or use the Export to Source feature available in TIA Portal V16 and later (right-click the block in the project tree → Export → SCL source).
2. Export both blocks as .scl files. The textual representation is canonical for FBD/STL/SCL, and reasonably close for LAD.
3. Run a standard line-based diff (e.g., diff -u left.scl right.scl on a Linux workstation, or FC / Beyond Compare on Windows). Configure the diff to ignore whitespace differences introduced by re-indentation.
4. For LAD blocks, the export is partial; supplement it with a side-by-side screenshot of the networks the diff flags as significant. Paste the screenshots into the code-review record.
5. Re-import the merged source via Import → SCL source in TIA Portal. Recompile to confirm the merge produced a valid block.

This approach is documented in the SIMATIC S7-1500 SCL programming manual chapter on source management. It is the approach preferred by teams that already store their projects under Git, SVN, or TFS.

7. Cross-Version Behavior (V15 → V19)

Siemens has not published a behavior change note for the offline comparator across these versions. The matching heuristic, the visual highlighter, and the network-difference marker are functionally identical from V15.0 through V19.0. The minor versions V15.1, V16, V17, and V18 did not introduce a "synchronize from here" capability, nor did they relax the matching rules.

Engineers who upgraded to a newer TIA Portal version hoping for an improved comparison experience are consistently disappointed. Plan the comparison workflow around the limitation, not around the next release.

8. Feature Request History and How to Submit Feedback

The integrated offline / offline comparator has been a long-standing request target. The most common requests, in order of frequency in the Siemens feedback channels, are:

1. A "synchronize from here" cursor that forces the comparator to re-anchor at a user-selected network.
2. A "pair these two networks" command that explicitly binds a left network to a right network regardless of signature.
3. An alignment filter that lets the engineer exclude specific signals (e.g., title text, comments) from the matching heuristic.
4. A three-way merge for blocks, analogous to Git's three-way merge, with the integrated comparator pre-filling the merge view.

Siemens historically does not maintain a public feature-request portal for TIA Portal. The official channel is the Siemens Industry Online Support entry submission under "Request". Customer support engineers (CSEs) can escalate requests on behalf of their account. Siemens also surveys attendees of the annual Siemens Automation Summit and the SPS trade fair; engineers attending those events should request a slot with the TIA Portal product manager.

9. Engineering Best Practices to Minimize the Problem

The integrated comparator is a good tool for confirming that nothing has changed. It is a poor tool for reviewing exactly what has changed in a busy block. The practices below reduce the frequency with which the alignment splits.

• Compile both branches on the same TIA Portal version before comparing. The auto-inserted ENO handling segments vary by minor version and are a frequent cause of phantom splits.
• Strip network title and comment edits into a separate change set so the logic-only diff is reviewable on its own.
• Lock the instance DB when the FB uses multi-instance DBs; an auto-shuffle of instance numbers is enough to break every network that touches the instance.
• Disable the "format on paste" option in the LAD editor settings. Auto-formatting a pasted contact changes its column index and splits the network.
• Use the SCL export workflow for any block that is reviewed more than twice. The cost of setting up the export is amortized over the second review.
• Maintain a written map of which network in Block_Left corresponds to which network in Block_Right. The map survives TIA Portal upgrades and project re-imports.
• Train reviewers to recognize the split signature: a left network marked Different whose text matches a right network whose scroll position no longer tracks the left.

10. Verification: Confirming the Workaround Worked

After applying Solution A, B, or C, the engineer should confirm the comparison is meaningful. The verification checklist applies to all three solutions.

1. Open the comparator and confirm that the network of interest on the left is highlighted on the right, or — in Solution B — confirm that both network selectors show the same network number.
2. Scroll the left pane. The right pane should follow in Solution A; in Solution B, the engineer must scroll manually.
3. For each of the 6 signals in the trigger matrix (Section 3), confirm that the corresponding signal is identical on both sides. The network is genuinely aligned only if all six signals match.
4. Capture a screenshot of the aligned view and attach it to the code-review record. Screenshots are the only durable evidence that the review covered the intended networks.
5. After the review, delete the anchor rung (Solution A), close the side-by-side panes (Solution B), or revert the merged source (Solution C). Confirm that the block compiles cleanly and that the interface signature is unchanged.

11. Frequently Asked Questions