Wireless HMI link for a trade show demo

What the radio changes on the link

A transparent serial radio pair is a cable replacement. It passes bytes, so baud rate, parity, data bits, stop bits and the protocol's station address must match on both radios and at both endpoints. The pair also buffers and packetizes, which adds latency and can land a packet boundary in the middle of a protocol frame. At 9600 baud, one start bit, 8 data bits, no parity and one stop bit make 10 bits per character, so a character takes 10 / 9600 = 1.04 ms. A receiver that declares end-of-frame after about 1 ms of silence will split any message the radio holds for a packet boundary. Tight inter-character timing is the first thing to fail over a serial pair.

An Ethernet bridge pair behaves like a wireless switch port. The panel and PLC keep their IP settings, both ends stay in the same subnet, and each bridge is set to bridge mode, not router mode. Example: a panel at 192.168.10.20/24 and a PLC at 192.168.10.50/24 pass through the bridge pair untouched.

Choose by port. If panel and PLC both have Ethernet, use the bridge pair and the panel's project needs no changes at all. Use a transparent serial pair on a serial link, and handle its frame splitting with the receive logic near the end of this page.

Prove the wired link first

Whatever the radios carry has to work on the cable first. A wrong port setting and a weak radio link look identical from the touch screen, and a wired baseline is what tells them apart.

1. Connect the panel to the PLC with its normal cable and confirm live values update in both directions.
2. Cycle Start and Stop from the touch screen and watch each command act before any motion runs. The write-before-motion habit in operator panel PLC link setup is exactly this check.
3. Write down what the link uses: baud rate, parity, data bits, stop bits, protocol and station address for serial; IP address, subnet mask and port for Ethernet. Take them from the CPU manual's port table, and check the serial cable distance figures by interface while you are there.
4. Open the panel's comms diagnostic and record the update time and retry count over a 10-minute wired run. On a healthy wire the retry count reads zero.
5. Leave the panel's timeout and retry settings where they are.

That diagnostic screen is the baseline. Everything the radios do gets measured against it.

Bench the radios before the hall

You need the radio pair, its antennas, the settings sheet from the wired run and the original cable. Bench the pair before you pack: radios side by side, short cables to panel and PLC, power on.

1. Match the radios to the recorded settings. A serial pair gets the recorded baud, parity, data bits and stop bits; a bridge pair gets bridge mode and passes the recorded IP settings through.
2. Confirm the radio link itself, from the status indicator or the configuration utility, before you look at any process data.
3. Re-open the panel's comms diagnostic. The update time sits a little above the wired baseline and the retry count stays at zero.
4. Walk the panel away in steps: 10 ft, 25 ft, then the farthest corner of the demo area, re-reading the retry count at each stop.
5. Run a 10-minute soak at each position and read the counter again. At the 250 ms poll interval of the example below, that soak covers 600 s / 0.25 s = 2,400 polls, and the acceptance test is a counter that has not moved. One retry in 2,400 polls is an antenna or channel question, and a filled hall makes it worse. Raise the antenna, re-scan and repeat the soak; a retry that survives both fixes marks that corner as out of range.

If the panel talks on the cable but not through the radios, the fault is in radio configuration, antenna placement or the cable to the radio, and the HMI project is fine. Change one radio setting at a time. When retries climb anyway, the checks in dropped PLC-triggered messages on a serial HMI panel are the same ones that catch a noisy serial link.

Make link loss stop the machine safely

The panel's Stop button is a convenience command over a link that can drop. The wired emergency stop stays on the machine, and the machine needs a reason of its own to stop when the link disappears. Test the wired stop with the radios powered off, before the hall opens.

Then add a heartbeat in the PLC. Let the panel write a counter value every poll, and trip a comms-fault bit when three consecutive polls go missing. At the 250 ms poll interval, three misses reach the fault bit within 750 ms, and the fault bit drives the machine's safe state: stop motion, hold the drive at zero speed, close the valve, whatever the machine's documented safe state is.

Test it twice on the bench and once in the hall:

• With the machine doing its slowest harmless motion, power off the panel-side radio. The machine reaches its safe state inside the 750 ms window.
• Restore the link. The panel recovers on its own, with no project reload.
• Press the wired emergency stop with the radios still off. It stops the machine, because it never went through the link.

Example: a 40 ft booth walk test

Scenario: the panel polls the PLC every 250 ms, each poll and each reply is 24 bytes, the serial link runs at 9600 baud with 8 data bits, no parity, one stop bit, and the booth is 40 ft deep.

On the wire:

• One character is 10 bits / 9600 bit/s = 1.04 ms.
• One 24-byte message is 24 x 1.04 ms = 25 ms.
• One poll cycle is 25 ms out and 25 ms back, so the wired diagnostic reads about 50 ms.
• A 10-minute soak covers 600 s / 0.25 s = 2,400 polls.

Through the radios on the bench, the same cycle reads 70 ms: the pair adds about 20 ms of buffering and airtime, well inside this project's 500 ms comms timeout. The acceptance test at each position of 10 ft, 25 ft and 40 ft: the retry counter still at zero after the 2,400-poll soak, and Start and Stop each acting on the first press ten times in a row.

The numbers decide the demo. At a passing position, the sales staff carry the panel anywhere inside the tested 40 ft radius. At a position where one retry appears, move the PLC-side antenna clear of the machine frame, re-scan the hall's channels and repeat the soak; a retry that survives both fixes puts the panel back on its cable stand for that corner.

Recommendation: choose the Ethernet bridge pair when both ends have Ethernet and keep the panel's IP settings untouched; use a transparent serial radio pair only on a serial link, matched setting for setting to the wired record; accept a demo position only after a 10-minute, 2,400-poll soak with zero retries at the farthest spot; keep the wired emergency stop on the machine and trip the heartbeat fault after three missed polls.

When the radio splits a frame

A transparent serial pair splits a protocol frame whenever its packet boundary lands inside a line. Framing on the newline delimiter survives that split. The worse case is a truncated line, where the radio drops bytes or the line runs past the receive buffer. The loop below holds a damaged line back whole, tail included.

/* Illustrative receive loop for a serial link behind a radio pair.
   Every name here is the example's own: port_read stands in for your
   platform's serial read, handle_line for your protocol's handler. */
char buf[16];             /* line buffer, 16 bytes                */
int  len = 0;             /* bytes held in buf                    */
bool discarding = false;  /* overflow seen; drop to the next '\n' */
char chunk[64];           /* one read from the port               */
int  n;

for (;;) {
    n = port_read(chunk, sizeof chunk);   /* n may be 0 */
    if (n == 0) continue;                 /* empty read: state holds */
    for (int i = 0; i < n; i++) {
        char b = chunk[i];
        if (b == '\n') {
            if (discarding) {             /* broken line ends here */
                discarding = false;
                len = 0;                  /* tail is not published */
            } else {
                handle_line(buf, len);    /* complete line */
                len = 0;
            }
        } else if (len == 16) {           /* buffer full, no newline yet */
            discarding = true;
            len = 0;
        } else {
            buf[len++] = b;
        }
    }
}

Feed it what a hall produces. The PLC sends a 20-byte status line, T=1200000,MODE=AUTO plus its newline, and the radio splits it after byte 16:

• Read 1 returns T=1200000,MODE=A. Sixteen bytes fill the buffer exactly.
• Read 2 returns UTO\n. The U arrives with no room left, so the loop raises the discard flag; U, T and O go nowhere; the newline clears the flag and nothing publishes. Clearing the buffer and carrying on would hand the parser UTO as a data field from a line that never completed.
• Read 3 returns 0 bytes. The empty read changes nothing and the state holds.
• Read 4 returns T=96,RUN\n. Nine bytes, a complete line, and handle_line receives T=96,RUN.

If your protocol groups several lines into one record, a discarded line leaves the parser unsure which record line comes next. Resync on the fixed header the protocol's documentation defines, a start character or a known first field, and hold every line of the current record unpublished until that header appears again. Nothing partial reaches the screen.

The receive fragment above runs as a behavioral check in tools/test_serial_article_overflow.py. That check covers the parser's behavior on this feed, and a behavioral adapter is not a CODESYS compiler or a hardware test.

What goes in the road case

• The original cable. It proves the panel and machine healthy whenever the radios misbehave, and it is the fallback stand.
• A charged panel and a charged spare battery. A dead battery mid-demo looks exactly like a lost link.
• The settings sheet from the wired run: baud, parity, data bits, stop bits, protocol and station address, or the IP settings.
• The antenna plan: PLC-side antenna clear of the machine frame and off the drive cabinets.
• The morning re-scan, done before the doors open.

Pack those five, repeat the walk test in the hall before the doors open, and the demo position you accepted is the position that works.

Questions