UT_MOTOR_CORE — What every motor block shares

The record, run request, interlock and permissive, every protection, the restart
rules, state, fault codes and status of the motor blocks. UT_MOTOR is this core
and one contactor; the reversing, star-delta, two-speed and VSD blocks are this
core and their own output sequence. Use it directly only to build a new kind of
motor block.

The core is two functions, not a function block:

• UT_MOTOR_RESET: the reset request of this scan. Call it first.
• UT_MOTOR_CORE: everything else.

A function keeps no instance of its own, so the motor record is never copied. The
motor block keeps the core's working state in one UT_MOTOR_ST and passes it, with
the record, to both functions every scan. The motor block also runs its own
UT_MODE_SELECT and passes the mode in.

Pins

UT_MOTOR_RESET

UT_MOTOR_CORE

The core's results are in St after the call, for the variant to read:

The other fields of UT_MOTOR_ST are the core's own memory: leave them alone, and
don't show them on an HMI.

Status

The core works out statusCode, faultId and statusText for every motor block
(statuses). The variant only says what its sequence is doing
through VarStatus (with VarTime), names a bad setting through CfgId, and hands
its own protections over as one summary through the Ext… pins. The core ranks the
variant's status with its own: a normal status shows while the motor runs; a
waiting status shows while it is asked to run; "drive not ready" shows whenever it is
stopped. A StartBlock with no status shows UT_ST_START_BLOCKED, so a start held
back by a variant is never unexplained. A variant works out its status before
calling the core, from its last scan, so its sequence states show one scan late.
The core also reads and clears cmdStart and cmdStop (each on its rising edge; a
stop read TRUE blocks every start), keeps stopReason, the last trip and trips,
the Hand run limit, and sets timeLeft to the time the status shows.

CfgId, ExtCfgId and the core's own settings name the setting with a UT_FAULT
member: the core's are UT_F_FLC, UT_F_CURRENT_NEEDS_FLC, UT_F_START_MASK,
UT_F_RESTART_DELAY, UT_F_HAND_MAX_RUN, or a protection's name (UT_F_OVERLOAD
… UT_F_DRIVE) for its delay, recover or maxRetries. The variants' are
UT_F_REVERSAL_DELAY, UT_F_TRANSITION_TIME, UT_F_STAR_CURRENT,
UT_F_STAR_NEEDS_FLC, UT_F_STAR_TIME, UT_F_SPEED_CHANGE, UT_F_LOW_START_TIME,
UT_F_MIN_MAX_SPEED, UT_F_RAW_MIN_MAX, UT_F_ACCEL_RATE, UT_F_SKIP_BAND,
UT_F_HAND_SPEED, UT_F_RESET_PULSE, UT_F_RATE_UNIT, UT_F_RATED_HZ_RPM, and
UT_F_SPEED_DEV, UT_F_CHANGEOVER or UT_F_DRIVE_NOT_READY for their own
protections. The full list is in conventions.

Using it

The pattern every motor block follows (here a block with one contactor):

modeSel(Source := Data.modeSource, SwHand := SwHand, SwAuto := SwAuto,
        PowerUp := Data.powerUp, CmdMode := Data.cmdMode);
x1 := UT_MOTOR_RESET(Reset := Reset, EnteredOff := modeSel.EnteredOff, Data := Data, St := cs);
(* the variant's own protections here, with UT_PROT_RUN and ResetReq := cs.resetReq *)
x2 := UT_MOTOR_CORE(Mode := modeSel.Mode, ModeChanged := modeSel.Changed, AutoCmd := AutoCmd,
                    Feedback := Feedback, Overload := Overload, Interlock := Interlock,
                    Permissive := Permissive, Data := Data, St := cs);
Run := cs.runReq;