Why Your VFD Won't Start From SCADA (and How Control Words Actually Work)

A drive is not a simple start/stop relay

A variable frequency drive (VFD) rarely exposes a plain run contact and a plain running lamp. Most drives are commanded through a packed control word and report state through a packed status word, each a 16-bit register with meaning assigned bit by bit. The SCADA or PLC has to assemble the right bit pattern to start the motor, and decode the returned bits into states the operator understands.

This is where commissioning goes wrong. The wiring is fine, communication is up, but the drive will not start, or it starts and the HMI says "stopped," or a fault clears on the drive but the SCADA fault lamp stays latched. Almost every one of these is a control-word or status-word mapping detail that was guessed instead of proven.

Treat the control word and status word as a documented interface, the same way you would treat a Modbus register map. Decode one bit at a time and prove each transition.

The control word is a sequence, not a single command

The common trap is thinking "set the run bit and the motor turns." Most drive profiles (CiA 402 and PROFIdrive, both standardised under IEC 61800-7, plus vendor equivalents) require a small state machine to be walked in order before the run command is accepted:

Clear any coast/quick-stop inhibit bits so the drive is allowed to be enabled.
Assert "enable / ready to switch on."
Assert "switch on" and "enable operation."
Only then does the "run forward / start" bit actually spin the motor.

A typical control word looks like this once decoded:

Bit	Meaning	Notes
0	Switch on / ON	Often must be 1 as a precondition
1	No coast stop (enable voltage)	Active-low logic: 1 = allowed
2	No quick stop	Active-low logic: 1 = allowed
3	Enable operation	Required before run
4	Ramp / run enable	Vendor specific
7	Fault reset	Rising edge, not level
8	Jog	Momentary
11	Reverse direction	Direction, not run

Note the active-low bits. Several drives use "no coast stop" and "no quick stop" bits where a 0 means stop. If SCADA writes a control word of 0x0000 expecting "everything off, safe," it has actually commanded coast stop and quick stop, which is fine for stopping but means the run bit will never take effect until those bits are set to 1. Write out the required "ready to run" pattern explicitly, for example 0x047F, and put it in the commissioning note.

Fault reset is an edge, not a level

The single most common status-word complaint is: "the drive fault is gone but SCADA still shows faulted." The usual cause is fault reset handling.

The fault reset bit in the control word is almost always edge triggered. Holding it at 1 does nothing after the first transition, and can even block re-arming.
The SCADA logic should pulse the reset bit 0 -> 1 -> 0, then read the status word again to confirm the fault bit cleared.
Do not latch the reset bit permanently "to be safe." That masks new faults and prevents subsequent resets.

Build the reset as a one-shot: operator presses reset, SCADA sets the bit for one or two scan cycles, then clears it, then confirms via the status word. This mirrors the command feedback timeout pattern used for any drive command, and the reset should time out and report failure if the drive fault does not clear.

Decode the status word into named states, not raw bits

The status word is the mirror image of the control word: a packed 16-bit value where each bit reports one condition.

Bit	Meaning	Use in SCADA
0	Ready to switch on	Precondition indicator
1	Switched on	Intermediate state
2	Operation enabled	Drive is energised
3	Fault	Drive faulted, needs reset
4	No coast (voltage enabled)	Safety chain indicator
5	No quick stop	Safety chain indicator
6	Switch-on inhibit	Blocks start until cleared
7	Warning	Non-latching alert
10	Target/speed reached	At-speed feedback
11	Internal limit active	Torque/current limit

Do not push raw status bits onto the HMI. Combine them into one derived state the operator can read at a glance: Not Ready, Ready, Running, At Speed, Warning, Faulted, Inhibited. This is the same discipline as any derived status tag: one clear state that HMI, alarms, trends, and reports all share, instead of six lamps the operator has to interpret.

A minimal decode:

if     status.bit3            -> "Faulted"
elif   status.bit6            -> "Inhibited"
elif   status.bit2 and bit10  -> "At Speed"
elif   status.bit2            -> "Running"
elif   status.bit0            -> "Ready"
else                          -> "Not Ready"

Speed reference and feedback need their own scaling

Beyond the bit words, the drive exchanges a speed reference (SCADA to drive) and a speed feedback (drive to SCADA). These are usually scaled integers, not engineering units.

Many drives use 16384 (0x4000) as 100% of reference frequency, not the Hz value. Writing 50 expecting 50 Hz gives roughly 0.3% speed.
Confirm whether the reference is percent of max frequency, a raw Hz x scale, or an RPM value.
Confirm the feedback scaling separately; reference and actual can use different scales on the same drive.
Decide and document the direction convention: is reverse a negative reference, or a separate control-word bit?

Prove scaling the same way you prove a Modbus 32-bit value: write a known reference, read the raw register, and record both the raw count and the resulting Hz. Do not add a "fudge" multiplier to make one setpoint look right.

Commission one transition at a time

Test the interface on the bench or with the motor uncoupled before trusting it in the process:

Read the status word at rest and record the raw hex and decoded state. Confirm it matches "Not Ready" or "Ready."
Write the ready-to-run precondition pattern, without the run bit, and confirm the drive reports "operation enabled" or equivalent, still stopped.
Add the run bit and a small speed reference. Confirm the motor turns and the "running" / "at speed" bits appear.
Command stop and confirm the drive ramps down and the status returns to "Ready."
Trigger a fault (e.g. a controlled overcurrent or an external trip), confirm the fault bit sets, then pulse reset and confirm it clears.
Test loss of communication: what does the drive do when the fieldbus drops? Confirm the configured behavior (hold, ramp to stop, coast) matches the safety design, and that SCADA shows the tag as bad quality rather than the last-known state.

Watch these interface details

A few things that repeatedly cause lost commissioning hours:

Active-low safety bits. "No coast stop" and "no quick stop" are 1-means-allowed. A zeroed control word will not run.
Local/Remote mode. A drive in local (keypad) mode ignores fieldbus commands entirely. Confirm and display the control-place bit.
Bit numbering. Vendor manuals mix 0-based and 1-based bit numbering, and MSB/LSB display order varies by tool. Note which is which.
Word order. If the control and status words arrive as part of a larger process-data telegram, the word order and byte order still apply.
Watchdog / lifebit. Many drives require a periodic control-word toggle or a heartbeat, or they trip on communication loss. Pair this with a SCADA heartbeat/watchdog tag.
Warning vs fault. A warning bit does not stop the drive; do not alarm it at the same priority as a trip.

Closeout checklist

Before handing over the drive point list, the project record should include:

The exact "ready to run" control-word pattern in hex, with each bit's meaning.
Whether fault reset is edge or level, and how SCADA pulses it.
The full status-word bit map and the derived-state logic built from it.
Reference and feedback scaling, proven with a recorded raw value and the resulting Hz or RPM.
Direction convention (bit vs signed reference).
Communication-loss behavior of the drive and the matching SCADA quality handling.
Local/Remote control-place handling and how it is shown to the operator.

A VFD interface that is documented at this level starts, stops, and clears faults the way the operator expects. One that was guessed bit by bit will run on the bench and then confuse everyone the first time it faults in production.