Connect an HMI serial cable to a PLC simulator

Which port on the HMI takes the PLC cable?

Connect the cable to the panel's PLC port, the one its manual labels for controller or runtime communications. The panel sends controller data out of that port only; the programming port carries project transfers and setup screens and never passes values between panel and controller.

Panels that split the two jobs put controller traffic on the PLC port alone, and that split is exactly where this fault lives. Others carry one serial port for both jobs, and then the question disappears. Read the panel manual for the layout you have, and mark the PLC port before any cable moves.

The trap is the download itself. It works through the programming port, the bench looks finished, and the runtime link was never in the circuit.

What do you need on the bench?

Gather the panel with its PLC port free, a PC that runs the simulator and its communications driver, a 6 ft null-modem cable with two 9-pin D-sub ends, a USB-to-serial adapter if the PC lacks a serial port, and the controller serial-channel manual for the port labels.

Round the bench out with these:

• The panel project already set to the controller family's serial driver, before any hardware is touched.
• The panel's hardware manual, for port labels, connector signal tables and the DTE or DCE role of each end.
• The panel's own power supply, so nothing on the bench borrows power from the PC.
• The adapter's COM number, noted once the PC assigns it, because the driver will need it.

How do you wire the serial cable, pin for pin?

At each 9-pin D-sub end, cross pin 2 to pin 3 both ways and join pin 5 to pin 5: pin 3 carries transmit and pin 2 carries receive at each DTE device, and pin 5 is the signal common both ends share.

Two DTE ends need that crossover, and on a bench both ends usually are DTE: PC serial ports and USB adapters present the DTE arrangement, and panel controller ports do the same, so the null-modem cable is the default buy. A DCE end mirrors the pins, and one DCE end in the pair calls for a straight-through cable instead. Connector gender tells you nothing about signal direction, so settle each end from its manual's signal table before crimping anything. The pin tables in an RS-232 TXD and RXD setup walkthrough for a PLC serial module show the signal directions to confirm at an unfamiliar end.

Keep the bench lead short. The RS-232 standard gives 50 ft as its guide length, and 6 ft covers any bench with room to spare; extending a serial run later is its own job, and safely extending an RS-232 HMI cable by 10 feet covers the limits that come with length.

Power the panel and the adapter down before moving the cable between ports or rewiring a connector, and buy the lead moulded: a swapped pin 2 and 3 on a hand-built crossover looks identical from outside to a correct one.

Which serial settings match on both ends?

Set DF1 full duplex at 9600 baud, 8 data bits, no parity and 1 stop bit on both ends, with the same station number, because those are the defaults a serial full-duplex DF1 channel prints in the controller manuals and one mismatched value stops every reply.

The panel's values live on its driver or communications page in the project, and the channel's values live in the simulator project's serial-channel configuration; open both and read them side by side. A silent link from a settings fault looks identical on screen to one caused by wiring, which is why the checks section tests the layers in order.

The protocol matches too. If the panel's driver list offers DH-485 and not DF1, serve DH-485 from the PC communications package and drop DF1. The same matching discipline carries into the real install, where a PC HMI speaks the PLC's serial protocol or moves to Ethernet under the same rule.

How does the HMI reach a simulator running on the PC?

The simulator runs the ladder and holds the data table but has no serial line of its own. A communications driver from the simulator's software family opens the PC's COM port, speaks the panel's protocol and serves it values from the simulator's data table.

That bridge is the piece engineers miss while the simulator runs and the panel still faults. The simulator family was built with serial port emulation so an HMI could talk to it, and the middleman is the communications driver from the same software family, sold as a small single-node or OPC package. The whole chain runs: panel PLC port, null-modem cable, adapter, COM port, driver, simulator data table. A write from the panel lands in the simulator's table, and a read comes back out of it.

Two housekeeping rules keep the chain up. The simulator serves one ladder program at a time, so close every other project window before the panel connects. And the driver must bind to the COM number the adapter actually took; if the driver insists on a fixed low number the adapter cannot use, remap the USB serial adapter's COM port once and the binding holds.

What are the steps, in order?

Work in one pass: identify the ports, wire the crossover, match the settings, load a single ladder, start the PC driver, power the panel, and only then test a read and a write against a register you chose for the test.

1. Mark the panel's PLC port from its manual and connect the null-modem cable there, panel end first, with power off.
2. Connect the other end to the PC serial port or the USB adapter and note the COM number the PC gives it.
3. In the panel project, select the controller family's serial driver, set DF1 full duplex at 9600 baud, 8 data bits, no parity, 1 stop bit and station 1, and point the driver at the panel's PLC port.
4. Load the ladder into the simulator and close every other project window so exactly one program is open.
5. Start the PC communications driver bound to that COM number and leave its status window open.
6. Power the panel, start its runtime screen and open the screen that shows the communication status.
7. Read the test register on the panel.
8. Write a chosen value from the panel, confirm it in the simulator's data table, then restart the panel runtime and the driver and pass the read once more.

What does a worked example look like end to end?

This bench example uses a 9-pin DTE panel port, a 6 ft null-modem cable, a USB adapter on COM3, DF1 full duplex at 9600 baud with 8 data bits, no parity, 1 stop bit and station 1 at both ends, and the integer address N7:0 as the test register.

Work the numbers before the first connection. Length is off the suspect list, since 6 ft sits far inside the 50 ft the RS-232 standard gives as its guide. The line budget settles the baud question: a poll of 20 bytes and a reply of 30 bytes move 50 bytes per exchange. At 8 data bits plus a start and a stop bit, each byte takes 10 bits, so one exchange moves 50 × 10 = 500 bits. At 9600 bit/s that is 500 ÷ 9600 ≈ 0.052 s, about 52 ms of line time. With the example project polling every 250 ms, the line sits at 52 ÷ 250 ≈ 21 percent busy, so the 9600 baud default carries the bench traffic with room to spare and nothing faster is needed.

On this bench the panel's status reads active within a second or two of the runtime starting, N7:0 shows the value the ladder left in it, a write of 1234 from the panel shows 1234 in the simulator's data table, and after a restart of both ends the read passes again. The write is the moment that earns trust: on the bench it can touch only the simulator's table, which is the point of testing before the real controller arrives.

How do you check the link is actually working?

The link is working when the panel's communication status reads active, a register whose address matches the ladder displays on the panel, a write from the panel changes that register in the simulator, and the sequence passes again after a restart of the panel runtime and the PC driver.

Run the sequence in that order and let it fail in order too. A general communication alarm points at the physical and configuration layers first: port, cable, serial parameters, driver status. A link that reads active but shows a wrong or frozen value points at the tag: its address or data type against the simulator's actual data table. Rewrite tags only after the status reads active, because a link fault hides behind edited tags and both problems stay alive.

Why does the panel still show a communication fault?

Work five causes in order, each with a one-minute test: the cable on the programming port, TXD and RXD not crossed, one mismatched serial parameter, the PC driver stopped or bound to another COM number, and a tag whose address or data type differs from the simulator's data table.

1. Cable on the programming port. Compare the connector the cable occupies with the manual's port labels and move it to the PLC port; a successful download through the other port hides this one completely.
2. TXD and RXD not crossed. Power down, then meter the lead: pin 3 at one end must beep to pin 2 at the other, and pin 5 must beep straight through. If pin 3 beeps to pin 3, swap in a null-modem cable.
3. One parameter off. Read baud, data bits, parity, stop bits and station from both screens side by side. A single difference stops every reply, so set both ends to the values the manuals print.
4. Driver stopped or bound elsewhere. Check the driver's status window and the adapter's COM number in the PC's device list; start the driver, or remap the adapter if the software insists on another number, and confirm one ladder window is open in the simulator.
5. Tag fault, not a link fault. If status reads active and one value freezes or reads nonsense, open the ladder, compare that tag's address and data type with the data table, and correct that tag alone.

A status light that never comes on at all is the dead-port case, and HMI to PLC serial timeout with a dead com light walks that symptom on its own.

Recommendation: For a one-panel bench test, buy a moulded 6 ft null-modem cable with two 9-pin D-sub ends instead of building one, put it on the panel's PLC port, set DF1 full duplex at 9600 baud, 8 data bits, no parity, 1 stop bit and station 1 at both ends, and keep the simulator to one open ladder. Move the panel to the real controller's channel settings only after the read and the write pass once more following a restart.

None of this bench needs a signage display, and the panel under test stays the machine's interface. When the cell itself needs a separate notice or status screen that plays its own offline content, our panel-mount shop-floor screens are built for that job; on a wall or behind a cabinet they run from a low-voltage DC feed, and a DIN-rail 24 V DC supply suits the hidden location.

Questions