Fix SFC Interconnection Cannot Be Moved Error in TIA Portal

The error message "The SFC interconnection cannot be moved to this connection" is raised by the TIA Portal (STEP 7) editor when an engineer performs an Alt+drag-and-drop operation to relocate an existing Sequential Function Chart (SFC) access from one block input/output to another and the proposed target fails the editor's internal validation. This article documents both root causes observed in field service work, the diagnostic workflow to identify which one applies, and the resolution steps to complete the move without losing the SFC linkage semantics.

1. Problem Description

The error is triggered by the following editor sequence:

1. An SFC step, transition, interlock, or supervision already has an access bound to a boolean block input (for example "Conveyor_FB".ModLiOp where ModLiOp is a BOOL input).
2. The engineer selects the SFC access on the interconnection line in the S7 GRAPH editor or the SFC view.
3. While holding the Alt key, the engineer drags the access to a different block input/output (for example "Conveyor_FB".SP_Ext).
4. TIA Portal runs a type check and a semantic check on the proposed target.
5. If either check fails, the editor displays the message and aborts the move. The original interconnection is preserved.

The error is editor-side only; no download is required to trigger it. It is raised in both the offline and online views of the project. In German-localized installations the same message reads "Die SFC-Verschaltung kann auf diese Verbindung nicht verschoben werden."

2. SFC Interconnection Architecture in TIA Portal

Siemens TIA Portal exposes two SFC implementations:

An SFC interconnection is the binding between an SFC element (transition, interlock, supervision, action qualifier) and the boolean tag or block parameter that supplies the value at runtime. The SFC evaluation cycle samples the bound boolean on every scan and interprets it according to the assignment mode stored in the SFC metadata.

For S7 GRAPH, the assignment mode is one of two reserved semantics:

• Interlocked — the condition is ACTIVE when the bound boolean equals TRUE (1).
• Not interlocked — the condition is ACTIVE when the bound boolean equals FALSE (0).

These are not the same as binding the literal constants TRUE or FALSE. The SFC engine stores the assignment mode as a separate attribute of the step/transition and consults it during evaluation. This distinction is the source of one of the two root causes discussed below.

3. Root Cause 1 — Data Type Mismatch

The most common cause of the error is a data type mismatch between the original SFC access and the proposed target. TIA Portal enforces strict type compatibility because the SFC evaluation engine always reads the bound value as a BOOL.

3.1 Typical Scenario

A function block exposes two parameters:

The SFC transition was originally bound to ModLiOp (BOOL). During refactoring the engineer attempts to move the access to SP_Ext (REAL). TIA Portal detects the mismatch and rejects the move. The original message "The SFC interconnection cannot be moved to this connection" is displayed.

3.2 Why the Editor Rejects the Move

If the move were allowed, the SFC evaluation engine would attempt a non-boolean comparison at runtime. The resulting behavior depends on the CPU family and firmware:

• S7-300 / S7-400: implicit conversion of REAL to BOOL is not defined for transitions; the SFC fault bit is set and the affected step enters the error state.
• S7-1500 with strict type checking (default since firmware V2.0): the SFC block fails to compile, or the OB1 cycle raises a Type Conflict error and the CPU enters STOP.
• S7-1500 with permissive type checking: the conversion is performed as BOOL := (REAL <> 0.0), which is almost never the intent of the original logic.

TIA Portal blocks the move at editor time to prevent these runtime faults. The validation is performed against the IEC_Type field of the source and target block interfaces, not against runtime values.

3.3 Detecting the Mismatch

Open both block interfaces:

1. In the project tree, right-click the source FB instance → Open.
2. In the block editor, navigate to the Interface section.
3. Note the data type column for the input/output currently bound to the SFC access.
4. Repeat for the target FB instance.
5. Compare the data types. If they differ, you have identified Root Cause 1.

You can also enable the View → Details → Data Type Information overlay in the interconnection editor to see the resolved data type of each line at a glance.

4. Root Cause 2 — Boolean Assignment Mismatch

The second cause applies specifically to S7 GRAPH interlock and supervision conditions. Even when both source and target connections are BOOL, the editor may still reject the move if the assignment mode of the original SFC access differs from the assignment mode stored for the target connection.

4.1 Reserved Sequencer Names

S7 GRAPH reserves four boolean assignment tokens that the sequencer interprets specially:

The literal values TRUE and FALSE are not interchangeable with Interlocked / Not interlocked. When a step's interlock was defined with assignment Interlocked and you attempt to drag the access to a connection that was previously used with assignment TRUE, TIA Portal raises the same "cannot be moved" error.

4.2 Why the Assignment Mismatch Fails

The SFC access in the project DB stores two pieces of metadata:

• The tag reference (DB number, byte offset, bit offset for BOOL).
• The assignment mode (Interlocked / Not interlocked / TRUE / FALSE / direct).

When Alt+drag is invoked, the editor copies both pieces to the target connection. If the target connection's previous SFC access used a different assignment mode and the editor's consistency check decides the two are incompatible (for example, swapping Interlocked for TRUE would invert the runtime meaning of the same boolean), the move is rejected.

4.3 Diagnosing the Assignment Mismatch

1. Double-click the SFC step or transition in the S7 GRAPH editor.
2. For interlock conditions: open the Interlock tab.
3. For supervision conditions: open the Supervision tab.
4. Note the assignment dropdown — it will read Interlocked or Not interlocked.
5. Open the Properties dialog of the target block input/output. Look for any previous SFC access reference and its stored assignment mode.
6. If the modes differ, you have identified Root Cause 2.

5. Diagnostic Workflow Summary

6. Resolution Procedures

6.1 Resolving a Data Type Mismatch

Choose one of the following options:

Option A — Select a matching target. Identify a different input/output on the target block that exposes a BOOL parameter and attempt the Alt+drag operation again.

Option B — Add a new BOOL input. Open the target FB and add a new parameter (for example bEnableExt : BOOL). Recompile the FB and retry the move to the new parameter.

Option C — Use a comparison block. Insert a comparator (for example GE_REAL from the standard library) that converts the REAL signal to a BOOL output. Connect the comparator's BOOL output to the SFC access. This is the recommended approach when the analog signal represents a threshold.

Option D — Modify the source type. If the application permits, change the source parameter's data type to match the target. Update all downstream consumers of the source.

6.2 Resolving a Boolean Assignment Mismatch

1. Open the SFC step/transition and navigate to the Interlock or Supervision tab.
2. Change the assignment dropdown to the mode required by the target connection (typically Interlocked for interlock conditions, Not interlocked for inverted conditions).
3. If you change the assignment mode, also invert the bound expression to preserve the original logic. For example, an interlock of "FB".bFault with mode Not interlocked is equivalent to NOT "FB".bFault with mode Interlocked.
4. Save the SFC block and recompile the project.
5. Retry the Alt+drag operation.

6.3 Verification Checklist

• [ ] Source and target parameter data types match (both BOOL for SFC).
• [ ] Assignment modes are compatible (Interlocked / Not interlocked / TRUE / FALSE).
• [ ] SFC block compiles without errors.
• [ ] SFC block compiles without SFC-specific warnings in the output window.
• [ ] Alt+drag completes without the error message.
• [ ] The interconnection appears in the new position in the cross-reference list.

7. Block Interface Compatibility Rules

7.1 Access Direction Restrictions

SFC interconnections can target the following parameter directions:

• Input (IN) — allowed.
• Output (OUT) — allowed (the SFC reads the output value).
• InOut (IN_OUT) — allowed but uncommon for SFC conditions.
• Static (STAT) — allowed for multi-instance FBs.

The editor will reject moves to:

• Constant (CONST) parameters.
• Temporary (TEMP) parameters.
• Read-only system-side connections.

7.2 Block Identity Independence

The source and target blocks do NOT need to be the same FB type, instance, or even from the same library. The editor validates only the parameter data type and assignment compatibility, not the block identity. Moving an SFC access from "FB_Conveyor_1".bRun to "FB_Conveyor_2".bRun is permitted as long as both bRun parameters are BOOL.

8. S7 GRAPH vs Basic SFC Behavioral Differences

The boolean assignment mode (Interlocked / Not interlocked) is unique to S7 GRAPH. If you are working with the basic SFC editor available for S7-1500 and ET 200SP CPUs (added in TIA Portal V14 SP1), the assignment concept does not apply — transition conditions are evaluated directly as boolean expressions. The data type mismatch cause (Root Cause 1) still applies.

If you encounter the "cannot be moved" error in basic SFC, the cause is almost always a data type mismatch. Diagnose by following the procedure in Section 3.

9. Multi-Instance and Cross-Station Considerations

9.1 Multi-Instance FBs

When the source or target SFC access targets a parameter of a multi-instance FB (an FB instantiated inside another FB's STAT section), the editor stores the access path as a fully qualified instance name. The path looks like "Parent_DB".Child_Instance.Parameter. When moving the access between two multi-instances, ensure both instance names resolve correctly in the compiled SCL/ST/FBD source.

9.2 Cross-Station SFC Access

If the source and target blocks are in different AS stations or different S7-1500 CPUs of the same project, Alt+drag cannot move the access across the station boundary. TIA Portal raises a different error ("Interconnection across station boundaries is not permitted"). In this case, create a proxy tag in the SFC block's home station and link the proxy to the remote tag via PUT/GET or via an Open User Communication connection.

10. Verification and Field Testing

10.1 Offline Verification

1. Compile the project (Project → Compile → Software (rebuild all)).
2. Open the cross-reference list (Right-click the SFC block → Cross-references) and confirm the new interconnection appears.
3. Check that no orphaned references remain on the old connection.

10.2 Online Verification

1. Back up the current PLC program (Online → Backup).
2. Download the modified SFC block to the PLC.
3. Open the S7 GRAPH viewer (or SFC viewer) in online mode.
4. Force the boolean source to TRUE and observe the transition or interlock activate.
5. Force the boolean to FALSE and observe the transition or interlock deactivate.
6. Test all sequencer paths that depend on the moved access.

10.3 Functional Test Cases

11. Troubleshooting Matrix

12. Related SFC Errors and Edge Cases

Engineers troubleshooting this error frequently encounter related SFC errors that share the same root causes:

• "SFC access cannot be created" — raised when creating a new SFC access (rather than moving one) to an incompatible connection. Resolution is identical: match types or change assignment.
• "Transition condition invalid" — raised at compile when the transition references a non-boolean expression. Add a comparator or change the source tag.
• "Step qualifier conflict" — raised when S7 GRAPH step qualifiers (N, S, R, L, D, etc.) are inconsistent with the interlock mode. For example, qualifier "L" (limited) on a step with a permanent interlock causes an infinite wait state.
• "Sequencer overflow" — raised when the SFC structure exceeds the CPU's maximum step count. Refer to the CPU's SFC resource limits in the device manual.
• "SFC initial step missing" — raised when the SFC has no defined initial step after a refactor.

13. Platform and Firmware Notes

The error and resolution apply to the following TIA Portal versions and target hardware:

For legacy STEP 7 V5.x projects with S7 GRAPH V5.x, the same root causes apply. The menu path to the Interlock assignment differs slightly (S7 GRAPH → Step properties → Interlock tab → Assignment dropdown).

Always consult the Siemens Industry Online Support portal for the latest function manuals, application examples, and firmware compatibility matrices before applying the resolution to a production system.

14. Best Practices for Avoiding the Error

• Standardize tag names. Avoid PLC tag names that collide with reserved SFC tokens (0, Run, Interlocked, Not interlocked). Prefix all boolean tags with a project-specific identifier.
• Use wrapper FBs for mode bits. Centralize mode and interlock signals in a dedicated FB with explicit BOOL inputs. This makes future refactors cleaner and reduces direct PLC-tag dependencies in the SFC.
• Document assignment modes. Add comments to each SFC step explaining why Interlocked vs Not interlocked was chosen. This prevents the next engineer from "fixing" the assignment during a routine refactor.
• Test refactors in a sandbox project. Before applying an Alt+drag move to a production SFC, replicate the structure in a test project and verify the move succeeds and the logic remains equivalent.
• Keep S7 GRAPH and basic SFC separated. Do not mix S7 GRAPH and basic SFC in the same S7-1500 CPU if avoidable; the assignment mode differences cause confusion.