Ignition Gateway Scripts Keep FSM State by Writing It to a Tag

A finite state machine (FSM) instantiated in an Ignition script module lives in exactly one process. It is not a shared object. The working design for a gateway timer script (300 ms period, about 1000 tag reads and 100 tag writes per scan) is to rebuild the transition tables on every run and keep only the current state in a gateway memory tag. That removes any dependence on how long the interpreter keeps a module-level object alive.

Which process holds the FSM instance?

Trace where the object is created and who can reach it. A top-level Python object in a script module is created separately in each runtime that loads the project. No memory is shared between these runtimes, and there is no network path for an object reference between them.

The consequence: fsm1 created in a client script is a different object from fsm1 created in a gateway script, even if both call project.fsm.FiniteStateMachine(). No script location makes one instance visible to all gateway and client scripts. A state value visible everywhere has to travel through a shared medium: a database, a file, or a gateway memory tag that each scope reads on demand.

Must clients see the FSM, or only the gateway?

This decision splits the design in two.

• Clients must read or drive the state: Treat the gateway as the single owner. Store the state in a memory tag (or database row) and let clients read it as a normal tag binding. Route operator input to the gateway with a message script or a tag write, and let the gateway FSM evaluate it. Message scripts and tag change scripts can mimic synchronization between scopes, but they do not guarantee it. Two scopes that each run their own FSM copy can diverge.
• Only gateway scripts need the FSM: Keep the FSM entirely in gateway scope. This is the case for a PLC simulator driven by a gateway timer script. Go to the next check.

If the honest answer is "clients need a live copy of the same object," the requirement cannot be met with script objects. Move the state to a tag.

What resets a module-level object inside the gateway scope?

Objects instantiated at the top level of a script module persist in their scope until a Designer saves or publishes the containing project, or any Designer saves a global change such as a shared script. At that point the scripting modules reload and module-level objects are re-created from their initializers. Observed behavior on a gateway timer script matches this: some script variables keep their values between runs. That is a side effect of the module staying loaded, not a contract.

Any of the first three rows can occur mid-sequence during a commissioning session, so a design that depends on the object surviving will lose state at an arbitrary scan.

Does the posted FSM code run correctly as written?

The logic works. The posted trace shows trig3 firing the registered f1To3 transition from s1 to s3 (state 2), then trig1 moving row 2, column 0 to state 1. Output 2 then 1 matches the table [[0,0,2],[0,2,0],[1,1,2]]. Four defects still need fixing before it goes into a timer script:

Note also that the transition function runs only when the new state differs from the current one (if newState != self.state). Self-transitions never call their function. If a state must execute an action on re-entry, remove that condition.

Does a 300 ms scan tolerate rebuilding the tables every run?

Yes. The gateway script reads about 1000 tags and writes about 100 per cycle and typically finishes in under 6 ms. The tag I/O dominates. Building three 3x3 lists and two dictionaries adds negligible time next to that.

Rebuild-per-scan removes the persistence question for the tables, which are constants. The single mutable datum is the current state integer. Persist that and the FSM is reconstructible at any scan.

Is a script FSM the right tool, or does SFC fit better?

Use these checks to decide:

1. Is the sequence a step-and-transition process with operator confirmations and step timing? The SFC module implements that natively, with persisted chart state managed by the platform, and is the better fit than a hand-built transition matrix.
2. Is the FSM a small simulation of PLC behavior tied to a fixed timer scan? Keep it as a gateway script with the state in a tag.
3. Do you need PLC-style communication from the gateway itself? A separate Ethernet/IP module exists for gateway-side PLC-style work; evaluate it against your licensing and version before committing.

Reserve script FSMs for logic that is easy to restate and where losing the object costs nothing. If the scripting approach requires client visibility or multi-scope coordination, it is doing too much in scripting.

How do you restructure the gateway timer script so only the state persists?

1. Create a memory tag to hold the FSM state integer. The path below is a placeholder: [default]FSM/State. Initialize it to the state you want after a cold start.
2. Rewrite the class so containers are created per instance and the state can be injected:

   class FiniteStateMachine(object):
       def __init__(self, initialState=0):
           self.triggers = {}
           self.states = {}
           self.stateXition = []
           self.stateXitionFunction = []
           self.state = initialState
   
       def newState(self, triggerEvent):
           trig = self.triggers[triggerEvent]
           nxt = self.stateXition[self.state][trig]
           if nxt != self.state:
               func = self.stateXitionFunction[self.state][trig]
               if func is not None:
                   func()
               self.state = nxt
           return self.state

3. In the timer script, read the state tag first, build the FSM, apply the scan's trigger events, then write the state back only if it changed:

   In Ignition versions that predate system.tag.readBlocking and system.tag.writeBlocking, use the older system.tag.read and system.tag.write calls with the same logic.

4. Register transition functions inside scan (or a helper it calls) on every run, since the object is rebuilt each time.
5. Source the events list from tag reads already performed in the scan or from operator-input tags. Clear one-shot operator triggers after they are consumed so a trigger is not applied twice on consecutive scans.

How do you confirm the state survives a save and a rebuild?

1. Run the timer script and drive the FSM to a non-initial state, for example send trig3 from s1. Confirm [default]FSM/State reads 2.
2. Save the project from the Designer, which forces the script modules to reload. Confirm the tag still reads 2 and that the next scan resumes from state 2, not from the initializer.
3. Send trig1 and confirm the tag moves to 1, matching row 2, column 0 of the transition table.
4. Watch the script run time in the gateway diagnostics or a logged timestamp delta across a full 1000-read, 100-write cycle. Confirm it stays well inside 300 ms (about 6 ms typical).
5. Repeat step 2 while a client window shows the state tag, and confirm the client displays the tag value with no script involvement.

FAQ