Control Module: vfd

A variable-frequency drive with a recipe-commandable run/speed and a hardware-fast fault interlock. This template is pump-agnostic. Use it for any VFD-controlled load (pump, fan, agitator, mixer, compressor). Operator or recipe logic writes the RUN_CMD (run/stop) and SPEED_SP (speed setpoint) tags. Each is backed by a constant block, exactly like solenoid-valve and analog-control back their writable CMD. The template AND-gates the run command with the inverted fault signal, so the drive is disabled in the same scan cycle on any fault. When running, the speed setpoint is clamped to max_speed. When stopped or faulted, the speed output is forced to zero.

Where to find it

System endpoint → Equipment Library → Control Modules tab → select vfd.

FBDST

What you see on the faceplate

Element	Meaning
RUN_CMD	Run/stop command (read-write — operator or recipe)
SPEED_SP	Speed setpoint, 0–max_speed (read-write — operator or recipe)
FAULT	VFD fault input state (read-only)
RUN	Interlocked run enable delivered to the drive (read-only)
SPEED	Effective speed output delivered to the drive, 0–max_speed (read-only)

The RUN tag already reflects the fault interlock. If FAULT = true, RUN is forced false and SPEED is zero regardless of what RUN_CMD or SPEED_SP are doing.

Tags

The template declares deviceClass: actuator and a role on each tag (ADR 0016). The HMI renders from these declarations and never infers meaning from moduleType or tag names. The RUN tag's role: state makes it the unit card's prominent status word (rendered with the CM-level true_label/false_label, Running/Stopped). SPEED_SP (role: setpoint) fills the HMI setpoint bar and SPEED (role: feedback) the feedback bar.

Tag	Type	Access	Role	Description
RUN_CMD	Boolean	read-write	command	Run command. Operator or recipe ST writes TRUE/FALSE; backed by a BOOL_CONST block.
SPEED_SP	Float	read-write	setpoint	Speed setpoint (0–max_speed). Operator or recipe ST writes the value; backed by a REAL_CONST block.
FAULT	Boolean	read	alarm	VFD fault status (from fault input). Exposed so an AlarmDefinition can wrap it with severity and exception action.
RUN	Boolean	read	state	Interlocked run enable written to run_out. true only when RUN_CMD = true AND FAULT = false. Shown as the card's prominent status word.
SPEED	Float	read	feedback	Effective speed written to speed_out. Equals clamped(SPEED_SP, max_speed) while running, zero otherwise.
ILCK	Boolean	read	interlock	true while the device interlock is forcing the output to its safe state. Reserve a TagTrue AlarmDefinition for interlocks whose trip is abnormal in itself (why). The historian records every trip either way.

Parameters

Parameter	Default	What it does
max_speed	100.0	Upper clamp on the speed setpoint, same units as SPEED_SP
eng_units	(blank)	Display units for SPEED / SPEED_SP (e.g. %, Hz, RPM)
true_label	Running	Faceplate label when the drive is active (shown for the RUN state tag; RUN_CMD carries its own per-tag Run/Stop labels)
false_label	Stopped	Faceplate label when the drive is off
interlockAddress	(empty — interlock disabled)	Device address of a boolean trip signal, read by the output block every scan; while tripped (or unreadable — fail-safe) the output is forced to the safe value.
interlockInvert	false	Trip while the signal is false (with the invert off, true trips).
safeValue	(empty)	Output value forced while interlocked. Applies to the speed output; empty means the output range minimum. The run command always drops to stopped while tripped.

Setting interlockAddress on an instance enables the device interlock. See Alarms and Interlocks → Pattern 0.

The former state_tag parameter is replaced by the RUN tag's role: state designation. The card reads Running/Stopped, the live interlocked state. The RUN_CMD verbs Run/Stop belong to the command alone.

Scan interval is fixed at 100 ms. The fault interlock is the driving constraint: slow scan rates defeat the same-cycle guarantee.

How it works

Each scan cycle, the runtime:

1. Takes the latest RUN_CMD (Boolean) written by operator/recipe.
2. Reads fault (Boolean) → FAULT tag.
3. Computes RUN = RUN_CMD AND NOT FAULT and writes to run_out.
4. Takes the latest SPEED_SP (Float), clamps with MIN(SPEED_SP, max_speed).
5. Selects SPEED = clamped_speed if RUN else 0.0, writes to speed_out.

Steps 3 and 5 are deterministic within one scan. That is the hardware-fast interlock guarantee. The FAULT tag is also exposed for an AlarmDefinition to wrap (typical pattern: TagTrue with exceptionAction: Hold so the batch pauses for operator acknowledgement even though the drive itself has already dropped out).

Why the interlock lives in the network

Most diagnostic signals (MISMATCH, DEV_ALARM) are raised as tags and wrapped by AlarmDefinition for debounce, severity, and action, keeping the control module stateless. VFD fault is the exception. Drives can damage themselves or their loads in hundreds of milliseconds, faster than a Kubernetes-hosted alarm reconciler can react. The in-network AND-gate ensures the drive output is zero the moment the fault arrives, independent of alarm handling. The AlarmDefinition then handles batch-level response (hold, operator acknowledgement) on top of the already-safe hardware state.

Failure modes

• Fault signal stuck high — drive never runs. Visible as RUN_CMD = true, FAULT = true, RUN = false. Check wiring and the VFD fault contact.
• Fault signal stuck low during an actual fault — the in-network interlock can't help because the tag lies. This is why the AlarmDefinition wrap is still valuable: it gives a second line of evidence (e.g. overcurrent observed on the analog-sensor wrapping motor current) that can hold the batch independently.
• Speed setpoint above max_speed — silently clamped. If you want to alarm on attempted overdrive, wrap SPEED_SP (not the internal SPEED tag) with AlarmDefinition(TagHigh).

Reference instances

Deployment	Unit	Instance	Purpose
newark-plant	granulator-1	impeller-motor	Main impeller drive for dry mixing and wet granulation

The impeller motor pairs with an analog-sensor called impeller-current that monitors VFD current draw. HH/H alarms on impeller-current.PV catch over-torque (binding). L/LL catch belt slip or empty bowl. The vfd template owns the fast fault interlock. The analog-sensor + AlarmDefinitions own the slower diagnostic loop.

Try it

On newark-plant:

1. Process → newark-plant → granulator-1
2. Click the impeller-motor symbol on the unit detail view
3. Write SPEED_SP and toggle RUN_CMD — observe RUN and SPEED respond
4. Force fault = true via the IOModule simulation — observe RUN drops to false and SPEED to zero within one scan cycle, and the impeller-motor-fault AlarmDefinition holds any running batch