Connect an HMI to a PLC port with fixed serial settings

Why won't a new HMI panel talk to the PLC's fixed serial port?

Port 1's operating parameters are fixed in the CPU on this PLC family. The table below is the complete list, and no menu, parameter or programming-software page edits any of it. The new panel fails because it is set differently. The panel moves; the port cannot.

The CPU manual for this family (DL250, DL250-1 and DL260) prints the port exactly this way, which is what makes the troubleshooting one-sided: every adjustable number in the link sits in the panel project.

What each symptom points to

• Every tag read times out: the panel's serial format differs from the port's fixed values, or the panel is not set as the protocol master.
• Framing, parity or CRC errors: the panel's parity or stop-bit setting is wrong, or the cable lands voltage on a data conductor.
• The panel's driver list has no entry for this PLC: the panel cannot speak any of the port's three protocols as master, and no serial setting will change that.
• The port stays silent while every setting looks right: both ends are configured to answer, and a slave-only port needs the panel to ask.
• One panel model talks and another will not on identical numbers: the two panels carry different protocol drivers, so the numbers were never the deciding factor.

For the plain settings-mismatch case on any port, the HMI-to-PLC serial settings mismatch checklist works through the same symptoms in a shorter list.

Can I change a fixed PLC port's settings in the programming software?

No. The programming software exposes editable serial parameters for the CPU's configurable port only. The fixed port has none to display, because its format is built into the silicon.

On this line the software is DirectSOFT32, and what it edits is Port 2: the configurable port, with its own 15-pin connector and a built-in Modbus RTU or DirectNET master/slave capability. The documented DL250 second-port setup walks through that configuration. Port 1 has no settings page because there is nothing on the CPU to edit, so the search for one ends at the manual's port table. On this machine Port 2 is already committed to the servo interface, which means the panel connection has to succeed on Port 1 as it stands. Treat the manual's port table as the port's entire configuration.

Which protocol works on a PLC port that only answers as a slave?

K-sequence, DirectNet and Modbus RTU are the three protocols this port answers, each slave only. The HMI must be the master that starts every transaction. Choose the one your panel's driver list supports for this PLC; Modbus RTU is the usual fallback.

Slave only means the port waits. It never transmits first; it answers whatever request a master puts to it. The panel therefore runs its driver for one of the three protocols in the master role, and why the HMI panel must be the serial master explains those roles in detail. Half-duplex RS232C fits the pattern: the panel asks, the port answers, one side transmits at a time.

Which of the three is decided by the panel's driver list. Older panel software families carried native drivers for these PLC protocols; current releases sometimes drop them, and then Modbus RTU is the only language both ends share. Confirm the driver before purchase, before any wire is stripped, and confirm it addresses the CPU's registers the way your tags expect. The protocol selection lives in the panel project; there is nothing to enable on the PLC side of Port 1.

What serial settings do I enter in the HMI panel?

Enter 9600 baud, 8 data bits, 1 start bit, 1 stop bit and odd parity. Set the panel to act as the master and leave the physical layer at RS232C levels; on a fixed port those are the only numbers that get answered.

Enter them inside the PLC driver in the panel project, on that driver's serial page. Baud, data bits, parity, stop bits and the request role all live there, not in a generic port menu. Each character then travels as 11 bits: 1 start + 8 data + 1 parity + 1 stop. That bit count drives the traffic math in the example below.

Odd parity means the UART adds one bit to every character so the character's 1-bits total an odd number. The Modbus RTU odd parity page at the UART hardware level shows how the hardware produces it. If the panel calculates even parity or none, every byte arrives damaged and the log fills with framing errors even though the cable is perfect. There is no negotiation on a serial link: both ends hold the same numbers because someone typed them there.

Which wire goes to which pin on the fixed RJ12 port?

On the port's 6-pin RJ12 jack, pins 1 and 6 are 0 V ground, pins 2 and 5 carry +5 V, pin 3 is RXD and pin 4 is TXD. Check the cable against this list before power-up.

The two +5 V pins exist to feed the handheld programmer and the operator display the manual lists for this port. One safety note: never land a +5 V conductor on the panel's RXD or TXD. Power on a data conductor kills both ports at once and turns a settings job into a board-level repair.

At the panel end, follow the panel's own cable drawing. A molded plug that fits the jack can carry any conductor to any pin. The PLC port is DTE and most panel ports are DTE as well, so the cable crosses TXD and RXD between the two ends. Connecting a Modbus RTU HMI to a legacy PLC RS-232 port walks through a cable build of exactly this kind.

Example scenario: how much Port 1 traffic does a 20-tag screen create?

Two Modbus RTU blocks of 10 registers each take about 46 ms on the wire at 9600 baud, so a 20-tag screen refreshed every 500 ms uses roughly 92 ms per cycle, about 18 percent of the port's time.

The screen: 20 numeric values, arranged as two Modbus RTU reads of 10 holding registers each, refreshed every 500 ms.

The arithmetic, one transaction at a time:

1. Line capacity. Every character is 11 bits (1 start + 8 data + 1 parity + 1 stop), so 9600 baud / 11 bits per character = 872 characters per second.
2. Request frame. A 10-register read request is 8 bytes: 8 x 11 = 88 bits, and 88 / 9600 baud = 9.2 ms.
3. Response frame. The answer is 25 bytes (address, function, byte count, 20 data bytes, CRC): 25 x 11 = 275 bits, and 275 / 9600 baud = 28.6 ms.
4. RTU framing silence. Modbus RTU bounds each frame with a silent gap of 3.5 character times, so 7 character times per transaction = 7 x 11 = 77 bits = 8.0 ms.
5. Total. 9.2 + 28.6 + 8.0 = 45.8 ms per transaction, and two transactions per refresh = 91.6 ms of line time per 500 ms cycle: 18 percent utilization, with about 408 ms of idle line left in every cycle.

What moves the number: a 40-tag screen in four blocks doubles the line time to 183 ms, still under 37 percent. Cutting the refresh to 100 ms pushes the 20-tag case to 92 percent of the line, which leaves no room for a retry after a CRC error. The decision: at the fixed line speed, Port 1 carries the 20-tag screen on under a fifth of its time, so the port is not the bottleneck; the driver and the tag addressing are. Keep the refresh at 500 ms and split larger screens across pages.

What do I check when the panel still will not communicate?

Work down one list: protocol driver, master role, the fixed numbers, then the cable. Most stubborn cases end at the driver list, because a panel without a master driver for one of the port's three protocols cannot talk at any setting.

1. Write the port's fixed values from the CPU manual and keep the sheet at the panel; the table in the first section is the list.
2. Open the panel's driver list and confirm a driver for this PLC family, or a Modbus RTU master that reaches its registers. Replacing a legacy panel starts at the protocol, and checking the PLC serial protocol before replacing a legacy HMI gives the order of that check.
3. Set the numbers and the master role inside that driver's serial page, not in a port menu outside the driver.
4. Build a one-tag test screen: read a register whose value you set from the PLC program and compare it on screen. If the value arrives but reads absurdly large, change the tag's data format to signed decimal; setting the signed decimal data format fixes that exact symptom.
5. Verify the cable against both drawings, panel and PLC, and confirm no +5 V conductor touches a data conductor.
6. Read the panel's error log. Timeouts with the numbers confirmed point at the driver or the tag addressing; CRC and framing errors point at parity settings or the cable.

The decision splits three ways. A panel with a master driver for K-sequence, DirectNet or Modbus RTU talks to Port 1 once its serial page matches the table: set it, wire it, prove one tag, then build the rest of the screens. A panel with none of the three protocols will not connect at any setting, because the port cannot move to meet it: change the panel choice before cable is fabricated or screens are drawn. A machine whose configurable port is free is a different job: set that port to the panel's native protocol and the fixed port stops mattering.

The machine's HMI and a shop-floor notice board stay different screens. If the cell also needs a status or andon board playing its own offline content, that is the job our shop-floor displays are built for, alongside the panel that talks to the PLC.

Recommendation: Before buying any replacement panel for a fixed PLC port, open its driver list and confirm a master driver for one of the port's documented protocols. On Port 1 of this CPU family that means K-sequence, DirectNet or Modbus RTU at the fixed serial format. If the list offers none of the three, change the panel choice now, before cable is made or a single screen is drawn.

Questions