Wireless serial link between a PLC and an HMI panel

Can a pair of Zigbee radios replace the PLC to HMI cable?

Yes for a monitoring screen that tolerates 1 to 2 seconds of staleness, no for a screen whose buttons start or stop equipment, because a 250 kbit/s Zigbee pair adds hundreds of milliseconds to every request and reply.

A serial cable is a plain pipe: it moves bytes at one speed both ends agreed on. The radio pair has to behave the same way. The PLC keeps talking to what it believes is a serial port, the HMI keeps polling what it believes is a serial port, and the pair carries every byte across the air in between. Nothing in the PLC program or the HMI project changes, and the link is the only difference. The 250 kbit/s figure is the rated air rate of the Zigbee physical layer under IEEE 802.15.4; what reaches the serial port per second is less.

The decision comes down to staleness and writes. A temperature or status screen that refreshes once a second shows values that are already seconds old, so an added radio delay does little harm there. A write button pays the crossing twice, once for the request and once for the reply, and a retry after an interference hit doubles it again. That is why the write path is what usually disqualifies a radio link, more than the reading path ever does.

What decides whether the link carries the protocol?

Two layers decide it: the electrical interface, where each radio's serial port must match the PLC and HMI port it connects to, and the radio link itself, which must carry bytes in both directions with the baud rate, data bits, parity and stop bits set the same at every hop.

Start at the electrical layer. Identify what each equipment port actually is before buying anything: an RS-232 port, an RS-485 port or a bare logic-level UART. RS-232 swings its data line several volts negative and positive while a logic-level UART runs between 0 and 5 V, so the two cannot be wired straight across. Where the interfaces differ, the converter the radio maker documents for that job goes between them and becomes part of the link for good.

Then the settings layer. Serial data only flows when the UART settings match at each hop: the PLC and the first radio need the same baud rate, data bits, parity and stop bits, and so do the second radio and the HMI. Put both radios on the same network settings too, so they join one network and find each other.

Finally the mode. In transparent operation the Zigbee module guide documents the pair acting as a serial line replacement: bytes in one port come out the other port in order, with nothing added. That is the mode a PLC-to-HMI link needs. A mode that buffers for later delivery, packetizes toward a host computer, or sends in one direction only breaks the pattern, because an HMI exchange is a question and an answer and half a conversation returns no values.

Before any of this, confirm which driver or protocol the HMI project selects and that its settings match the PLC port; the check before replacing a legacy HMI panel walks that in order.

How slow will the screen be on a 250 kbit/s radio pair?

Budget 100 to 300 ms for one poll exchange through a one-hop Zigbee pair, and figure the screen shows a changed value one poll interval plus one exchange later, so a screen polling every second lands at roughly 1.1 to 1.5 seconds from change to display.

Split the delay into three parts. The HMI's own poll interval comes first: a screen that asks every second displays values that average half a second old even on a perfect link, and no radio fixes that. The exchange time over the air comes second: channel access, transmission and unpacking on the way out, then the same again on the reply. Retries come third: every interference hit adds another full crossing, and interference near welders, motors and switching loads is normal.

The air rate rarely settles the question. One register poll is a few hundred bits, so even a pair delivering a tenth of its rated rate sits nearly idle at one poll per second. Latency is what the buyer feels. If the link speaks Modbus RTU and replies already wobble on the wire, the radio stretches that wobble; start with the erratic Modbus RTU response delay fix before blaming the radios. When the whole chain feels slow, not only the radio section, the 10 to 15 second delay trace walks panel to device in order.

How long does one poll cycle take in a worked example?

One poll of 8 registers at 19200 baud carries 270 bits on the wire and a second or less over the air, so a temperature screen polling once a second sits far below the pair's capacity and the delay comes from radio overhead, not from bandwidth.

Scenario: a shop floor watches four heater temperatures on one screen. The HMI reads 8 holding registers once per second, the link speaks Modbus RTU, and both serial ports run 19200 baud, 8 data bits, no parity, 1 stop bit, so every byte travels as 10 bits with its start and stop bits.

The request frame is 8 bytes: address, function code, start address, register count and CRC. 8 bytes x 10 bits = 80 bits. The reply is 19 bytes: address, function code, byte count, 16 bytes of register data and CRC. 19 bytes x 10 bits = 190 bits. One exchange is 80 + 190 = 270 bits. On the cable that takes 270 bits / 19200 bit/s = 14.1 ms. Over the air the same 270 bits take 270 bits / 250000 bit/s = 1.1 ms, which is negligible.

Bandwidth is not the problem. The demand is 270 bits x 1 poll/s = 270 bit/s, about 1% of even the low end of 25 to 60 kbit/s usable. The real cost is fixed overhead at each crossing, and two planning inputs carry it: 100 to 300 ms per exchange through one hop, and a tenth to a quarter of the rated air rate as usable throughput. Both are assumptions to measure with a stopwatch against the wired baseline, because the module guide documents throughput as variable, not as a datasheet promise.

The decision numbers fall out of those inputs. A changed temperature reaches the screen at worst in 1 s poll + 0.3 s exchange = 1.3 s. A button write crosses the air twice, so 0.2 to 0.6 s typically, and seconds after a retry. If 1.3 s of staleness suits the shop, this pair fits the job; if it does not, no throughput figure changes that.

How do I test the radio pair before trusting it?

Run the test in this order: record the wired baseline, match the settings at every hop, swap only the cable for the radios, then judge the link on screen values and error flags, because activity LEDs show traffic and nothing more.

1. Record the wired baseline: which ports the cable uses, which driver the HMI project selects, the baud rate, data bits, parity and stop bits at both ends, and how fast a known tag updates on screen today.
2. Check the radio documentation for its serial interface, its supported settings and its modes, then configure both radios to match the equipment's serial settings and to join one network.
3. Swap only the physical link: same project, same settings, same power-up order, with the cable coiled nearby as the fallback.
4. Walk every screen: each numeric tag tracks the PLC value, each write does what it should, and no communication alarm appears through a full pass.
5. Leave the pair in service for at least 2 hours at the mounting spot, then close a door or start a nearby machine and watch whether updates recover on their own.
6. Compare with the baseline: same values, same alarm behaviour, and a response time you can accept with a hand on the buttons.

Judge on the screen and on the HMI's own communication status. Busy activity LEDs show bytes moving; they do not prove the HMI is reading complete replies, and a clean first minute does not establish reliable operation in a plant full of interference.

One safety rule: if any button on the screen starts or stops equipment, keep the writes out of the HMI project until the write test has passed with the machine able to act and someone watching. A read-only screen skips that step.

When should I run cable instead?

Run cable when the screen writes to the process, when update times under half a second matter, or when the radio test misses updates; an RS-485 run reaches about 1200 m at low data rates on 22 AWG, 120 ohm twisted pair.

Wire the comparison with these figures. The traditional RS-232 guideline is about 15 m at 20 kbit/s, and the limits differ by interface, as the HMI to PLC serial cable distance limits piece tabulates. RS-485 buys the long run at low speeds; the radio buys no cable at all and pays for it in delay.

Recommendation: choose the radio pair only for a screen that reads values, polls once per second or slower, and tolerates about 1.5 seconds of staleness. Keep the cable, or pull RS-485 within its 1200 m low-speed reach, for any screen with write buttons and for any case where the 2 hour radio test misses an update. Before motion depends on the link, prove writes the way the operator-panel PLC link setup requires.

What should I check before buying the radios?

Before you buy, get four answers from the radio datasheet: which electrical interface each serial port exposes, which baud rates and parity settings it accepts, whether the mode is a transparent serial line replacement in both directions, and what supply voltage the pair needs.

Then ask the seller the rest:

• Converter: if a port mismatch exists, is the level converter for it documented and available from the radio maker?
• Settings: does the baud rate range cover both equipment ports, with the data bits, parity and stop bit combinations they use?
• Network: what puts both radios on one network, and what is the documented pairing procedure?
• Power: what supply voltage does each radio need, and where does that power come from at the cabinet and at the screen?
• Placement: what range does the datasheet quote, and what walls, racking and moving machines sit between the two antennas?

If the far end only has to show values, with nobody operating through it, a shop-floor signage screen on notice-board duty is the simpler answer for the same wall. Our factory screens are built for that job, not for replacing an HMI.

Questions