Control seven VFDs from an HMI panel over Modbus RTU

One master, seven slaves, one transaction at a time

RS-485 is the electrical layer: an EIA-485 differential signal that many devices share over one twisted pair, with a baseline capacity of 32 unit loads per segment. Modbus RTU is the conversation running on that pair, and the two are separate choices. A drive's RS-485 terminals carry whatever protocol its firmware serves on them, and many drive families serve the maker's own peripheral protocol first with Modbus RTU as a documented second option. Read the communication section of each drive manual and confirm Modbus RTU mode on the RS-485 port before anything else.

Modbus RTU over serial line puts one master on the bus with addressed slaves. Only the master starts a transaction, and each request names exactly one slave address, so there is no group write that reaches all seven drives at once. The HMI therefore needs one control path per drive: one device entry, its address, its tags. Speeds on screen come from seven sequential reads, so the values refresh in turn with a visible stagger between updates. For start, stop and speed reference that stagger is irrelevant, because each command reaches its drive in milliseconds.

The single-drive version of this job is covered in wire an HMI panel to a VFD over Modbus RTU; what follows adds the multidrop work.

What you need

• An HMI panel with a Modbus RTU master driver and at least one RS-485 serial port. Confirm the driver exists before you buy or tune anything; checking the panel driver list before tuning serial settings shows how a missing driver sinks the job early.
• Seven drives whose manuals document Modbus RTU slave operation on the RS-485 terminals, with a register map covering start/stop control, a speed reference, and status.
• Shielded twisted-pair cable for the bus, plus signal common if the drive manuals call for a third conductor.
• 120 ohm termination at each end of the run, from built-in jumpers or resistors across the pair.
• An address plan mapping drive locations to addresses 1 through 7, written on the panel door.
• Mounting and power for the panel: the enclosure door cutout or bracket, and a fused supply sized per the panel's manual, kept clear of the drive power terminals.

Commission the network

1. Set the protocol on every drive. In each drive's communication parameters, select Modbus RTU on the RS-485 port. A drive left on the maker's peripheral protocol stays silent to a Modbus master.
2. Give each drive a unique address. Valid RTU slave addresses run from 1 to 247, and 0 is reserved for broadcast. Assign 1 through 7 in panel order and record the map. The address lives in a parameter menu on some drives and in hardware switches on others; the switch type usually sets baud and addressing modes, and the drive manual's communication chapter shows the pattern.
3. Match the serial settings everywhere. Baud rate, parity, data bits and stop bits must be identical on the master and all seven slaves. Choose from settings every device documents, and when the lists differ, the slowest common baud wins. A common factory default across drives and panels is 9600 bit/s, 8 data bits, even parity, 1 stop bit, which is a workable starting point when all eight ends list it.
4. Wire the daisy chain. Run one shielded twisted pair from the HMI through each drive in physical order, in and out of each drive's RS-485 terminals. Keep polarity consistent end to end, and relabel A and B once at the panel because drive manuals disagree on which name is which. Keep the stub to each drive as short as the terminal layout allows. Fit 120 ohm termination at the two physical ends of the chain only. Ground the shield per the drive manuals, usually at one point, and run signal common as a third conductor when the manuals call for it. For a bus of 2 to 32 devices the standard topology is a single trunk with termination at the two ends only; the wiring chapter of each drive manual and the Modbus over Serial Line specification both describe it.
5. Count the electrical load. The EIA-485 baseline allows 32 unit loads per segment. Eight devices at one unit load each sit at 8 of 32; if any comm port states a heavier load, add its number before you extend the run.
6. Point the drives at the network. Set each drive's command source and speed reference source to the network option in its parameters, and check the reference scaling. If the manual lists the speed register in 0.01 Hz steps, a 45.00 Hz request is the value 4500, and the HMI tag must scale the same way.
7. Build one control path per drive in the HMI. One device entry per address, tags for the control word and speed reference bound to that entry, and buttons labeled with the drive's machine location so the operator knows which drive will move.
8. Prove drive 1 alone. With the machine in a safe state and under the site's approved procedure, read a documented status item from address 1, then write a small speed step, 30 Hz to 32 Hz, and watch the drive and the machine respond correctly. A small step tells you more than a jump to full speed.
9. Add drives 2 through 7 one at a time, testing a read and a command on each address before wiring in the next.
10. Define the loss-of-communication behavior before handover: what each drive should do when it stops hearing from the master, and what the HMI shows. The master side of that recovery is covered in make a Modbus master reconnect after a slave outage.

How to check it worked

• Press each drive's stop in turn and confirm only that drive responds.
• Run a start and a speed change on all seven and watch the HMI's diagnostic or error count stay at zero.
• If you display speeds, the seven values refresh in sequence, each a few transactions behind the one before it, and each tracks its drive's actual speed.
• Take one drive off the bus terminals, machine in a safe state, and confirm the fault appears on the HMI and the network recovers as you defined in step 10, then reconnect it.

Worked example: the seven-drive command cycle at 19200 bit/s

Inputs, with their sources: the link runs at 19200 bit/s, 8 data bits, even parity, 1 stop bit (the example's assumed setting; 19200 bit/s is the reference baud in the Modbus over Serial Line specification). The speed write is a write-single-register transaction, 8 bytes out and 8 bytes back: address, function 06, register, value, two CRC bytes on each frame (Modbus RTU framing). One character puts 11 bits on the wire: 1 start + 8 data + 1 parity + 1 stop. The Modbus RTU framing rule requires a silent gap of 3.5 character times between frames.

Rule in words: time per transaction equals bits on the wire divided by baud, plus two silent gaps; then multiply by seven drives.

Arithmetic:

• Bits per transaction: (8 + 8) bytes x 11 bits = 176 bits. On the wire: 176 / 19200 bit/s = 9.17 ms.
• One character at this setting: 11 / 19200 = 0.573 ms, so one 3.5-character gap is 3.5 x 0.573 = 2.01 ms, and two gaps per transaction add 4.01 ms.
• One drive: 9.17 + 4.01 = 13.2 ms, before the drive's own processing time.
• Seven drives in sequence: 7 x 13.2 = 92.4 ms, about 0.1 s.

Result and decision: at 19200 bit/s a command that reaches all seven drives completes in about 0.1 s; at 9600 bit/s the same cycle is 176 / 9600 = 18.3 ms of wire time plus 8.0 ms of gaps, 26.3 ms per drive and 184 ms for seven, about 0.2 s. Sequential writes are comfortably fast enough for start, stop and speed reference from a screen. Reading all seven speeds once per second adds seven more transactions, about 0.1 s of bus time per second, roughly a tenth of the segment's transaction capacity.

The number that wrecks the cycle is the response timeout. A master set to wait 1 s on a drive that never answers adds a full second to every pass, which is why the timeout set on absent devices matters. Stop an HMI polling PLCs that are not installed works that number through. A cycle taking whole seconds means a timeout or a retry, never the wire at these bauds.

When a drive will not answer

Check in this order:

• Nothing answers, all seven. Serial settings or wiring. Confirm the master's baud, parity and stop bits against the drives, then A/B polarity and the 120 ohm termination at both ends. The full cause list is worked through in Modbus RTU master no-reply and address errors: fix both.
• One drive silent, six alive. Suspect its address: a duplicate or a mistyped device entry. Swap address entries between the silent drive and a working one. If the fault follows the number, the HMI device entry is wrong; if it stays with the drive, the drive's own setting is.
• Reads work, commands do nothing. The drive's command source still points at its terminals or keypad. Switch the source to the network in its parameters and retest.
• Speed lands wrong by a round factor. Scaling. Divide the requested speed by the speed the drive actually reached, compare against the manual's register units, and correct the HMI tag scale.

The decision, case by case

• Start, stop and speed from the panel, with timing and discrete I/O handled elsewhere: one HMI master on the bus at addresses 1 through 7, commissioned with the steps above. This is the case the whole page builds.
• Machine logic must react to drive status: give the master role to the controller and connect the HMI to the controller, keeping exactly one RTU master on the RS-485 bus. Two masters on one bus produce collisions and ghost replies; two Modbus RTU masters on one RS-485 bus: why and the fix shows the failure and the wiring fix.
• Speeds on screen matter: poll each drive in turn, expect the sequence stagger from the worked example, and poll no faster than the screen actually needs.

Recommendation: Put all seven drives on one RS-485 daisy chain at Modbus RTU addresses 1 through 7, match the master's serial settings to the slowest setting all eight devices share, terminate at 120 ohm at both physical ends, and commission one drive completely before adding the next six. Keep emergency stop and every safety function wired to the drive's own safety inputs; a network write is not a safety function.

Questions