Why an HMI gets no data from an Ethernet base controller serial port

Why is there no communication when the serial settings match?

Both ports agreeing on 9600 baud, 8 data bits and odd parity only settles the wire format. An Ethernet base controller has no controller data table behind that serial port, so there is nothing inside it able to answer a single read request from the panel.

K-Sequence is a controller serial protocol: the master, here the HMI panel, sends read and write requests addressed into controller memory, and the slave answers from that memory. The base controller's serial port sits on the slave side, but its job is to ferry I/O between its local I/O base and the remote master on the plant network. It runs no program and keeps no register file, so the memory the panel's requests are addressed to does not exist. A protocol label describes how the port talks. Whatever sits behind the port decides whether there is anything to say.

What do my symptoms point to?

Each symptom has its own meaning: matching settings with zero replies points at the endpoint's role, an auto-detected link that names a controller model points at the driver database, and a plan to unplug the remote link points at lost I/O rather than a working HMI endpoint.

• Settings match, protocol matches, zero replies. The serial endpoint has no data to serve. That is the base controller case this article fixes.
• Auto-detect proposes a protocol and a controller model. The programming software matched the nearest entry in its driver database. It is a proposal from a list, not a discovery about the hardware.
• Someone suggests unplugging the base controller from the remote master to test locally. That removes the remote I/O from the controlling system and still leaves no HMI data endpoint, so the plant loses visibility of its own I/O and you gain nothing.
• A link comes up but addresses read zero or error out. The panel objects were mapped from a guessed model or an old project instead of the running controller project.

What is the K-Sequence serial port on the base controller for?

Service work and special drivers: the port runs as a slave at 9600 baud, 8 data bits, 1 stop bit, odd parity, and its documented uses are firmware maintenance and, in one PC-based control package, a driver that lets that package serve an HMI panel.

Slave mode means the port only answers; it never initiates. The vendor's serial communications documentation describes the K-Sequence controller port as slave-only RS-232C, fixed at 9600 baud, 8 data bits, 1 start bit, 1 stop bit, odd parity, which matches the numbers you set. The panel's K-Sequence driver documentation lists the controller families it supports, the DL05, DL06, DL105, DL205, DL350 and DL405 lines, and a remote I/O base controller appears on no such list. If your control software is not that PC package, expect nothing from this port. Treat even the documented driver case as a feature of that exact software combination, to be confirmed in its manual before anyone wires it.

Why did my programming software propose K-Sequence and a DL240?

Its auto-detect scanned its own driver database for the closest known device and proposed a K-Sequence link to a DL240, which is a database answer about what could exist, not a measurement of what is connected to the port.

DL240-class controllers do speak K-Sequence on their serial ports, so the pairing exists in the database, and the auto-detect had nothing else to work with: a port in slave mode offers a protocol label and silence. Treat the auto-created link as a starting point for the controller it was made for, and as noise here. The useful check is on the panel side, because what the panel can actually talk to is printed in its driver documentation; that is the point of checking the panel driver list before tuning serial settings.

How do I check the cable before changing anything?

Put numbers on the wire: a healthy EIA-232 driver idles near -3 to -15 V, and a 20-byte request at 9600 baud occupies 220 bits, about 23 ms, so a quiet, correctly wired line with no reply means the endpoint cannot answer.

1. Confirm the settings character for character on both ends: 9600 baud, 8 data bits, odd parity, 1 stop bit. Odd parity means the UART appends a bit to each character so the finished character carries an odd number of 1s, and both ends must compute it the same way; there is a short page on how odd parity is configured at the UART if you want the hardware detail. With 1 start, 8 data, 1 parity and 1 stop, every character takes 11 bits, so the line moves 9600 / 11 = about 872 characters per second.
2. Meter the DE-9 pins while the panel polls. On a DTE-style port, pin 3 carries transmit, pin 2 receive and pin 5 signal ground, the arrangement defined by the DE-9 standard (TIA-574). A working driver idles at around -5 to -12 V on its transmit pin; 0 V points to the wrong pin, a dead driver or an unpowered panel.
3. Swap pins 2 and 3 with a null modem adapter if step 2 shows nothing, because straight and crossover confusion is the most common wiring fault on EIA-232.
4. Check that requests actually leave. A 20-byte poll every 250 ms is 220 bits × 4 = 880 bits per second of offered load, about 9 percent of the 9600 bit/s line, so congestion is ruled out. Bursts leaving and no bytes returning means the endpoint cannot answer.
5. If any one of the three settings differs between the ends, fix that first; the case where the settings genuinely disagree is a different fault, covered in HMI panel not talking to the PLC: serial settings mismatch.

What does a worked example of the fix look like?

The panel comes up the moment it faces an endpoint that owns the data. In the example below that takes one cable move, 32 inputs and 16 outputs mapped from the controller project, and one test output checked in a maintenance window.

Scenario: a packaging line runs from a rack-mounted controller. An Ethernet remote master module in that rack owns one remote base across the plant floor, and the base carries an Ethernet base controller head with 32 input points and 16 output points. The maintenance tech wants a small HMI panel at the base for local checks.

1. The panel is set to K-Sequence at 9600 baud, 8 data bits, odd parity; the base controller port already runs as a slave at the same numbers. After a 1 s timeout the panel reports no communication.
2. The wire checks pass. Idle voltage on the panel's transmit pin reads -7.8 V, inside the -3 to -15 V mark range, so the driver is alive. A null modem swap changes nothing. Each 20-byte poll takes 220 bits, and 220 / 9600 = 23 ms of line time; the panel's diagnostics show the bursts leaving every 250 ms with no return bytes.
3. Conclusion at this point: settings and cable have passed every check, and the endpoint has no data to serve. A clean wire only clears the wiring; it says nothing about the endpoint behind it.
4. The tech moves the panel cable to the controller's own serial port, keeps the same K-Sequence driver at the same settings, and the link comes up on the first poll.
5. All 32 inputs and 16 outputs are mapped from the controller project's I/O map. A colleague toggles a field switch; the panel, the controller's live data table and the physical switch all show the same state.
6. In an approved maintenance window the tech commands one test output: the controller bit changes and the physical point on the remote base switches. The remote I/O network was never opened during the work.

Same panel, same driver, same settings, different endpoint: the only change that mattered was who owns the data.

How do I verify reads and writes without risking production?

Verify reads on live inputs first and do the first write in maintenance mode on one test output: compare the panel value with the controller value while someone toggles the field device, then command the test output and confirm the controller bit and the physical point both change.

1. Start read-only. Put a raw input value on the panel beside a status text from the controller, have someone actuate the field device through its normal range, and compare all three: panel value, controller live value, physical device.
2. Do the first write in an approved maintenance condition, with the machine state known and the equipment safe to jog. Command one designated test output and check two things: the controller data changed, and the correct physical point responded.
3. If the controller value changes but the physical point does not, work downstream of the panel link in order: object address, remote base, output module, interlock. The panel link has already passed its checks at that stage.
4. Restore normal mode, delete the temporary test object, and leave write access off the panel until every object you intend to expose passes the same two checks.

One safety rule carries the whole procedure: verify every read with the machine running normally, and verify every write with the machine in a controlled maintenance state.

Two details from the controller side matter here. An HMI write goes to a controller data address, and a panel toggle cannot force a physical input, which is the whole subject of why an HMI toggle cannot force a PLC physical input. For building the objects themselves on real bits, wire an HMI button and indicator to PLC bits walks the mapping end to end.

When is a direct connection to the base controller port actually supported?

Only when the control system that owns the remote I/O documents a driver for it: one PC-based control package ships such a driver and also uses the port for firmware service, so check your control software's manual and the panel driver's supported-device list before anyone wires it.

The documentation has to show three things together: your control software, a driver for your exact HMI panel, and that base controller serial port as the endpoint. If your system has no controller or runtime that can serve the panel, stop cycling baud rates and protocol names, collect the hardware and firmware details, and ask the vendor whether the exact combination you own is supported. If it is supported, use it exactly as the manual describes; if it is not, the port has no data endpoint, and no setting will create one.

If the line also needs a status or andon-style board next to the machine, that is a separate screen job, not a second use for this port. Our factory screens are the shop-floor boards to start from, and the factory screens category shows the range; factory data table signage for offline screen content covers how controller data becomes content on an offline board.

Recommendation: connect the HMI panel to the controller or PC runtime that owns the remote I/O, use that system's documented driver and its project's address map, and leave the base controller's serial port for firmware service. Verify reads against live inputs with the line running, verify writes on one test output in a maintenance window, and only then expose real output controls to the panel.

Questions