Fix an HMI timeout when the PC sends but the panel stays silent

What seven bytes out tells you

RS-232 moves each character as a frame: one start bit, eight data bits and one stop bit, ten bits at the no-parity setting. The editor's initialization string is seven frames, 70 bits. Put a serial monitor on the COM port, start the connection and read the counters: seven bytes transmitted, zero received, the same on every attempt. Driver, adapter and port selection all did their jobs, because the bytes reached the wire.

What is missing is the other half of what RS-232 requires: one side's transmit line lands on the other side's receive line, over a shared signal ground, with both ends framing characters the same way. Silence after a clean transmit has three causes: the panel never received the frames, the panel received them and answered into a broken return line, or the panel is busy running its application with the port assigned elsewhere. The checks below separate those three.

Symptoms and what each points to

• Seven bytes out, zero back, every attempt. The panel side: run mode with the port assigned elsewhere, a cable that crosses transmit onto transmit, or a settings mismatch at the panel. First move: setup mode, then the cable.
• No bytes out at all. The PC side: the editor holds a different COM port than the adapter, or the driver failed. First move: read the adapter's COM number in Windows and select that number in the editor; if the editor's port list stops at COM4 and the adapter sits higher, remap the USB serial adapter's COM port.
• Windows lists no usable port. The driver or the enumeration. First move: load the adapter maker's driver; Windows 7 grabbing the wrong HMI USB driver before the editor's install is a documented pattern.
• Connects in setup mode, times out in run mode. The project's serial configuration differs from the setup baseline. First move: read the port's configuration in setup mode and set the project to match.
• Bytes come back as garbage. Both ends alive, framing mismatched. First move: match baud, parity and stop bits to what setup mode shows.
• Connects, runs, then drops after minutes or hours. A runtime fault on the machine link, a different class from a first-connection timeout. First move: HMI to PLC serial timeout checks.

Put the panel in setup mode

A panel running its application gives the serial port to the application. The editor's protocol is answered in setup mode, the maintenance screen the manual documents for transfers. On this panel family the documented entry is two touch cells pressed together after power-up: the extreme upper-left corner and the extreme lower-left corner. At least one printing of the manual drops the word left in that instruction, so aim for the corners of the screen. Your panel's manual names its own entry; use that one.

Inside setup mode, check the port's assignment. A port configured for printer duty stays silent to the programming editor, so clear that assignment, then read the serial configuration the panel reports and write it down. Those two readings, assignment and configuration, are what the PC side has to match.

Check the PC port and adapter

Read the COM number Windows gave the adapter and select the same number in the editor; editors default to COM1 or to the port used last, and the adapter can land anywhere in the list. Fix a missing port before anything else, because a dead adapter stops the whole checklist: a USB serial adapter timeout has its own driver and port checks. If the same seven-then-zero pattern repeats on a second PC, stop tuning the first one; the monitor already cleared both.

Check the cable against the documented wiring

Build or buy the cable the panel manual draws, then meter it; five minutes of continuity checks beats an hour of settings sweeps. The documented wiring for this family runs 2-2, 3-3 and 5-5, with pins 4, 6 and 8 tied together at one connector, a loop that closes the handshake lines on themselves while the editor runs with flow control off. Confirm which connector carries the tie from the manual's own drawing before you solder or jumper anything. Kill power to the link before re-pinning a connector.

Cable type carries as much weight as continuity. This family wants straight-through. A null modem swaps lines 2 and 3, so the PC's transmit lands on the panel's transmit: both sides speak, nobody hears, and the monitor shows exactly the seven-then-zero pattern. Wiring belongs to each family, so quote your own manual's table and no one else's: one documented DB9 programming cable for a different panel family runs 2-2, 3-3, 7-7 and 8-8, which grounds and ties differently from the 5-5 with the 4-6-8 loop above.

Match the settings, do not sweep them

The documented default for this family is 9600 baud, no parity, 1 stop bit, no flow control. The panel's port holds one configuration, and the setup screen is where it is readable. Set the PC to what the panel reports and stop. In this example a sweep across parity odd, even and none, several baud rates and stop-bit counts returned zero replies, and it could never have done otherwise: a sweep transmits and never listens, while the panel's configuration sat fixed, readable only on the panel. If the panel's port runs a rate the adapter cannot match, change the setting in setup mode, on the panel, and carry the change into the project. Keep speed out of it: why a faster RS-232 baud rate will not fix HMI animation makes the same point for refresh; a faster rate never answers silence.

Example: seven frames in 7.3 ms, then nothing

The scene: a panel labelled with firmware D.5, an editor moved from release 1.0 to 3.1-A with no change in the timeout, a USB-to-RS-232 adapter at the PC, a monitor on the port. Connection start, and the monitor logs 7 bytes out, 0 bytes in.

The arithmetic. At 9600 baud each 10-bit frame holds the line for 10 ÷ 9600 s = 1.04 ms. Seven frames: 7 × 1.04 ms = 7.3 ms of line time. Three connection attempts put 21 bytes on the wire, 21 × 1.04 ms ≈ 22 ms. A connection timeout is measured in seconds, so the wait, and the fault, sit entirely on the panel side of the link.

The decision rule, with the checks above done: if the connection completes in setup mode, the panel's serial hardware is cleared and the difference is configuration, so carry the setup-mode port settings into the project. If the monitor still shows seven out and zero in after setup mode, cleared port assignment, a matched COM number, a metered cable and matched settings, the panel's serial side is the fault; book it for service.

The fix, in order

1. Power the panel and enter setup mode through the corner cells.
2. In setup mode, read the port's assignment and configuration; clear printer duty from the programming port; write both down.
3. Read the adapter's COM number in Windows and select the same number in the editor.
4. Meter the cable against the manual's wiring: 2-2, 3-3, 5-5 with 4, 6 and 8 tied, straight-through, power off while you re-pin.
5. Set both ends to the panel's reported configuration; start from 9600 baud, no parity, 1 stop bit, no flow control when the panel still reports its default.
6. Start the connection and watch the monitor: the counters have to move in both directions.
7. Accept the result only when the editor reports a completed transfer; seven bytes out on its own means the job is still open.

When the editor version is the answer

Rarely. Change the editor only against the manual's compatibility table for your model and firmware, and only after the link itself is cleared: the cable comes before the software version on a version error, and the same order holds for a timeout. The release jump from 1.0 to 3.1-A in this example changed nothing, because the fault sat in mode and wiring, and no editor release re-pins a cable.

When the panel itself is at fault

If the monitor still counts seven out and zero in with all five checks passed, stop changing settings and send the panel for service with the evidence attached: the exact model and firmware from the label, D.5 in this example; the editor release, 3.1-A here; the port configuration read in setup mode; and the monitor log with the one-way counts. Keep the fault classes apart on the way out: a link that connects and later drops is a runtime fault with its own procedure. And while the panel is in service, the line's notices and targets can run on a separate screen with no machine link; that is a shop-floor signage display's job, and it leaves the HMI's link untouched.

Recommendation: Run the five checks in order, one change per attempt: setup mode, the panel's port assignment, the COM number, the metered cable, the matched settings. Clear the link in setup mode before you touch the editor version; the 1.0 to 3.1-A jump in this example fixed nothing. When all five checks pass and the monitor still shows seven bytes out and zero back, call the panel's serial side faulty and send the log with it.

Questions