SFC Sequencer Jumps: TARGETSEQ and TARGETSTEP in STEP 7 / PCS 7

Overview

Sequential Function Chart (SFC) is the IEC 61131-3 high-level language for state-driven control. In Siemens PCS 7 and STEP 7, the SFC editor allows engineers to model complex batch and continuous processes as a hierarchy of steps, transitions, and actions. A recurring architectural question is whether a running sequencer can transfer control to a different sequencer inside the same SFC chart and then resume the original flow once that second sequencer finishes. The short answer is yes, but only when the chart is implemented as an SFC type (not a plain SFC plan) and the jump is configured through the system attributes TARGETSEQ and TARGETSTEP assigned in a step action of the source sequencer.

This reference documents the exact configuration path, the syntax for setting and reading the redirection attributes, the practical SEQ1 → SEQ2 → SEQ1 round-trip pattern, the active control strategy change mechanism in PCS 7, and the failure modes you will encounter during commissioning. The article applies to STEP 7 V5.5 with SFC for S7, TIA Portal V15.1 and later with S7-GRAPH/SFC, and PCS 7 V8.2 through V9.1 SP2. Where the syntax differs between platforms, the platform is named explicitly.

Prerequisites

• STEP 7 V5.5 + SPx, or TIA Portal V15.1 or later with the S7-300/S7-400 or S7-1500 SFC support package installed.
• PCS 7 V8.2 or later for the active control strategy change and the SFC faceplate.
• The SFC must be implemented as an SFC type. A pure SFC plan (chart) does not support cross-sequencer target steps.
• Working knowledge of IEC 61131-3 SFC structures: steps, transitions, actions, alternative branches, simultaneous branches with convergence.
• Read/write access to the SFC's instance DB to confirm the runtime values of TARGETSEQ, TARGETSTEP, LASTSEQ, and LASTSTEP.
• The CFC chart that contains the SFC instance must compile without unresolved references; missing tags in a downstream CFC will silently break the operator faceplate.

SFC Type vs. SFC Plan: The Architectural Distinction

Siemens differentiates between two SFC implementation models. Understanding the distinction is the single most important prerequisite for the cross-sequencer jump pattern; the most common commissioning failure is an engineer who builds the chart as an SFC plan, then discovers at runtime that the TARGETSEQ writes do nothing.

SFC Plan (Chart)

An SFC plan is a self-contained chart compiled into a single FB. It exists as one instance, runs as one piece of code in the CPU, and cannot coordinate with a sibling SFC plan. Sequencer jumps inside an SFC plan are limited to the same chart; TARGETSEQ writes targeting a different chart have no effect at runtime. The plan model is appropriate for small, self-contained sequences that never need to redirect control to a sibling.

SFC Type

An SFC type is a centralized definition (the "type") from which multiple instances (DBs) can be derived. All instances share the same step and transition definitions but execute independently at runtime. TARGETSEQ and TARGETSTEP operate on the running instance and the next sequencer of the same instance, so a single type can host SEQ1 and SEQ2 and route control between them. PCS 7 also exposes an active control strategy for SFC types, which is the operator-facing concept behind cross-sequencer coordination.

For the round-trip pattern to work, embed both sequencers inside a single SFC type. The SFC type must be instantiated at least once in the S7 program (PCS 7 creates a default instance automatically). The detailed state diagram of the active control strategy change is documented in the Siemens PCS 7 Compendium Part C — Process Control and SFC, section 7.3.

TARGETSEQ and TARGETSTEP: System Attributes

Two writable system attributes control the redirection; two read-only attributes expose the most recent execution history.

Syntax inside a step action (Command, Action, or Set/Reset block):

<SFC_Instance>.TARGETSEQ := 2;
<SFC_Instance>.TARGETSTEP := 0;

Notes from the Siemens SFC help (also reproduced in the SFC Manual, English edition, pages 43 and 120):

• The target step is honored when the sequencer starts or resumes, and is then deleted from the runtime state.
• All other target steps of the sequencer, including manually set ones from the faceplate, are reset by the assignment.
• Setting TARGETSEQ := 0 clears all pending targets for that sequencer.
• Target steps cannot be assigned inside a simultaneous (parallel) branch.
• Step numbers are assigned automatically by the editor and shown in the step's Properties dialog and in the SFC overview window.

Querying Execution History: LASTSEQ and LASTSTEP

Because the SFC execution can branch, the next jump destination is often conditional on which sequencer/step was active just before. Use the read-only attributes in a transition condition:

// Transition condition of the calling sequencer
IF <MySFC>.LASTSEQ = 3 AND <MySFC>.LASTSTEP = 2 THEN
   <MySFC>.TARGETSEQ := 2;
   <MySFC>.TARGETSTEP := 5;
END_IF;

This pattern is the standard way to implement "if we came from sequencer 3 step 2, then jump to sequencer 2 step 5; otherwise continue normally". Without it, you cannot distinguish multiple inbound paths into a single jump point. LASTSEQ and LASTSTEP are updated by the runtime at every sequencer transition; they are also useful for audit logging in the PCS 7 SFC trace.

Practical Example: SEQ1 → SEQ2 → SEQ1 Round Trip

Use case: an SFC type RecipeSFC contains two sequencers.

• SEQ1 (number 1): the main recipe, steps 1–20.
• SEQ2 (number 2): a CIP (clean-in-place) cycle, steps 1–10.

Requirement: at step 12 of SEQ1, branch into the CIP cycle. When the CIP cycle finishes, resume SEQ1 at step 13.

Step 1 — In the command/action of step 12 of SEQ1

RecipeSFC.TARGETSEQ := 2;     // target sequencer = CIP
RecipeSFC.TARGETSTEP := 0;     // start at the CIP initial step

The transition of step 12 then advances the sequencer. When the sequencer is told to resume, the runtime consumes the target and loads SEQ2 at step 0.

Step 2 — In the command/action of the last step of SEQ2 (e.g. step 10)

RecipeSFC.TARGETSEQ := 1;     // back to main recipe
RecipeSFC.TARGETSTEP := 13;    // resume in SEQ1 after the jump point

When SEQ2's last step finishes, control transfers to SEQ1 step 13 and the recipe continues.

State Diagram (SVG)

Figure 1 — Round-trip control flow between SEQ1 and SEQ2 inside one SFC type. The dashed vertical link inside SEQ1 indicates that step 13 is the resume target after SEQ2 returns; the linear path between step 12 and step 13 is skipped at runtime.

Active Control Strategy Change in PCS 7

PCS 7 extends the SFC type model with an active control strategy. Each SFC type instance can have one or more control strategies (e.g. "Production", "Cleaning", "Sterilization"). The active strategy determines which sequencer path is currently controlling the process. The active control strategy change allows the operator (or the SFC itself) to switch strategies while the SFC is running.

Combined with TARGETSEQ/TARGETSTEP, the pattern is:

1. The active strategy of instance A finishes its current step.
2. The step action writes TARGETSEQ/TARGETSTEP on the next strategy (instance B).
3. The active strategy is then switched to instance B.
4. When instance B's target sequencer is exhausted, the original strategy resumes via the reverse assignment.

Operator interface configuration (faceplate buttons, authorization levels) is documented in the PCS 7 Compendium Part C, section 7.3. The runtime block SFC_RTM exposes the strategy change events for trending and audit.

Conditional Round-Trip: Using LASTSEQ to Drive the Target

Many real recipes need to resume at different steps depending on how the secondary sequencer exited. Extend the basic pattern with a LASTSEQ/LASTSTEP query in the last step of SEQ2:

// In the last step of SEQ2, choose the resume point in SEQ1
IF <MySFC>.LASTSTEP < 5 THEN
   // CIP aborted early; resume at the cleaning verification step
   <MySFC>.TARGETSEQ := 1;
   <MySFC>.TARGETSTEP := 15;
ELSE
   // CIP completed normally; resume at the next recipe step
   <MySFC>.TARGETSEQ := 1;
   <MySFC>.TARGETSTEP := 13;
END_IF;

This pattern keeps the round-trip declarative and avoids hard-wiring the exit path from the CIP sequencer back into the recipe sequencer.

Cross-Instance Coordination: Two SFC Instances of the Same Type

If two SFC instances of the same type need to coordinate (e.g. RecipeSFC_A and RecipeSFC_B share a cleaning cycle), use a coordinating DB to pass the target values:

// In a transition of RecipeSFC_A
IF CleaningCycleDone THEN
   RecipeSFC_B.TARGETSEQ := 2;
   RecipeSFC_B.TARGETSTEP := 0;
END_IF;

Both instances belong to the same type, so the runtime attributes are reachable from either instance's step actions. The alternative — using a separate "coordinator" SFC type that writes to both instances — is also valid and is sometimes preferred for clarity in large unit-coordination projects.

Limitations and Edge Cases

• Simultaneous branches: Target steps set inside a parallel branch are ignored by the runtime. Move the assignment to the convergence point downstream of the branch.
• Multiple writes: If TARGETSEQ/TARGETSTEP are written in more than one step action before the sequencer resumes, only the last assignment is effective. The runtime clears the prior values during the resume cycle.
• TARGETSEQ = 0: This reserved value clears all pending targets. It is the default after a successful jump or a cold restart.
• Cross-instance jumps: The pattern only works between sequencers in the same SFC type instance, or between coordinated instances of the same type. Jumps between unrelated SFC types require an external coordination block (e.g. a shared data block or a sequencer flag in the CFC).
• Operator mode override: In "Manual" operator mode, the operator can set a target step from the faceplate. A program-level assignment is still consumed at the next start/resume, but the operator value is lost.
• Initial start vs. resume: A target set before the very first start of a sequencer is honored on that first execution only. Subsequent cold restarts require a fresh assignment from a step action or an operator input.
• Hot restart on CPU fault: After a CPU STOP→RUN hot restart, the SFC runtime restores the last active step but does not preserve pending TARGETSEQ/TARGETSTEP. Add an initialization action in step 0 that re-issues the target if the operator expects the jump to survive a fault.
• Compiler warnings: "Unreachable step" or "Missing convergence" warnings during SFC compilation both indicate a topology error that will block the jump. Treat them as errors, not warnings.
• OB1 cycle budget: SFC types with many step actions and several instances can push the OB1 cycle time. Use the SFC chart properties to set a maximum cycle budget and trigger a CPU stop on overrun if your process requires deterministic response.

Verification and Commissioning

1. Compile and download the SFC type to the AS. Check the compiler log for "Unreachable step" or "Missing convergence" warnings—both indicate a topology error that will block the jump.
2. Open online monitoring with PCS 7 SFC Visualization or TIA Portal "SFC Trace". Verify TARGETSEQ and TARGETSTEP show the expected values just before the jump step is left.
3. Step through manually using the SFC faceplate's "Step" button in operator mode. Confirm the round-trip path matches the design.
4. Watch the active step time in the trend. The active step time should reset to zero at the jump boundary. If it does not, the target was not consumed (likely because the sequencer was in a state that ignores the target, e.g. "Held" or "Completing").
5. Trace the state attributes LASTSEQ and LASTSTEP with the SFC trace. The values should match the design history.
6. Operator acceptance test: have an operator perform a "Strategy change" from the faceplate, then verify that the SFC instance follows the expected round-trip and returns to the original strategy.
7. Fault injection: force a CPU STOP→RUN with a pending target and confirm the recovery path (see initialization action above).
8. Audit verification: open the PCS 7 audit log and confirm that the strategy changes are recorded with operator name, timestamp, and source (manual vs. automatic).

Troubleshooting Matrix

Related SFC Concepts for Context

The SFC building blocks defined in IEC 61131-3 are: step, transition, action, alternative branch, simultaneous branch with convergence, and sequence. The round-trip jump pattern is built on top of these primitives—it does not introduce a new construct, it simply reuses the target-step mechanism defined for normal sequencer restart. A clear independent primer on the difference between alternative branching and simultaneous branching with convergence is the Omron SFC Introduction Guide (PDF); the same structural rules apply to the Siemens editor, and the convergence concept in particular is what limits where you can place TARGETSEQ writes.

For deeper context on the Siemens SFC state machine (active, held, held-by-error, completing, aborted, idle), consult the SFC Visual Basic API documentation included in the PCS 7 installation under "SFC Documentation" → "SFC API". The API is also the only reliable way to interrogate the runtime attributes from a CFC chart, because direct instance-DB reads can race with the SFC scan.

FAQ