Programming an HMI panel over an Ethernet serial server

Why does the panel program over a cable but not through the serial server?

Because the server route adds three parts the direct link never had: a virtual COM port your software must open, a serial port on the server with its own framing and flow control, and network latency in both directions.

Any one of them can break a session the defaults ran fine. The direct test cleared the panel, its cable and the software together, so those parts are good; the server was never part of that test. Commission the remote route as a new link, from the PC outward: first the port the software opens, then the serial values on the server, then timing. Indicator lights on the server report power and Ethernet link state; they say nothing about whether this panel's download protocol is passing. A server that already serves other serial devices has demonstrated its network half, and nothing more. The parts of a PC-to-panel serial link and where each sits are laid out in connecting a PC HMI to a PLC over serial or Ethernet; what follows covers only what the server changes.

Which symptom points to which part of the chain?

Read the failure location before you touch a setting. The port the software refuses to open points at the PC side. A dead link light points at the network. A session that opens but never completes points at framing, flow control or timing.

Match what you see to one of these:

• The virtual port is missing from the software's list, or the software errors the moment it opens it. The driver did not load, the port moved, or another application holds it. Stay on the PC until the port opens cleanly.
• The port opens but the server's serial-side indicator stays dark during the attempt. The network half works and the server is not putting bytes on its serial line. Check the serial cable at the server end and the panel end before any serial setting.
• Both ends blink but the handshake never finishes. Framing or flow control mismatch, or a timing limit. Go to the settings comparison and the worked example below.
• The com light stays dead from the first byte. That pattern and the order to check it in are laid out in HMI to PLC serial timeout with a dead com light.
• The route worked last month and fails today. Recheck the COM number first. Drivers land on a new number after updates and re-enumeration.

How do you make the direct cable session the baseline?

Run one complete download with the cable straight from the PC to the panel, at the settings that already worked, and write down what the software used.

That session is the reference every later test compares against. If it fails, stop there: the fault is in the cable, the panel's port or the software's selection, and no server setting will fix it. Re-seat the cable at both ends, confirm the panel's port is set to its programming function, and run it again. Some panels expose the port's function, programming or printer, on a setup screen built into the panel itself; open it the way the panel's manual documents, because a touchscreen shortcut that opens it on one model does nothing on the next. Once the baseline passes, change one thing at a time for the rest of the job.

Which COM port does the programming software have to open?

Open the COM number the server's driver has assigned today and select exactly that number in the software. The assignment moves when the PC re-enumerates USB or the driver reinstalls.

The virtual COM port is a PC-side endpoint the server's driver utility creates, and the number it carries, COM3 in many installations, belongs to the PC alone. The panel neither knows nor cares what the PC calls the port. Windows Device Manager, under Ports, lists the number currently assigned. Close anything else that could hold the port while the software connects, because a virtual port usually allows a single open. The same utility also asks how the PC reaches the server on the network. In the common arrangement the PC side runs as a TCP client pointed at the server's IP address and port number, so note both while you are there.

If the software only offers COM1 to COM4 and the driver landed above that, the port will never appear no matter what the server does. Remapping a USB serial adapter COM port walks through that fix. If the virtual port is missing entirely, sort out the driver before touching a single serial value on the server.

What serial settings have to match between the server and the panel?

Baud rate, data bits, parity, stop bits and flow control must agree at every serial hop in the chain. The values to copy are the ones the working direct session used, not a default you assume.

Manuals compress those five values into a shorthand such as 9600 8N1, which stands for 9600 bits per second, 8 data bits, no parity and 1 stop bit; your device's serial settings reference spells the notation out. Serial ports designed to connect to a PC have settled on that combination as the common default, which is exactly why it is the first thing people guess. A programming port can just as easily run a different combination. A guess that fails looks identical to the fault you started with, so read the values.

Find them in this order:

1. The programming software's connection dialog or its documentation, which prints the serial values it uses on the PC side. The server's port must match those.
2. The panel manual's specification for the download port.
3. The panel's own setup screen, where some models show the port's mode and its serial values.
4. The panel vendor's technical support, which can give the exact parameters for your model and firmware version.

Flow control deserves its own check, because it is the value most often left at a factory default that does not match. A port set to hardware handshaking on a link wired without the handshake lines stalls. A port set to none on a panel that expects it can overrun. Set the server's serial port to whatever the panel port uses, and set the software side the same.

Worked example: how long does a 256 KB project take to download at 9600 baud?

About 4 minutes 33 seconds with no protocol overhead: 262,144 bytes at 960 bytes per second is 273 seconds, and the real download runs longer once handshake bytes and retries join in, which is why timing breaks a server route first.

Here is the arithmetic. At 9600 8N1 the line carries one start bit, 8 data bits and 1 stop bit for every byte, 10 bits per byte, so 9600 ÷ 10 = 960 bytes per second. A 256 KB project is 256 × 1024 = 262,144 bytes, and 262,144 ÷ 960 = 273 seconds, which is 4 minutes 33 seconds. Change the framing to 9600 8E1 and every byte takes 11 bits: 9600 ÷ 11 = 873 bytes per second, and 262,144 ÷ 873 is about 300 seconds, 5 minutes even, for the same file.

Now add what the arithmetic leaves out. Assume a quarter of the elapsed time goes to block acknowledgements and waits: 273 × 1.25 is about 341 seconds, 5 minutes 41 seconds. A route that stalls and retries once doubles it to about 682 seconds, 11 minutes 22 seconds.

The decision this produces: if the software exposes a connection timeout, set it above the longest download the panel will take on this route, about 15 minutes for this example, a third above the worst case computed here and well above what the direct cable needed. If the software hides its timeout, cut latency instead. Put the PC and the server on the same switch, keep Wi-Fi out of the path, and leave the network quiet during the download. The related failure, a programming job that times out because an adapter adds delay, is covered in fixing a USB serial adapter timeout when programming a text panel.

How do you commission the server route one change at a time?

Bring the route up in four tests, PC to server, server to cable, cable to panel, then the whole session. Change one setting between tests so every pass or fail names the part you just touched.

1. Confirm the server is online and the software opens its virtual port. Port open with the serial-side indicator dark means the network half is done; move to the cable.
2. Seat the programming cable at both ends, server and panel, and confirm it is the same cable the direct session used, including any crossover or gender adapter it needed. A server's 9-pin port and a PC's COM port are not always wired the same, so if the indicator stays dark with a cable that just passed the direct test, try one straight-through and then one null-modem adapter.
3. Enter the recorded serial values on the server's port: baud rate, data bits, parity, stop bits and flow control. Save the configuration in the server's own management interface so it holds through a power cut.
4. Run the software against the panel with nothing else changed, and watch the serial-side indicator during the attempt. Dark means bytes are not leaving the server. Blinking with a stalled handshake means the panel is receiving bytes it cannot use, which points back to framing, flow control or timing.
5. If the route still fails, go back to the direct cable, confirm the baseline still passes, and repeat the steps after changing one item. Some software exposes a connection timeout you can raise; adjust only a control its documentation names, and only after the serial path passes.

What do you record so the route survives the next boot?

Write down five things when the download completes: the COM number in use, the server's IP address and port, the serial values on the server, the panel port's mode, and the software version that worked. A power cycle can move the first, an update the rest.

A server that boots to factory defaults passes one session and fails the next day. Keep the cable route alive as well. It is the recovery path for a panel sitting in an unknown port mode, or a plant network that is down, and it takes two minutes to reconfirm the baseline before you debug the server route.

A programming link and a notice board are different jobs. If the cabinet or the line also needs a screen that shows shift targets, counts or safety notices on its own, that is what our shop-floor screens are for, with offline playback and no subscription; they do not stand in for the panel or its programming port.

Recommendation: commission the Ethernet serial server route until it passes a full download, keep the direct cable as the standing recovery path, and if the software hides its timeout and the route stalls mid-download, finish the job on the cable, then cut latency on the server route before the next attempt rather than adjusting any setting you cannot name.

Questions