SFC Editor (GRAFCET)

The SFC Editor (Sequential Function Chart) provides a graphical view of the step-and-transition sequence within a process, following the IEC 61131-3 GRAFCET standard. It visualizes how steps connect through conditions, making complex process flows easy to understand and edit.

Access: Open a module → Module Ribbon → Conditions panel → SFC button.

🔎 Overview

The SFC Editor renders the entire process as a directed graph where:

• Steps (phases) are shown as rectangular nodes

• Transitions (conditions) are shown as labeled edges connecting steps

• The graph supports parallel fork, parallel merge, and jump patterns for complex branching logic

The editor is built on the GraphX library and uses orthogonal edge routing for clean, readable layouts.

🧩 Graph Elements

📦 Step Nodes (Vertices)

Each node in the graph represents one of four vertex kinds:

Info: Only Step (process phase) vertices can be edge targets when dragging new connections. Fork and merge vertices are managed automatically by the system.

🔀 Edges (Transitions)

Edges represent transitions between steps. Each edge carries a condition text describing when the transition fires. There are 10 edge visual kinds that determine how the edge is displayed and what actions are available:

Simple Transitions

Parallel Fork Edges

Parallel Merge Edges

Jump Edges

🎯 Condition Types

Each condition in the algorithm has a type based on the IEC 61131-3 standard. The SFC Editor displays these using distinct visual tokens and colors (configurable via Algorithm Colours in the Module Ribbon):

Tip: You can customize the colors for each condition type using the Algorithm Colours button in the Conditions panel of the Module Ribbon.

🏭 Pharma Example: CIP Sequence as a GRAFCET

This example shows a complete Clean-In-Place (CIP) sequence modeled as a Sequential Function Chart. CIP is one of the most common automated processes in pharmaceutical manufacturing.

📋 Steps (Process Phases)

🔀 Transitions (Step-to-Step Conditions)

▶️ Continuous Actions (Run While Step Is Active)

⚡ Actions on Activation (Execute Once When Step Starts)

🔄 Conditional Continuous Actions

Note: This CIP example demonstrates all the major GRAFCET condition types working together. The sequence is linear (no parallel forks), but in practice you might add parallel branches for simultaneous tank draining and line blowing.

⚙️ Graph Building Pipeline

When you open the SFC Editor or switch processes, the graph is built through these stages:

1. Load Domain Data — The adapter queries all steps, conditions, and transitions from the active process

2. Create Step Vertices — One vertex per step, positioned using saved coordinates (or auto-layout if new)

3. Create Transition Edges — Each condition's success/failure targets become directed edges

4. Detect Parallel Forks — When a single condition has multiple target steps, a Parallel Fork vertex is inserted

5. Detect Parallel Merges — When multiple conditions from different sources share the same target, a Parallel Merge vertex is created. The system checks whether all incoming condition texts match (unified vs. mixed)

6. Create Jump Pairs — For conditions marked with teleport endpoints, entry/exit node pairs are created with matching display IDs

7. Route Edges — The orthogonal edge routing algorithm computes clean right-angle paths for all connections

8. Place Labels — Edge labels are positioned on vertical segments using a reservation system to avoid overlaps

🔱 Parallel Fork Branching

A parallel fork occurs when a single condition leads to multiple target steps that activate simultaneously. For example, a condition might transition to Step 3 on success and Step 5 on failure, while also having additional fork targets.

How it works:

• The condition becomes a Parallel Fork diamond vertex

• The original edge (Step → diamond) carries the condition label

• Each target step gets a child edge (diamond → Step) without labels

• You can add more fork targets by using the Fork action on any edge

Edge creation modes:

• New Success Transition — Create a brand new transition to a target step

• Duplicate Transition — Clone an existing transition's condition text to a new target

• Fork Transition — Add a new branch from an existing parallel fork condition

🔗 Parallel Merge

A parallel merge occurs when multiple transitions from different source steps converge on the same target step. The SFC Editor automatically detects this pattern.

Detection logic:

• The system groups all incoming edges by their target step

• If a target step has incoming edges from 2+ different source steps, a Parallel Merge vertex is created

• If all incoming conditions share the same text → Unified display (single shared label)

• If conditions differ → Mixed display (individual labels per incoming edge)

🚀 Jump Nodes

Jumps are visual shortcuts for connecting distant parts of the graph without cluttering the layout with long edges.

Structure:

• Each jump consists of a pair of vertices

• The entry node is placed near the source step

• The exit node is placed near the target step

• Both nodes share a pair key and display a matching ID for visual identification

When to use jumps:

• When the source and target steps are far apart in the graph

• To reduce visual clutter from long crossing edges

• To keep the graph readable when many transitions span large distances

📐 Edge Routing

The SFC Editor uses an orthogonal edge routing algorithm that produces clean, right-angle paths:

🔧 Routing Strategy

1. Naive Route Computation — Each edge gets an initial orthogonal path based on source/target positions

2. Connection Points — Routes connect to specific anchor points on vertices (top, bottom, or indexed connection points for forks)

3. Special Routing for Forks — Parallel Fork vertices use left/right fanning for child edges; Parallel Merge vertices use controlled approach angles

4. Label Placement — Labels are placed on vertical segments of the route, with a reservation system that prevents overlaps. The algorithm tries three strategies in order:

   • Place on the first vertical segment below the source (if single outgoing)

   • Place on the last vertical segment above the target (if single incoming)

   • Fall back to an intermediate vertical segment

5. Hidden Loops — When the desired label distance doesn't match the natural route midpoint, small forward/backward loops are inserted at the start or end of the route to shift the label position

📏 Layout Constants

⚠️ Dangling Conditions

Some conditions may not have any transition targets assigned yet. These are called dangling conditions and are displayed as a list on their parent step vertex. This helps you identify incomplete step configurations that still need transitions.

📤 Exporting to Visio

The SFC graph can be exported to Microsoft Visio format for external documentation. See Export Dialogs to Visio for details on the GRAFCET Visio export, which maps each graph element to Visio shapes with metadata cells.

Exported elements include:

• Steps (initial and regular) with index, name, and description

• Conditions with their types and texts

• Fork and merge junctions

• Jump nodes with display IDs

• Edge labels with transition details

• Nested action elements (timed actions, conditional actions, etc.)

📋 How To: Build an SFC for a CIP Process

Follow this step-by-step workflow to create a Sequential Function Chart for a CIP (Clean-In-Place) process in AseptSoft.

Step 1 — Open the SFC Editor
Navigate to the Module Ribbon → Conditions panel → SFC button.

Step 2 — Ensure the process and steps exist
Before building the SFC, make sure the Process has been created with all required steps (e.g., Idle, Pre-Rinse, Caustic Wash, Intermediate Rinse, Acid Wash, Final Rinse, Drain). Steps are created in the Process Design area.

Step 3 — Arrange the step nodes
When the SFC Editor opens, all steps appear as rectangular nodes. Drag them into a logical top-to-bottom flow representing the CIP sequence. Place Idle at the top and Drain at the bottom.

Step 4 — Create transition conditions
Drag from one step node to the next to create a transition. In the condition editor that appears, enter the transition logic:

• Idle → Pre-Rinse: "CIP start command received"

• Pre-Rinse → Caustic Wash: "Pre-rinse timer elapsed (5 min)"

• Caustic Wash → Intermediate Rinse: "Caustic hold time complete at target temperature"

• And so on for each step transition.

Step 5 — Add continuous actions
For each step that needs ongoing behavior (e.g., keeping pumps running, monitoring sensors), add Continuous action conditions. These run every scan cycle while the step is active.

Step 6 — Add activation/deactivation actions
For one-shot tasks like logging the CIP start time or recording a batch ID, add Execute on activation conditions to the relevant steps. For cleanup tasks, add Execute on deactivation conditions.

Step 7 — Configure conditional continuous actions
For actions that only run under certain conditions within a step (e.g., boost heater when temperature drops), add Conditional continuous action entries with the appropriate guard condition.

Step 8 — Add the return-to-idle loop
Create a transition from the Drain step back to Idle, forming a complete cycle. If the graph becomes cluttered, use a Jump to connect the bottom of the chart back to the top cleanly.

Step 9 — Validate the chart
Check for dangling conditions (conditions without targets) shown on step nodes. Ensure every step has at least one outgoing transition. Review the complete flow matches your CIP recipe specification.

Step 10 — Test with the algorithm
Use the Algorithm Design tools to verify the SFC executes correctly — step through each phase and confirm transitions fire at the right conditions.

Tip: Use the CIP example above as a template. Most CIP processes follow a linear sequence; add parallel forks only when truly needed (e.g., simultaneous tank drain and line blowing).

🖱️ Keyboard and Mouse Interactions

Note: Vertex positions are saved per-process and restored when you reopen the editor.

📚 Related Pages

• Module Ribbon — Access the SFC Editor from the Conditions panel

• Algorithm Design — Conditions and algorithm editing

• Process Design — Process and step management

• Algorithm Attributes — Attribute configuration for conditions

• Export Dialogs to Visio — GRAFCET Visio export details

• Valve Phase Matrix — Complementary matrix view of valve states across phases

• Symbol Editor — Symbol definition editor

• Engineering Item — Engineering item data model

• State — State definitions and custom values