A PLC controls a VFD over a network by cyclically exchanging a fixed block of process data. Whatever the protocol — PROFINET, PROFIBUS, EtherNet/IP or Modbus — the pattern is the same: the PLC writes a control word (individual bits meaning run, stop, reset, direction) plus a speed reference, and reads back a status word (ready, running, fault, at-speed) plus actual speed. The speed reference is almost always a normalised value rather than Hz or RPM, so the PLC must scale it. Everything else — motor data, ramps, current limits — stays in the drive's own parameters and should not be pushed over the network.
- Networked control replaces a bundle of digital and analogue wires with four words, and adds diagnostics that hardwiring cannot provide.
- Always drive the HMI "running" indication from the drive's status word, never from the PLC's own command bit.
- Keep configuration data in the drive and command data on the network. Writing parameters cyclically is a common and avoidable design error.
- Comms loss behaviour must be configured in the drive, because during a comms loss the PLC cannot reach it.
Three Ways a PLC Can Control a Drive
| Method | Wiring | What you get | What you lose |
|---|---|---|---|
| Hardwired terminals | Digital outputs for run/stop/reverse, analogue output for speed, digital inputs for run and fault feedback | Simple, no protocol knowledge needed, independent of network health | No fault code, no actual current or torque, one analogue channel per drive, extensive cabling |
| Fieldbus / industrial Ethernet | One network cable, daisy-chained or through a switch | Full control word, status word, fault numbers, actual values, and parameter access | Depends on network health; needs correct configuration on both sides |
| Mixed | Hardwired safety-relevant stop plus network for everything else | Independent stop path that does not rely on the network, with full diagnostics | Slightly more wiring; the usual arrangement on machines with safety requirements |
The mixed approach is what most well-built machines actually use. Safety functions belong on a certified path — a safety relay, or a drive safety function such as STO wired to a safe output — not on a standard process network. Everything else runs over the network, where the PLC can read a fault number and display it on the HMI instead of the operator being told only that "the drive tripped".
The economic case for networked control grows with drive count. Hardwiring ten drives means ten analogue output channels and forty-odd digital points; putting them on a network means one cable run and forty words of process data.
Network Options Compared
| Network | Typical PLC | Drive interface | Notes |
|---|---|---|---|
| PROFINET | Siemens S7-1200 / S7-1500 | PROFIdrive telegram, I/O addresses assigned in TIA Portal | The default for new Siemens machines; device name based addressing, strong diagnostics |
| PROFIBUS DP | S7-300 / S7-400 / S7-1500 with CM | Same PROFIdrive telegrams over DP | Enormous installed base; telegram structure identical to PROFINET, only the transport differs |
| EtherNet/IP | Allen-Bradley ControlLogix / CompactLogix | Add-On Profile with input and output assemblies | Tag-based; the AOP maps drive data into structured tags automatically |
| Modbus RTU | Any PLC with an RS-485 port | Holding registers for command and setpoint | Universal and inexpensive; slower, one transaction at a time, no built-in diagnostics |
| Modbus TCP | Any PLC with Ethernet | Same registers over port 502 | Useful for mixed-vendor sites and for gateways |
The important insight is that the application-level model barely changes across these. A control word with a run bit, a status word with a fault bit, and a normalised speed reference appear in all of them. An engineer who has integrated a drive on PROFINET can pick up EtherNet/IP or Modbus quickly, because only the addressing and the configuration tooling are new.
Integrate drives on real PLC hardware
Practical sessions on PROFINET, PROFIBUS and Modbus drive control with S7 and SINAMICS equipment — Pune classroom or online.
The Control Word / Status Word Model
The control word is a single 16-bit value in which individual bits carry commands. It is not a set of independent flags you can toggle freely — most drives implement a state machine, and the drive only accepts a run command when the enable bits are already satisfied.
| Typical control bit | Function | PLC handling |
|---|---|---|
| Run / stop | Starts and ramp-stops the drive | Level-driven from the machine sequence |
| Coast stop enable | Removes pulses immediately when cleared | Normally held true; cleared only by an intentional emergency path |
| Quick stop enable | Fast ramp stop when cleared | Normally held true |
| Enable operation / pulse enable | Permits the output stage to switch | Held true whenever the machine is in a runnable state |
| Fault acknowledge | Clears an acknowledgeable fault | Edge-triggered — pulse for one or two scans, never hold |
| Direction / reverse | Inverts the setpoint sign | Only where the mechanics permit reverse rotation |
| Control by PLC / network control | Tells the drive to obey the network at all | Held true; the single most commonly forgotten bit |
Fault acknowledge is worth spelling out. Holding the acknowledge bit permanently true makes faults appear to clear instantly and hides a repeating condition — a motor tripping on overload every thirty seconds will simply run hot until it fails, with nothing visible on the HMI. Pulse it from the operator's reset button and no longer.
The status word runs the other way, and the discipline is equally simple: use it for everything the operator sees. Drive the HMI running lamp from the drive's "operation enabled" bit, the fault lamp from the drive's fault bit, and any "up to speed" permissive from the drive's setpoint-reached bit. A lamp driven from the PLC's own output bit shows what the PLC asked for, not what happened.
Scaling the Speed Reference
Drives almost never accept a speed reference in Hz or RPM over a network. They use a normalised integer, and the mapping is defined by a reference parameter in the drive.
| Family | Normalisation | Reference parameter |
|---|---|---|
| SINAMICS / PROFIdrive | 16384 (16#4000) = 100 % | p2000 — reference speed in RPM |
| Many Modbus drives | Often 0–10000 = 0–100 %, or direct 0.01 Hz units | Documented in the drive's register map |
| EtherNet/IP AOP | Frequently engineering units handled by the profile | Set in the drive's reference configuration |
The conversion in the PLC is arithmetic, but it must be guarded. A calculation that produces a value beyond the signed 16-bit range wraps to a large negative number, which most drives interpret as full speed in reverse. Clamp before writing, every scan, without exception:
Ref := (Speed_RPM / RefSpeed_RPM) * 16384.0;
IF Ref > 16384.0 THEN Ref := 16384.0; END_IF;
IF Ref < -16384.0 THEN Ref := -16384.0; END_IF;
NSOLL := REAL_TO_INT(Ref);
Scale the feedback the same way in reverse so the HMI shows RPM rather than a raw count, and so any values you archive to a historian or SQL database are already in engineering units. Archiving raw normalised counts and converting later is a reliable source of reporting errors months afterwards.
Cyclic vs Acyclic Data
Two distinct channels exist, and using the wrong one is a common design mistake.
Cyclic data is the telegram exchanged every bus cycle: control word, setpoint, status word, actual value. It is fast, deterministic and consumes bandwidth continuously. Put commands and live values here.
Acyclic data is on-demand parameter access — reading a fault history, changing a ramp time, uploading a full parameter set. On Siemens systems this uses the RDREC and WRREC instructions; on other platforms it goes by explicit messaging or a similar mechanism. It is slower, non-deterministic, and completes over several scans.
The mistake to avoid is writing configuration parameters cyclically. A program that pushes the ramp time into the drive every scan writes to the drive's non-volatile memory repeatedly, wears it out, and makes the machine's behaviour depend on the network being healthy at every moment. Set ramps, limits and motor data once, in the drive, and let the network carry only commands and setpoints.
Designing for Communication Loss
Two separate questions need deliberate answers, and only one of them is the PLC's to answer.
What does the drive do? This must be configured in the drive itself, because during a network failure the PLC has no way to influence it. Most drives offer a telegram-failure or comms-timeout response: coast, ramp down, quick stop, or continue at the last setpoint. Choose based on the process. A conveyor carrying product usually wants a controlled ramp stop; a cooling fan may well be safer continuing at its last setpoint until an operator intervenes.
What does the PLC do? Monitor the device's network status and treat a lost drive as an alarm that stops dependent equipment, rather than a silent failure. On an S7-1500, device status is available through the system diagnostics and diagnostic instructions. On Modbus, the master must implement its own timeout and retry count — three consecutive failed transactions is a reasonable threshold before declaring the device failed.
A related trap on Modbus RTU: one unresponsive slave stalls the entire poll cycle while the master waits out its timeout on every scan. If a drive goes offline and the whole line becomes sluggish, that is why. Mark a repeatedly failing node as dead and skip it, retrying occasionally rather than every cycle.
A Reusable Drive Function Block
Ten drives on a machine should mean one function block and ten instance data blocks — never ten copies of similar logic. Copied logic diverges: someone fixes a scaling bug in conveyor 3 and not in conveyors 1, 2 and 4, and the difference surfaces a year later.
A sound interface for such a block:
| Direction | Signal | Type | Purpose |
|---|---|---|---|
| Input | Enable | BOOL | Machine-level permissive; holds the drive in a ready state |
| Input | Start / Stop | BOOL | Run command from the sequence |
| Input | Reset | BOOL | Operator reset; the block converts it to an edge internally |
| Input | Speed_RPM | REAL | Requested speed in engineering units |
| Input | RefSpeed_RPM | REAL | The drive's configured reference speed, for scaling |
| Output | Running | BOOL | From the drive status word, not from the command |
| Output | Fault | BOOL | From the drive status word |
| Output | AtSpeed | BOOL | Setpoint-reached bit, used as a downstream permissive |
| Output | Actual_RPM | REAL | Scaled feedback for HMI and archiving |
| Output | CommsOK | BOOL | Device status; drives the machine's response to a lost drive |
| In/Out | Telegram | UDT | The mapped process data words for this drive |
Written in SCL this is a compact, testable block. Written once and instantiated per drive, it makes the eleventh drive a configuration exercise rather than a programming one — and it means a scaling fix applies everywhere at once.
Step-by-Step Lab: Build a Drive Interface Block
Hands-on- TIA Portal V17 or later with an S7-1200 or S7-1500 project. PLCSIM is sufficient for the logic; a real drive makes steps 5 and 6 meaningful.
- A drive already configured on the network with a telegram selected, if hardware is available.
- Basic familiarity with creating a function block and an instance data block.
- Estimated time: 45 minutes.
Create a UDT for the telegram
Add a PLC data type named Drive_Telegram with members ControlWord (Word), Setpoint (Int), StatusWord (Word) and ActualValue (Int).
Build the function block interface
Create FB_Drive in SCL with the inputs, outputs and in/out parameter described in the table above. Add a static BOOL for the previous state of Reset so an edge can be detected internally.
Write the scaling with clamping
Convert Speed_RPM to a normalised setpoint using RefSpeed_RPM, clamp the result to ±16384, and write it to Telegram.Setpoint. Scale Telegram.ActualValue back to Actual_RPM.
Build the control word and decode the status word
Assemble ControlWord from the Enable and Start inputs plus the required always-true enable bits, and pulse the acknowledge bit only on a rising edge of Reset. Decode StatusWord bits into Running, Fault and AtSpeed.
Instantiate it twice
Call FB_Drive twice from OB1 with two separate instance data blocks and two separate telegram tags mapped to two drives (or two simulated address ranges).
Test the failure paths
With real hardware, disconnect one drive's network cable while both are running. Observe CommsOK, the other drive's behaviour, and the CPU diagnostic buffer.
The block is correct if an out-of-range speed request clamps rather than reversing the motor, a held reset button does not continuously acknowledge faults, the HMI running indication follows the drive rather than the PLC command, and losing one drive does not disturb the other. Those four behaviours are what separate a drive interface that survives production from one that works on the bench.
Frequently asked questions
What is a control word and a status word?
They are single 16-bit values in which each bit carries a specific meaning. The PLC writes the control word — run, stop, enable, fault acknowledge, direction — and reads the status word, which reports ready, running, fault, warning and at-speed. Almost every industrial drive protocol uses this same model regardless of the network underneath.
Why does the drive ignore my run command even though there is no fault?
Usually one of three things: the "control by PLC" or network-control bit is not set, the drive's command source parameter is still configured for terminals or keypad rather than fieldbus, or the telegram configured in the PLC does not match the one selected in the drive. Check all three before reviewing the program logic.
Should the fault acknowledge bit be held or pulsed?
Pulsed. It is edge-triggered on virtually all drives. Holding it permanently true makes every fault appear to clear instantly and hides a repeating condition — such as a motor tripping on overload every few seconds — that will eventually damage the equipment.
Can I write drive parameters like ramp times from the PLC?
You can, using acyclic parameter access, but you should not do it cyclically. Writing configuration data on every scan wears out the drive's non-volatile memory and makes machine behaviour depend on continuous network health. Set ramps, limits and motor data once in the drive; keep the network for commands and setpoints.
What should happen if the network connection to the drive is lost?
The drive applies its own configured telegram-failure response — coast, ramp down, quick stop or hold — because the PLC cannot reach it during the loss. Configure that deliberately in the drive to suit the process, and separately have the PLC monitor device status so dependent equipment is stopped and the operator is informed.
Is one function block per drive really necessary?
One block, instantiated once per drive, is the maintainable pattern. Copied logic diverges over time — a scaling or edge-detection fix applied to one copy and not the others produces failures that appear months later and are hard to trace. An instance-based block fixes every drive at once.