UT_INTERLOCK — Interlock / permissive list with first-out and bypass

Collects all the conditions that must be healthy before a device may run (guards,
pull cords, levels, pressures, upstream running…) into one Ok signal for the
device's Interlock or Permissive pin. It records which condition tripped first
(first-out) and allows controlled maintenance bypasses.

Pins

Condition slot UT_INTLK_COND

Record UT_INTLK_DATA

How it works

• Ok is FALSE while any condition is tripped and not bypassed, and always with no
  conditions at all (an empty array: a config fault, configBad).
• Delay. A condition counts once it has been not OK for its delay, timed from
  the scan it was first seen. A loss shorter than that, or a chattering input, never counts.
• Reset. Reset or cmdReset, each on its rising edge, clears the first-out and
  releases MANUAL conditions that are healthy again. A condition that is still not
  OK stays out: the reset is refused, not remembered. A reset held on (a stuck
  button, a Modbus coil left on, a debugger force) acts once: a pull cord pulled again
  stays out until a new reset.
• First-out is the first condition to stop it since the last reset. Several at
  once: the lowest position. After a reset with conditions still out: the lowest of
  those. It counts positions from 1, whatever the array's lower bound, so declare the
  array from 1 and FirstOut is the index.
• Bypass. bypass takes effect only while BypassEnable is TRUE. It drops out
  after bypassTimeout, and stays out until the request or BypassEnable goes FALSE
  and back. Bypassed shows any bypass in effect, even on a healthy condition. A
  MANUAL condition still latches while bypassed; reset it before removing the bypass.
• Every condition keeps its own timing in its element, so the array can be any length
  and the block has no fixed limit.

Status codes

statusCode / faultId / statusText say why Ok is FALSE, or what to watch while
it is TRUE, and statusCond says which condition. The most important wins: config >
blocked > bypassed or a bad setting > OK. It names the lowest condition holding Ok
FALSE now (not the first-out, which stays until a reset), by its position from 1.
Name the conditions on the HMI, by position. statusText changes only when the code
or faultId changes.

Using it

|--[ GuardClosed ]----------------( Crusher[1].ok )--|
|--[ PullCordHealthy ]------------( Crusher[2].ok )--|
|--[ Conveyor2.Running ]----------( Crusher[3].ok )--|

CrusherIntlk(BypassEnable := MaintKey, Reset := ResetPB, Conditions := Crusher, Data := CrusherIntlkData);
Crusher1(AutoCmd := StartChain.Step3, Interlock := CrusherIntlk.Ok, Data := Crusher1Motor);

Bad settings

Invalid settings warn (configBad) and fall back to the safe side: a negative
bypassTimeout allows no bypass at all; a negative condition delay acts at once (as 0);
an unknown reset holds the condition until a reset (as MANUAL).