Resolving PCS 7 V9.1 SFC Technological Action Failures on MotL Blocks

This technical reference documents a recurring failure mode in Siemens PCS 7 V9.1 where a Technological Action configured inside an SFC (Sequential Function Chart, version 9.0 + SP5 + Upd2) does not drive the targeted input of a technological block (for example, MotL.StartAut) and does not reset the command in the Termination step. The article walks through the affected environment, the root cause related to block-contact interconnections, the architectural prerequisites, and a complete step-by-step remediation procedure with verification checks.

1. Problem Description

A technological action assigned inside an SFC step is expected to:

1. Set the target input of a technological block (for example, StartAut.Value := TRUE) at the start of the Initialization or Processing phase.
2. Reset that same input to FALSE in the Termination phase of the SFC, restoring the block to operator-controlled behavior.

Observed symptom on PCS 7 V9.1 with SFC V9.0 + SP5 + Upd2:

• The action appears in the SFC and is correctly assigned to a command (for example, SetStart).
• The action is not executed at runtime; the target input (for example, StartAut of MotL) is never written, or it is written but immediately overwritten.
• No diagnostic event, no SFC error, and no operator message is raised in the OS runtime.
• Manual traces on the block contact show the value flickering or remaining at the last wired source value.

The failure is silent: the SFC will report Action executed successfully even though the technological effect is missing, because the action itself is dispatched correctly. The conflict is downstream at the block I/O.

2. Affected Environment

Always re-validate against the latest SIMATIC PCS 7 V9.1 release notes and update packages before commissioning. The same pattern is known to appear on V9.0 SP4 and later APL revisions; the underlying mechanism is the same.

3. Root Cause Analysis

The root cause is an unintended interconnection at the block contact of the technological block. In PCS 7, a command such as SetStart assigned to a technological action writes directly to the input pin (for example, StartAut) of the target block. If the same input is also wired to another source (for instance, the EPH block contact, an operator faceplate signal, a derived status, or a hand-coded interconnection in the CFC), then:

1. The command's value reaches the input pin.
2. CFC resolves interconnections strictly: the most recently written source wins, and PCS 7 closes the source side of an "auto-generated" command wiring only if no other writer exists.
3. The other writer overwrites the command's value, so the action has no observable effect at the block I/O.
4. On Termination, the command tries to write FALSE to the same input, with the same result — it is silently overridden.

Compounding factors reported in the field:

• Reusing a CMT that was originally configured for direct operator control and then migrated to SFC commands without re-cleaning the block contact wiring.
• Hand-written CFC interconnections inserted to "force" behavior during commissioning tests and never removed.
• Use of legacy Initialization / Processing / Termination tabs in the SFC together with the new Technological Action mechanism on the same input — both write to the same pin, the second writer always wins.
• Using a non-standard interface block for command/status handling, where the SFC Type is connected via a custom block contact rather than the standard APL contact.

4. Architectural Context: CMT, EMT, EPHT

PCS 7 separates the reusable type definition from the instance use. Three template levels are relevant for technological actions:

The correct path for an SFC technological action to drive MotL.StartAut is:

1. The CMT exposes the StartAut input through a block contact.
2. The EMT/EPHT embeds the CMT as a template instance via a role assignment, with the option Basic requirement enabled so that the necessary preconditions for the command are wired automatically.
3. The SFC inside the EPHT/EMT defines a technological action of type "command" (for example, SetStart), maps it to the CMT role, and the framework writes to the CMT's block contact on the host side.
4. The CMT, in turn, is allowed to forward that command to the StartAut input of the MotL instance — only if no other interconnection exists at that input.

When the SFC Type is connected through a custom interface block (an in-house command/status block), the same rule applies but the block contact is the custom block. Mixing standard APL contact wiring with custom command blocks is the most common source of the override described above.

5. Preconditions for Technological Actions to Work

Before assuming a software defect, validate these preconditions in the engineering system:

1. APL version aligned: CMT, EMT, EPHT, and the SFC chart all reference the same APL revision. A mixed-version chart will compile but fail at runtime.
2. Command defined in CMT: Open the CMT, switch to the Commands tab, and confirm that a command such as SetStart exists. Its target must reference a block contact of a technological block inside the CMT (e.g., MotL.StartAut).
3. Role assignment in EPHT/EMT: In the EPHT/EMT, the CMT is inserted as a template instance and the Basic requirement checkbox is enabled. This auto-wires the preconditions (e.g., IsAuto, IsReady).
4. Status/feedback defined: The CMT exposes the feedback (e.g., IsRunning) that the SFC condition uses, mapped to the EPHT/EMT role.
5. No competing writers: Use CFC cross-references on the target input (e.g., MotL.StartAut). There must be exactly one source: the CMT's command output routed via the role assignment. Any other writer — even an inactive one — is a candidate for the override.
6. Compile order: Compile the SFC after the CMT/EMT/EPHT types. Out-of-order compiles can leave dangling references that the SFC then refuses to write.

6. Step-by-Step Solution

The remediation follows a strict sequence. Do not skip steps; the override is reintroduced whenever a hidden interconnection is left behind.

6.1 Identify the conflicting interconnection

1. Open the CFC of the CMT instance that contains the affected MotL.
2. Right-click the input pin (for example, MotL.StartAut) and choose Go to → Interconnection partner (or "Cross-references").
3. Record every writer. Acceptable writers are exactly one: the command output coming from the EPHT/EMT role assignment.
4. If a second writer is found (operator faceplate signal, hand-coded CFC block, EPH contact, or a bridging CFC connection made for testing), mark it for removal.

6.2 Remove the second writer

1. For each non-essential writer, right-click the connection in the CFC and select Delete (or Disconnect).
2. If the writer was placed for test purposes (e.g., a constant TRUE block), delete the source block as well.
3. Save and close the CFC.
4. Repeat for every chart level: instance CFC, master data library CFC, and the EPHT/EMT SFC charts.

6.3 Clean up mixed Initialization/Processing/Termination writers

1. Open the SFC chart inside the EPHT/EMT.
2. Switch to the Properties dialog of every step that previously used the legacy Initialization / Processing / Termination tabs to write to the same input.
3. Remove the legacy write and replace it with a Technological Action referencing the proper command (e.g., SetStart).
4. Save the SFC.

6.4 Re-validate command and role assignment

1. In the CMT, open the command (e.g., SetStart) and confirm that:
   • Target block contact = the input of the technological block (e.g., MotL.StartAut).
   • Initialization / Processing sets the value to TRUE.
   • Termination sets the value to FALSE.
2. In the EPHT/EMT, confirm that the role assignment still has Basic requirement enabled and that the CMT is inserted as a template with the correct role instance.
3. Save and recompile the type.

6.5 Adopt a dedicated command/status interface (recommended)

For projects that already use a custom interface block to decouple the SFC Type from the CMT, define the block contact explicitly:

• One input contact per SFC-controlled value (for example, SetStartCmd).
• One output contact per status returned to the SFC (for example, IsRunningSt).
• A separate block contact (for example, SetAutoMode) for "set to automatic", wired so it never overlaps with command inputs.

This split makes it impossible for a hidden writer to compete with the SFC, because each contact is dedicated to a single source role.

7. Verification Procedure

After applying the fix, verify at three levels.

7.1 Static verification (engineering)

1. Run Compile & Check on the SFC chart. There must be no warnings on the action block.
2. Open Chart → Cross-references on the target input (MotL.StartAut). Confirm exactly one writer.
3. Open the SFC online in the ES. The action must show a green executable indicator before the step is processed.

7.2 Functional verification (AS / OS)

1. Put the controller into Manual and start the SFC.
2. Watch the SFC step transition log: the Technological Action line must report Executed and the target tag (e.g., MotL.StartAut) must transition to TRUE within one OB1 cycle.
3. Force the Termination condition. The action's reset must drive MotL.StartAut back to FALSE within one OB1 cycle.
4. Capture the tag trace and archive it under the change ticket.

7.3 Operator-level verification (OS)

1. Open the MotL faceplate in WinCC Runtime. The Auto lamp must follow the action's state.
2. Run the EPHT/EMT sequence from the batch view. All steps must complete without Action failure messages in the OS message log.
3. Confirm that no spurious operator messages ("command rejected", "interlock active") appear during the action window.

8. Common Pitfalls and Edge Cases

9. Diagnostic Checklist

Use this checklist the first time you encounter a silent SFC technological-action failure on PCS 7 V9.1:

1. Open CFC cross-references on the target input (e.g., MotL.StartAut). How many writers?
2. If more than one, list them and identify which is the CMT's command output.
3. Open the SFC step. Does it use Technological Action only, or also legacy Init/Proc/Term writes?
4. In the CMT, open the command (e.g., SetStart). Are the Initialization, Processing, and Termination values all correct?
5. In the EPHT/EMT, is the CMT inserted as a role instance with Basic requirement enabled?
6. Was the AS fully recompiled, or only the SFC chart delta-downloaded?
7. Does the OS show any interlock, permission, or mode message on the affected block?
8. Is a custom interface block contact wired in parallel to the APL contact?

Each "yes" on a multi-writer, mixed write, partial download, or parallel contact pinpoints one of the documented root causes. Resolve them in this order; do not patch the SFC before clearing the CFC.

10. Version Compatibility Notes

The SFC Technological Action mechanism was extended in the PCS 7 V9.0 time frame and refined in V9.0 SP4 / SP5 / Upd1 / Upd2. The block contact / command interaction is stable across these updates, but the following items differ from earlier releases (V8.2 and older):

If a project is migrated from V8.2 to V9.1, pay particular attention to block-icon mappings and to the legacy SFC steps still writing to inputs that are now reserved for technological actions. The migration tool will not warn about overlapping writers.

11. Preventive Engineering Practices

To avoid the override recurring in future development:

• One input, one role. Treat each SFC-controlled input as reserved; document this in the CMT's interface specification.
• No test interconnections left in production charts. Add a code-review check: "no constant blocks write to command-target inputs in released CMTs".
• Compile order discipline. Compile CMT → EMT → EPHT → SFC for every release; never rely on delta downloads of SFCs only.
• Use the dedicated command/status interface. The custom block is not a workaround — it is the architectural clean separation. Adopt it project-wide.
• Add a runtime tag trace on every technological action's target input. The trace file is the smoking gun when the action runs and the tag does not move.

12. Frequently Asked Questions