VFDs Drives
On the load piping lesson we said variable-flow systems need a pump that can vary too — and forward-pointed to "the VFDs lesson" for what that pump actually is. This is that page. A variable frequency drive is the box between the line voltage and a motor that lets the motor run at any speed you ask for. It's also the box every controls tech ends up writing to from the BMS, and the box where half the "why won't this thing run" service calls trace back to a single misconfigured parameter. We'll cover both ends — what a VFD is, and what the controls-tech-facing surface of it looks like once it's on a network.
What a VFD Is
A drive takes fixed-frequency AC line power (60 Hz in the U.S., 50 Hz most everywhere else) and converts it to AC at whatever frequency the controller asks for. Lower frequency, slower motor; higher frequency, faster motor. Three stages, in order:
Inside the drive that's a wall of insulated-gate bipolar transistors (IGBTs) switching the DC bus on and off thousands of times a second to synthesise a sine-shaped output. From a controls perspective none of that matters. What matters is the surface above it — the parameters that decide what frequency the inverter outputs, when it's allowed to run, and where it gets its commands from. That's where every "configure the drive" task lives, and it's the rest of this page.
Why Drives Are Everywhere — The Cube Law
Walk through any modern mechanical room and you'll see drives on the pumps, on the fans, sometimes on the compressors. Forty years ago the same equipment ran at one speed and dumped whatever it didn't need through bypass dampers, three-way valves, or vanes. The reason that changed isn't comfort or controllability (those are nice side effects). It's energy, and the math is short.
For centrifugal equipment — fans, pumps, most compressors — the power required scales roughly as the cube of the speed. Drop the speed to 80%, the power isn't 80% of design; it's 0.8³ ≈ 51%. Drop it to 50% and the power's down to 0.5³ ≈ 13%. You don't need that many minutes a day at part load before the drive pays for itself on the electric bill.
Cube law — power vs. speed on centrifugal loads
Real drives lose a few points to inverter and motor inefficiency, especially at very low speed, so don't expect the numbers above on the meter — but the shape of the curve is what's selling the drive.
That's why a building with variable-flow pumping (every load piped two-way) almost always pairs with a VFD on the system pump — at part load you want the pump to slow down with the building, not push the same volume around all day. Same story on the air side: VAV (variable-air-volume) systems with a VFD on the supply fan ramp down with the boxes, and the fan's the biggest energy hog on the unit. Cube law is the why; the rest of this page is the how.
Run Command vs. Speed Reference
Here's the thing that catches more techs than anything else about drives. To make a VFD run a motor, you're actually giving it two commands, not one — and each command has its own source parameter, configured independently in the drive. The two are:
- Run command — should the drive be running right now? On/off, start/stop. Sourced from one of: the drive's keypad, a hardwired digital input on the terminal strip, or a write over the network (BACnet, Modbus, etc.).
- Speed reference — if you are running, how fast? An analog value (Hz, RPM, %), sourced independently from one of the same three places: keypad, an analog input on the terminal strip (usually 4–20 mA), or a network write.
The mistake — and it's a common one — is treating these as one thing. You set up the speed reference to come from BACnet, the BMS is happily writing 30 Hz to the speed-reference AV (a BACnet Analog Value object), and the drive doesn't run. Why? Because the run-source parameter is still set to "terminals" from the factory, and there's no digital-input run signal wired up. Two parameters; you only changed one.
Try it. The widget below is a tiny mock drive that respects whatever you set the run and speed sources to. Pick a configuration, then try to start it from each of the three command surfaces. The status panel tells you what it accepted and what it ignored.
The takeaway every drive-shaped thing on a job site shares: setting the speed reference is necessary, not sufficient. If the run command isn't coming from the same place you expect it to, the drive will sit there ignoring you no matter how clean your BACnet write is. When troubleshooting a drive that "won't run from the BMS," the first two parameters to check are both source parameters — not one.
The Parameter Groups Every Drive Has
Every manufacturer organises parameters differently — ABB calls them parameter numbers, Yaskawa calls them Pn-codes, Danfoss uses three-level menus — but the categories the parameters fall into are basically the same across the industry. If you can name the categories, you can find what you need to change on any drive without reading the whole manual cover to cover. Six groups; everything you'll touch lives in one of them.
Motor data · nameplate
Whatever's printed on the motor's nameplate, copied into the drive: full-load amps (FLA), rated voltage, rated frequency, rated speed (RPM), sometimes motor type and power factor. The drive uses this to size its current limit and run an auto-tune that builds its internal model of the motor. Get this wrong and the drive either trips on overcurrent at modest loads or quietly cooks the motor. First thing entered when commissioning a new drive; rarely touched again.
Ramps · accel / decel
How long the drive takes to ramp from 0 Hz to rated frequency on a start (accel time) and back down on a stop (decel time). Seconds. Sometimes a ramp shape parameter too (linear vs. S-curve) to ease mechanical shock. Too fast and you trip on overcurrent during accel or on overvoltage during decel (the motor regenerates back into the DC bus); too slow and the building feels sluggish or the sequence times out. Tune at startup; touch them again only if something complains.
References & sources · what speed, from where
The speed-reference source parameter (keypad / terminals / network / one of several presets), plus the bounds the reference is allowed to take: minimum frequency, maximum frequency, preset speeds, and the scaling that maps a 4–20 mA AI to a Hz range. Half the time a drive isn't ramping where you expect, this group is where the answer lives.
Run/stop sources · start command
The run-command source parameter, independent from the speed source above. Choices are the same set (keypad / terminals / network), but the parameter is separate. Sometimes a 2-wire vs. 3-wire distinction (maintained DI for run vs. momentary start/stop), jog enables, and a forward/reverse selection. Touch this in commissioning to flip a drive over from "keypad bench-tested" to "running from the BMS."
I/O configuration · what each terminal does
The drive's physical inputs and outputs are software-assignable. A digital input can be a run command, a fault reset, a jog enable, or a preset-speed select; an analog input can be the speed reference or a feedback channel; a digital output can signal "drive running," "fault active," or "at speed." This group is the map from physical terminal to logical function. Read it before wiring anything; verify it after.
Faults & protection · what to do when it trips
The fault history (the last N trips, with timestamps and the operating state at trip), plus the protective behaviour: auto-reset enable, auto-reset count and timeout, fault-output relay assignment, undervoltage ride-through, current-limit setting. Auto-reset is the parameter the maintenance crew turns on after they get tired of resetting drives, and that the controls tech turns off after they get tired of finding the same root cause re-tripping unnoticed.
Network Integration — Where Controls People Meet the Drive
The keypad on the front of the drive is for commissioning and panel-front diagnostics; in production the drive lives on a network and talks to the BMS over one of three protocols. Same three you'll meet anywhere else in the building, with the usual physical-layer tradeoffs.
| Protocol | Physical | Speed | Typical use |
|---|---|---|---|
| Modbus RTU | RS-485, twisted pair, daisy-chained | 9600 – 115200 baud | Older drives, retrofits, plant equipment with no BACnet option. Simple, well-supported. |
| BACnet MS/TP | RS-485, twisted pair, daisy-chained | 9600 – 76800 baud | Drives on a dedicated MS/TP trunk under a BMS field controller. Same wire as Modbus RTU; different protocol. |
| BACnet/IP | Ethernet, twisted pair or fibre | 10 / 100 / 1000 Mbps | Drives with a built-in or add-on Ethernet card; routed alongside the rest of the BMS. Modern default on new gear. |
What the BMS actually reads and writes is consistent across protocols, even when the addressing isn't. The four points worth knowing about on every drive:
- Run command — a binary value the BMS writes. Setpoint, not feedback. (And only effective if the drive's run-source parameter is set to "network" — see the widget above.)
- Speed reference — an analog value the BMS writes, usually in Hz or as a percentage of rated frequency. Same caveat: only effective if the speed-source parameter points at the network.
- Run status — a binary the BMS reads back. This is what tells you the drive actually started; never trust the BMS's own "I just sent the run command" view of the world.
- Actual frequency / current / fault code — the analog and binary feedbacks. At minimum, the BMS should be logging actual Hz, motor current (an early indicator of mechanical trouble), and the active fault code if any.
When you're pulling that hex address off an EBO BACnet/IP discovery and trying to make sense of it, the BACnet/IP converter turns it into the dotted-decimal IP. If you're reaching for a Modbus register and need to see the bits, the Modbus register viewer lays a 16-bit word out for you.
Fault Codes — The Conceptual Categories
Every manufacturer's fault-code list looks different and is far too long to memorise. What you can hold in your head is the five or six categories the codes fall into — because the root cause of a category is the same across manufacturers even when the code number isn't. A drive's fault history almost always tells you "an overcurrent happened"; what changes between brands is just which integer they call it.
| Category | What's happening | Usual cause |
|---|---|---|
| Overcurrent | Drive output current exceeded the limit, fast | Short circuit, ground fault, locked rotor, accel ramp too steep, motor data wrong |
| Overvoltage (DC bus) | DC-bus voltage climbed above the trip threshold | Decel ramp too steep (motor regenerating into the bus), incoming line voltage too high, brake resistor missing on a regenerative load |
| Undervoltage (DC bus) | DC-bus voltage sagged below the trip threshold | Incoming line voltage low or dropped out, brownout, loose power connection, building voltage sag on a big motor start |
| Ground fault | Drive detected current leaking to ground | Damaged motor cable, motor insulation breakdown, water in the conduit, wrong cable type on a long run |
| Motor overload | Drive's internal thermal model says the motor would overheat at this current, sustained | Mechanical bind, undersized motor for the actual load |
| Drive overtemp | Heatsink or interior temperature exceeded threshold | Cooling fan failed, filter blocked, enclosure airflow obstructed, ambient too hot |
A drive that auto-resets through a fault every five minutes is telling you something is still wrong. Reading the fault category — not just clearing the alarm — is the difference between fixing the problem and burning the motor.
Bypass Arrangements
On critical loads — life-safety fans, primary chilled-water pumps, anything where a drive failure shouldn't drop the equipment — the panel often includes a bypass. The selector switch routes line power either through the drive or directly to the motor across the contacts of a second contactor. Three positions: OFF, DRIVE (normal — variable speed), BYPASS (across-the-line — full speed, no drive). When the drive faults, you flip to BYPASS and the equipment keeps running at 60 Hz while someone gets a replacement on order.
Bypass is an electrical and operations topic more than a controls one — the BMS usually only sees a binary "in bypass" status feedback so the sequence can decide whether to keep modulating speed reference at a drive that isn't there. Worth knowing exists; not worth more than that on a controls-focused page.
Tying It Back to Load Piping
On the load-piping lesson we set up the variable-flow picture from the load side: every coil is throttled by a two-way valve; the system pump should slow down as the loads close in. The VFD is the answer to the pump side of that picture. The system pump's BMS-facing surface is a run command and a speed reference — exactly the two parameters we just walked through — and the BMS modulates the speed reference to hold whatever variable the sequence cares about (usually a differential pressure across the loop, sometimes a return-temperature setpoint, occasionally a valve-position reset on the most-open valve).
That last part — how the BMS decides what speed reference to send — is its own topic, and it now has a lesson on each fluid. The pump-control lesson picks up from here on the water side, walking through pump curves and the operating point, DP-based control with a remote sensor, and DP setpoint reset for the bottom of the cube-law savings; duct static control is the same story on air — a supply fan slowing against a static setpoint while the VAV boxes throttle.
And if you want to actually feel how the parameter tree on a real drive lays out — pressing up/down/enter/escape, finding the run-source parameter buried three menus deep, watching commanded Hz vs. actual Hz when you hit RUN — the mock VFD interface is the next step. Same source-parameter pedagogy as the widget above, but with a keypad and a parameter tree to navigate.