You get handed a drive you've never seen before. Maybe it's been in the building since before you started, maybe it's an out-of-production model whose manual is a scanned PDF someone posted on a forum in 2011. The mechanical contractor wired it, it spins the fan from the keypad, and now it's your job to make it talk to the BAS.
So you go looking for the manual. You find one — except it's the quick-start guide. You find another, and it's 400 pages of parameters for a whole product family, most of which don't apply. Forty minutes later you've learned how to configure a PID loop you don't need, and you still don't know what address the drive is on.
Here's the thing that makes this tractable: the parameters you actually need are almost never more than eight, and they're the same eight on every drive ever made. The numbers change. The menu names change. The concepts don't.
Before you open the manual
1. Get the exact model and firmware revision
Off the nameplate, and off the keypad if the drive will show it. Parameter numbers shift between firmware revisions on the same model — this is the single most common reason a parameter number you found online doesn't match the drive in front of you.
2. You probably need two documents, not one
This trips up more technicians than anything else here. Most manufacturers split their documentation: a programming manual covering motor setup, ramps and I/O, and a separate, much thinner fieldbus or communication supplement covering BACnet, Modbus or whatever protocol option is installed.
The comms parameters you need are usually in the supplement. If you're searching the main programming manual for “BACnet” and finding nothing useful, you're reading the wrong book. Search the model number plus fieldbus, communication supplement, or the protocol name.
3. Confirm the comms hardware is actually installed
On plenty of drives the network interface is an option card, not standard. A drive with no card fitted will happily let you set every comms parameter and never speak a word on the wire.
The eight
Protocol selection
Which language the drive speaks on the port. BACnet MS/TP, Modbus RTU, N2, proprietary — many drives support several and ship set to something you don't want.
Look for: protocol select, fieldbus type, comm protocol
Node address
The drive's identity on the trunk. On BACnet you may need to set both a MAC address and a device instance — they're different things.
Look for: address, node ID, slave address, device instance
Serial settings — baud, parity, stop bits
On anything riding RS-485 these must match the trunk exactly. One mismatched drive can disturb an otherwise healthy segment, and the symptom often looks intermittent rather than a clean failure.
Look for: baud rate, parity, data format
Control source — where the run command comes from
Keypad, terminal strip, or network. If this is left on terminals, your network start command does nothing and the drive reports no error at all.
Look for: control source, command source, control place
Speed reference source
A completely separate parameter from #4 on essentially every drive. Analog input, preset, keypad, or network.
Look for: reference source, frequency source, reference place
Speed scaling
How the number you write becomes a frequency. Almost never plain hertz — commonly percent, hertz × 10, or a raw integer where some full-scale value represents maximum speed.
Look for: reference scaling, speed reference format
Status and fault feedback
What you read back: running, at-speed, output frequency, current, fault code. Often a packed status word documented as a bit map in the fieldbus supplement.
Look for: status word, drive status, fault code
Comms loss behaviour
What the drive does when the network goes quiet — coast, ramp to stop, hold last speed, or run at a preset. Usually paired with a timeout value.
Look for: comm loss action, fieldbus fault response, watchdog
The two-source trap
If you take one thing from this page, take this one. Control source and reference source are separate parameters, and setting one does not set the other.
The classic failure: you set the drive to take its speed reference from the network, write 60% to it, and the drive sits there doing nothing. Everything reads correctly. No fault. No error response to your write. The run command is still expecting a dry contact on the terminal strip that nobody wired, because the mechanical contractor was told the BAS would start it.
It looks like a communication failure from the front end. It isn't — the communication is working perfectly. It's a configuration mismatch between two parameters that live in different parts of the manual and get set at different times by different people.
The scaling trap
| What you see | Usual cause |
|---|---|
| Commanded 60, drive runs 6 Hz | Drive expects Hz × 10; you sent plain Hz |
| Commanded 60, drive runs at max | Drive expects percent or a raw full-scale integer |
| Commanded 60, drive runs 0.6 Hz | Drive expects percent; raw value being scaled down |
| Speed close but consistently off | Max frequency on the drive doesn't match what the BAS assumes 100% means |
That last row is worth dwelling on. If the drive's maximum frequency is set to 50 Hz and your sequence assumes 100% equals 60 Hz, every speed command will be wrong by a fixed ratio and nothing will ever throw a fault.
Working an obsolete drive
- Search the exact model plus “fieldbus” or the protocol name, not just the model.
- Try the manufacturer's regional sites. Documentation pulled from a US site sometimes survives on a European one.
- Check who acquired them. Legacy drive lines often live on under a new parent company's support portal.
- Distributor technical support is underrated. They frequently have archived documentation that never made it onto a public site.
- If you truly can't find documentation, enumerate what's live on the wire and work backward — but treat anything derived that way as unverified until proven against actual drive behaviour.
The workflow, condensed
| Step | What you're doing |
|---|---|
| 1 | Record exact model and firmware from nameplate and keypad |
| 2 | Confirm the comms card is physically installed |
| 3 | Find both documents — programming manual and fieldbus supplement |
| 4 | Set protocol, address and serial parameters to match the trunk |
| 5 | Prove the drive runs from the keypad first |
| 6 | Set control source to network; prove start/stop independently |
| 7 | Set reference source to network; prove speed independently |
| 8 | Confirm scaling with a known value — command 50%, measure actual Hz |
| 9 | Set comms loss behaviour deliberately, and test it by disconnecting the trunk |
| 10 | Document every parameter you changed, in the panel and in your notes |
Step 10 is the one that gets skipped and the one that costs the most later. The next person on this drive — possibly you, in two years, with no memory of this visit — will be starting from scratch otherwise.
Go deeper
This is the same method, applied to protocols
Drives, sensors and sequences are all instances of one bigger problem: working out which layer is actually broken when the front end and reality disagree. That's what the book is about — BACnet, Modbus, LonWorks, OPC UA, gateways, and the diagnostic method that works across all of them.
Get BAS Communication — A Field ReferenceFound a wrong number or a broken link? Tell me and I’ll fix it.