Connect a PC HMI to a PLC over a serial protocol or Ethernet

Two documented paths, and what each is for

DirectNET is a master/slave protocol: the master initiates every read and write, the slaves answer, and the protocol is sized for up to 90 stations on one network. It runs on RS-232 for a point-to-point link and on RS-422 when you need distance or extra stations. On these small brick PLCs the built-in serial ports carry the maker's programming protocol, K-sequence, DirectNET and Modbus RTU, so the port you already program through is the port the HMI can poll. The frame layout is documented in the PLC manual's communications chapter.

The Ethernet route is a different animal: an Ethernet option module with its own software development kit. Your program calls the kit's documented functions, and an Ethernet jack on the panel becomes a working link only once the module is identified and its kit is doing the talking. Write the PC side of that link as an interface with defined requests and replies; the same design exercise for parameter reads over Ethernet spells out the pattern.

The 15 m figure is the RS-232 standard's own planning limit. The 1,200 m figure is the RS-422 guide at its reference speed of 100 kbit/s.

What you need

• The PLC's full model number and its manual set, above all the communications chapter that documents DirectNET or the Ethernet kit.
• A serial port on the PC, or a USB-to-RS-232 adapter, plus the cable built to the manual's wiring page. These PLCs expose their serial ports as 6-pin RS-232 jacks, so the pin functions come from the manual's drawing.
• For the Ethernet path, the module's part number and its development kit for your PC language.
• One noncritical register from the PLC program, watched live in the programming software. A timer accumulator or a parts count works well.
• Room in your code for a log line per request: timestamp, request, reply or timeout.

Prove the link with a read-only poll

1. Configure the PLC port as a DirectNET slave. Set the station address and start the baud at 9,600; the protocol's ceiling is 38,400 baud, and you move up only after the link runs clean.
2. Match the PC side to the same baud and to the data bits, parity and stop bits the manual's frame description assumes.
3. Write the smallest read your program will ever make: one request for that one register. No writes anywhere in the code yet.
4. Send the request and compare the reply with the live value in the programming software, byte for byte and in the right data format. If the raw bytes arrive and the number still looks wrong, check whether the register is stored as BCD or binary before changing anything else.
5. Change the value from the PLC side, for example by letting the timer run, and watch it move in both places inside one poll interval.
6. Let the poll run across a full machine cycle with the log recording every request and reply.

How to check it worked

• The polled value tracks the programming software's live value through power-up, running and stop.
• Pull the cable mid-cycle: the log shows timeouts, and the HMI you build later must show that state as stale or offline, never as a frozen number.
• The log at the end of the cycle shows zero timeouts.

Scenario: six screen values, refreshed once per second

A woodworking cell's PC HMI displays six PLC values, a feed position, a parts count, a timer and three status words, all refreshed once per second over DirectNET on RS-232 at 9,600 baud.

The planning arithmetic uses one illustrative assumption: a single-register read takes about 20 bytes on the wire, request and reply together. Take the exact frame length from the protocol manual; the point of the figure is the method. At 8 data bits, no parity and 1 stop bit, each byte occupies 10 bits on the wire, so one poll takes about 20 x 10 = 200 bits. At 9,600 baud, one poll takes 200 / 9,600 = about 21 ms.

Polling all six values once per second takes 6 x 21 ms = 126 ms out of every second, about 13% of the line: plenty of headroom for a second PC or a logging task on the same network. Now raise the demand to ten refreshes per second on all six values: 60 polls x 21 ms = 1,260 ms, and the second runs out before the last poll. Move the link to the 38,400-baud ceiling and the same poll takes 200 / 38,400 = 5.2 ms, so 60 polls take 312 ms, about 31% of the line, and the screen rate fits with room to spare.

The decision comes out of your own log: if the measured time per poll, times the polls you need per second, exceeds one second, slow the refresh, poll fewer values, or move to the top baud rate.

If the first poll fails

Check in this order:

• No reply at all. Wiring and settings first. The 6-pin jacks make a crossed cable easy to build, so go back to the manual's wiring page, confirm baud and format on both ends, and compare your symptom against the pattern in a serial timeout with the com light still out.
• A reply arrives, the number is nonsense. That is data format. Check whether the register is BCD or binary; the BCD data type that turns a live PLC register into nonsense numbers shows what the mismatch looks like.
• Clean at the bench, intermittent in the shop. Noise or length. Measure the run against the 15 m planning limit, reroute the cable away from motor leads, and compare with the behaviour behind dropped messages between a PLC and a serial panel.
• You chose Modbus RTU on the same port. The proof steps are identical. A link that connects and then returns no valid polls has its own known pattern, described in a Modbus driver that connects but will not poll.

Keep servo drive control on its own link

Your architecture has the PLC sequencing the machine and the PC commanding the servo drives. Treat those as two interfaces. The DirectNET link carries display values and operator requests between PC and PLC; the drives take their commands over their own drive interface, commissioned under the machine's own procedure.

Map every command to an owner before you write it: which PC actions are requests the PLC grants in its own sequence, which are direct drive commands, and how the PLC learns that a command finished or failed. Then verify what the drive actually did, because a drive can settle at an output frequency different from the reference you sent, a gap worth checking before any command is trusted, as described in why a drive's output frequency can differ from its reference command.

Safety: run the first PC-driven servo moves with the tooling clear of material and the machine's stop chain independent of the PC link, so a stuttering communications test stays incapable of producing motion.

The decision

• PC beside the panel, one PC, display values refreshed about once per second: DirectNET over RS-232 at 9,600 baud, with the scenario's arithmetic deciding when to move up. Prove it with the one-register read-only poll, then build screens.
• Long runs or more stations: the same protocol on RS-422 at its guide distance, one master, your PC, over the whole multidrop network.
• Distance beyond serial, throughput above the serial ceiling, or an existing plant network: the Ethernet module's development kit, used exactly as its documentation describes.
• Servo drives: their own commissioned interface, never the HMI link, with the PLC staying the machine's sequencing and safety authority.

Recommendation: Build the serial DirectNET link first whenever the PC sits within the RS-232 planning limit, prove it with a single read-only poll of a known register across one full machine cycle, and move to the top baud rate or the Ethernet module's kit only when the poll arithmetic or the distance demands it. Leave servo drive control to its own commissioned interface.

Questions