AutomationView sequences are plain Python files. Any AI coding assistant — Claude Code, GitHub Copilot, Cursor, or a local LLM — can read, write, and reason about .seq and .machine files directly without plugins or special integrations.
AutomationView stores sequences as Python classes. This makes them naturally readable by AI tools, which can:
No export, no conversion. The AI edits the same files that AutomationView loads.
The most effective way to work with AI is to add a CLAUDE.md file at the root of your AutomationView project. This file acts as a persistent briefing — the AI reads it at the start of every session and understands your project without you having to re-explain the API.
Tip:
CLAUDE.mdis the native briefing format for Claude Code. Other AI tools can read it too — rename itAI.mdorAGENTS.mdif your tool requires a different filename.
Copy this file into the root of your AutomationView project and adjust the project-specific sections:
# AutomationView Project
This is an AutomationView automation project. Programs are written as Python
classes using the `automation_machine` library. Files use `.seq` (sequences)
and `.machine` (project configuration) extensions — both are valid Python
loaded by a custom import hook.
Variables are inferred automatically. There is no IO class. The VariableExtractor
detects all variables from action names, transition conditions, and operands.
You only write .seq and .machine files.
## Project Structure
project/
main.machine # Project configuration (one per project)
SequenceName.seq # One sequence class per file
## File Types
| Extension | Purpose | Base Class |
|------------|----------------|------------|
| `.seq` | Sequence logic | `Sequence` |
| `.machine` | Project config | `Machine` |
## Imports
Only import what you use:
# In .seq files
from automation_machine import Sequence, StepType
from automation_machine import ActionQualifier # non-default qualifiers only
from automation_machine import ActionInstruction # timers, counters, instructions
from automation_machine import ActionOperand # arithmetic/comparison operands
# In .machine files — only this import, never import sequence classes
from automation_machine import Machine
## Creating Steps
Step variables use self.s0, self.s1, self.s2, etc. The name parameter is
the step's display label.
# Initial step (exactly one per sequence)
self.s0 = self.add_step(StepType.INITIAL, name="0", comment="Home position")
# Normal step (StepType.NORMAL is default — omit it)
self.s1 = self.add_step(name="1", comment="Extend cylinder")
## add_action() Full Signature
step.add_action(
name, # Variable name (positional, required)
description="",
qualifier=ActionQualifier.N, # Omit for default N qualifier
instruction=None, # ActionInstruction enum or plain string for plugins
duration=None, # ms — for timed qualifiers and timer instructions
operands=None, # List[ActionOperand]
condition=None,
code=None,
preset_value=None, # for counter instructions
parameters=None, # Dict[str, Any] for plugin-contributed actions
comment=None,
)
Common patterns:
# N action (default — most common, omit qualifier)
self.s1.add_action("verin_avance", description="Cylinder advance")
# Timer action
self.s3.add_action("T_Confirm", instruction=ActionInstruction.TON, duration=500,
description="Position confirmation timer")
# S/R for non-physical operations
self.s2.add_action("aspiration", qualifier=ActionQualifier.S)
self.s6.add_action("aspiration", qualifier=ActionQualifier.R)
# ActionOperand — variable reference vs literal
ActionOperand("sensor_value")
ActionOperand("100", is_literal=True)
## Creating Transitions
Condition syntax: . (AND), + (OR), / (NOT)
# Basic condition
self.add_transition(self.s0, self.s1, "start . /emergency_stop", comment="Start cycle")
# Dual-sensor check (always check opposite sensor)
self.add_transition(self.s1, self.s2, "verin_avant . /verin_arriere")
# Timer output — .q suffix
self.add_transition(self.s3, self.s4, "T_Confirm.q")
# Cross-sequence reference: SequenceName.XStepName
self.add_transition(self.s5, self.s6, "Convoyeur.X3")
# Parallel divergence (AND branch — one source, multiple targets)
self.add_transition(self.s0, [self.s1, self.s2], "start")
# Parallel convergence (AND join — multiple sources, one target)
self.add_transition([self.s3, self.s4], self.s5, "True")
## Transition Actions
Store the transition to add actions. Used for counters and pulse signals.
# Counter on transition (P = single pulse per firing)
self.t_count = self.add_transition(self.s4, self.s0, "/part_present . /counter1.q")
self.t_count.add_action("counter1", qualifier=ActionQualifier.P,
instruction=ActionInstruction.CTU, preset_value=3)
# Reset on another transition
self.t_reset = self.add_transition(self.s4, self.s5, "/part_present . counter1.q")
self.t_reset.add_action("counter1", qualifier=ActionQualifier.R)
## Cross-Sequence References
SequenceName.XStepName
- SequenceName = the self.name value of the target sequence
- XStepName = X prefix + the step's name parameter value
- Prefix with / for NOT: /Convoyeur.X3
## Dynamic Variables
Parameterized sequences use {var} patterns. Resolved by add_instance() using
the instance name as prefix.
class Verin(Sequence):
def setup(self):
self.name = "Verin"
self.s0 = self.add_step(StepType.INITIAL, name="0")
self.s1 = self.add_step(name="1")
self.s1.add_action("{move_forward}")
self.s1.add_action("{T_Forward}", instruction=ActionInstruction.TON, duration=2000)
self.add_transition(self.s0, self.s1, "{forward_cmd}")
self.add_transition(self.s1, self.s2, "{T_Forward}.q")
self.add_transition(self.s2, self.s0, "/{forward_cmd}")
## Machine File (.machine)
Only import Machine — sequence classes are resolved automatically by the runtime.
from automation_machine import Machine
class ProjectMachine(Machine):
def __init__(self):
super().__init__()
self.name = "Project Name"
self.version = "1.0.0"
self.description = ""
self.author = ""
self.metadata = {"standard": "IEC 61131-3"}
def setup(self):
# add_instance takes STRING class names — not class references
self.add_instance("Verin", "magasin_1")
self.add_instance("Verin", "magasin_2")
## Action Qualifiers
| Qualifier | Behavior |
|-----------|-----------------------------------------------------------------|
| N | DEFAULT — active while step active, omit the argument |
| S | Latch ON until Reset — non-physical operations only |
| R | Reset a previously Set action |
| P | Single-cycle pulse — use on transition actions for counters |
| D | Activates after delay (ms) while step remains active |
| L | Active for duration (ms) then stops |
| SD | Stored Delayed — activates after delay, stays even if step off |
| DS | Delayed Stored — delay counted while active, then stored |
| SL | Stored Limited — stored, auto-resets after duration |
## Action Instructions
Timers (require duration in ms):
TON — On-Delay TOF — Off-Delay TP — Pulse RTO — Retentive
Counters (require preset_value):
CTU — Count Up CTD — Count Down CTUR — CTU with Reset CTDR — CTD with Reset
Boolean / Bistable (no extra arguments):
SR — Set-dominant RS — Reset-dominant R_TRIG — Rising edge F_TRIG — Falling edge
Arithmetic (require operands):
ADD SUB MUL DIV MOVE
Comparison (require operands, result boolean):
GT GE LT LE EQ NE
Plugin instructions: pass as plain string — instruction="PLUGIN_NAME"
## Best Practices
N qualifier is the default — omit qualifier argument for physical actuators.
An N action on a variable must belong to ONE sequence only.
Dual-sensor rule — always check both sensors:
self.add_transition(s1, s2, "verin_avant . /verin_arriere")
self.add_transition(s5, s6, "verin_arriere . /verin_avant")
Timer confirmation — use TON on the step, transition checks .q:
self.s3.add_action("T_Confirm", instruction=ActionInstruction.TON, duration=500)
self.add_transition(self.s3, self.s4, "T_Confirm.q")
Typical durations: 300-500ms (position), 50-100ms (debounce), 1000-2000ms (safety)
Sync steps — for cross-sequence coordination, NO physical actions on sync steps.
Every sync step must have a matching desync step.
## Rules Checklist
- Every physical actuator uses N qualifier (omit argument)
- S/R only for non-physical, non-dangerous operations
- P qualifier on transition actions for counters and one-shot signals
- Every dual-sensor transition checks both: sensor . /opposite
- Timer instructions use TON (or TOF/TP/RTO) with duration
- Timer transitions use .q suffix
- Counter instructions use CTU/CTD with preset_value
- Cross-sequence references use SequenceName.XStepName format
- Sync steps have no physical actions
- Every sync has a matching desync
- Step variables are self.s0, self.s1, etc.
- Exactly one StepType.INITIAL per sequence
- Emergency stop in the start transition condition
- Only import what is actually used
- .machine files only import Machine — no sequence class imports
- add_instance uses string class names, not class references
Note: Variables are inferred automatically from action names, transition conditions, and operands. You never declare an IO list — just use descriptive variable names and the Variable Management system detects them.
Describe the machine in plain language and ask the AI to produce the .seq file:
"Write a sequence for a pneumatic press. The press has two sensors (top and bottom position) and one output (press_down). The cycle starts on start_button, descends, holds for 2 seconds, then returns to top position."
The AI will generate a complete .seq file with proper timer confirmation, dual-sensor transitions, and IEC 61131-3-compliant structure.
"I have 4 identical conveyor belts. Create a dynamic Verin sequence and a machine file that instantiates 4 copies named conv_1 through conv_4."
"Review this sequence for safety issues, missing timer confirmations, and any cases where two sequences might write the same output."
"Add an emergency stop monitoring step to this sequence that sets a memory flag and waits for a manual reset before returning to the initial step."
| Goal | Tip |
|---|---|
| Accurate IO naming | Mention your naming convention upfront (e.g., "inputs are prefixed i_, outputs o_") |
| Consistent style | Ask the AI to follow the patterns already in your project files |
| Complex machines | Describe one sequence at a time, then ask for the machine file to coordinate them |
| Cross-sequence sync | Explicitly state which steps synchronize between sequences |
| Review | Share the file contents and ask "Does this follow the rules in CLAUDE.md?" |