UT_SEQUENCER — Start/stop chain (conveyors, crushing, process trains)

Starts a chain of machines in order, each waiting for the previous one to prove
it's running, and stops them in reverse order. If a running machine drops out,
everything after it in the start order stops at once (cascade stop), so
material doesn't pile up. There's any number of steps: you declare the array.

Pins

Positions (CurrentStep, faultStep, configStep) count from 1 = the first
element, whatever the array's lower bound.

Step slot UT_SEQ_STEP

Ladder, one rung each:

|--[ Conveyor2.Running ]-------------( Steps[2].feedback )--|
|--[ Conveyor2.Ready ]---------------( Steps[2].ready )-----|
|--[ Steps[2].cmd ]-----------------( Conveyor2_AutoCmd )--|

Record UT_SEQ_DATA

How it works

• Start: step 1's cmd goes on; once its feedback proves, startDelay passes, then
  step 2, and so on. Bypassed steps are passed over. A start while stopping (or
  from part running) starts again from step 1: machines still running stay on and
  pass straight through.
• Stop: the steps stop one at a time in stopMode order, each waiting for its
  feedback to go, then its stopDelay. A step whose feedback won't go (welded
  contactor) holds the stop there and raises did not stop after its timeout, since
  its machine is still running and the ones it feeds must keep going. Abort is the
  way out.
• Loss / start timeout: per onLoss, see the table above. The fault stays until a
  Start edge, a Stop edge, Reset or cmdReset (a did not stop comes back while
  the machine still runs).
• Hold pauses a start: no further step is started and the current step's timers
  stop. Losses and stops still act.
• Abort (level) drops every cmd at once; the mode shows ABORTED until the next
  Start, Stop or Reset. It never restarts by itself.
• Auto restart: after a fault stop, with Start held TRUE and every non-bypassed step ready, Restarting
  comes on for restartDelay and the chain starts from step 1. A step going not ready,
  Start dropping or Hold cancels the countdown. A Stop edge or Abort cancels the
  run request, so a stopped or aborted chain never restarts by itself.
• Power cut: nothing is kept. The chain comes back idle with every cmd off (even
  if you declared the steps RETAIN) and needs a new Start edge — also with auto restart
  on and Start held.
• Start and Stop in the same scan: the stop wins. Commands held on act once.

Using it

VAR  Chain : ARRAY[1..4] OF UT_SEQ_STEP;  ChainData : UT_SEQ_DATA;  END_VAR

Chain[1].feedback := Conveyor3.Running;  Chain[1].ready := Conveyor3.Ready;
Chain[2].feedback := Conveyor2.Running;  Chain[2].ready := Conveyor2.Ready;
Chain[3].feedback := Jaw.Running;        Chain[3].ready := Jaw.Ready;
Chain[4].feedback := Feeder.Running;     Chain[4].ready := Feeder.Ready;
Plant(Start := RunSwitch, Stop := NOT RunSwitch, Abort := NOT EStopOk,
      Steps := Chain, Data := ChainData);
Conveyor3(AutoCmd := Chain[1].cmd, ...);   (* and so on *)
Siren := Plant.Restarting;

Status codes

statusCode is a UT_STATUS and faultId a UT_FAULT (an HMI reads their numbers);
statusText is the two in words, changed only when one of them changes. The one main
thing, in the order config, fault, held, normal, off. The step is in CurrentStep
(starting, stopping, held), faultStep (a fault) or configStep (a bad setting), the
countdown in timeLeft, and each step's state in Steps[n].state. Name the steps on
the HMI, by position.

Bad settings

A negative startDelay, stopDelay, timeout or restartDelay, or an unknown
stopMode / onLoss, is a config fault (fltConfig, Config: step setting with the
step in configStep, or Config: chain setting) while it lasts: no start and no auto restart. A chain already running
carries on (a negative time acts as 0, an unknown stopMode as REVERSE, onLoss as
CASCADE) and stops normally.