Put a serial PLC on Ethernet with a serial converter

What the converter does, and what it leaves alone

The converter has a serial side, RS-232 on most models and RS-485 on some, and an Ethernet side. The PLC still sees a serial device and runs the same program; the network sees a TCP endpoint a laptop or a panel can address. The protocol the two ends speak passes through untouched, which is why a driver that works over a cable usually works through the bridge.

Place the hardware with both cable limits in mind. The TIA-232 standard allows about 15 m of serial cable at the full rate, so past that distance the converter belongs close to the PLC and the Ethernet side carries the length; a structured twisted-pair run is good for 100 m end to end per TIA-568. Where the port is RS-485, the usual planning figure is about 1200 m at low rates such as 9600 baud.

What the converter never adds: routing between subnets, firewall rules, encryption or access control. A converter by itself gives no security, so anyone who can reach its TCP port can reach the PLC serial port. That gap is why the bench test comes first and the network work comes second.

What you need

• The PLC and its manual page for the serial port: baud rate, data bits, parity, stop bits, and whether the side is RS-232 or RS-485.
• A converter whose documentation covers that serial side and states how its serial settings, IP address and TCP port number are set.
• The serial cable both manuals call for; ports divide into DTE and DCE ends, so the documents decide whether the cable is straight or crossed.
• A small Ethernet switch and two patch cables.
• A laptop with the PLC programming software, or the HMI panel loaded with a driver for the PLC protocol.
• One spare register in the PLC, reserved for the test write.
• Power for the converter, as its own documentation describes.

Match the converter to the PLC serial settings

Open the PLC serial port configuration and write the numbers down before anything is unplugged. A common general-purpose port ships at 9600 baud, 8 data bits, no parity and 1 stop bit, but your port carries whatever the screen says. Set the converter serial side to those same four values. The PLC stays untouched; the converter is the only device you configure.

Two situations deserve a note. One common small PLC family reserves a port for its own operator panels and runs it at a fixed 38400 baud; if the panel must use that port, 38400 is what the converter gets and the choice is already made. And if nobody can say what protocol the port speaks, checking the PLC serial protocol first settles that before any converter is bought.

When a client later reports it cannot find the baud rate or parity, the mismatch is almost always sitting on this serial side. Fixing a serial driver that cannot find the baud rate and parity walks that exact error down to the setting that caused it.

The bench sequence

Run all of this on a bench switch, with no router, no office network and no internet path attached.

1. Write down the PLC serial settings from its port configuration screen and leave them untouched.
2. Set the converter serial side to the same baud rate, data bits, parity and stop bits.
3. Give the converter a fixed IP address on the bench subnet and set its TCP port number the way its documentation directs; write both down.
4. Point the client, the programming software or the panel driver, at the converter IP address and TCP port number.
5. Prove a read: open a register whose value you already know from the PLC's own screen and confirm the client shows the same number.
6. Prove a controlled test write: send a harmless value such as 1234 to the spare register, then read it back and confirm it matches. If anything on the bench moves, read the operator panel setup that tests writes before motion before you write anything.
7. Power-cycle the converter and repeat the read; the settings must hold and the register must read again.
8. Unplug the converter network cable and confirm the client reports a timeout instead of stale values, then reconnect and read once more.

Example: a 9600 baud bench with a 1 second timeout

Take the common default as the worked case. The PLC port runs 9600 baud, 8 data bits, no parity, 1 stop bit. The laptop sits at 192.168.1.10 and the converter at 192.168.1.50, both under the netmask 255.255.255.0, so they share one subnet and the bench switch carries every packet.

At 8 data bits plus one start and one stop bit, every byte takes 10 bits, so 9600 baud moves 960 bytes per second. A read request of 12 bytes takes 12 ÷ 960 = 12.5 ms to leave the laptop; a 24-byte answer takes 24 ÷ 960 = 25 ms. Add a few milliseconds inside the converter and a full exchange lands under 50 ms. Set the client timeout to 1 s, about 20 times a healthy exchange: a good poll never trips it and a dead link announces itself within a second.

The test write sends 1234 to the spare register and reads 1234 back. That completes the proof: read and write both work across the converter on a local subnet, and no router has been involved.

How you know the bridge is ready

The bridge is done when all of these hold:

• The known register reads the same through the converter as it did over the bench cable.
• The test write lands and stays: the spare register holds 1234 on the PLC's own screen after the read-back.
• An exchange completes in tens of milliseconds at 9600 baud, in line with the example's arithmetic.
• The converter's settings and the register value both survive a power cycle.
• No network cable means a timeout inside the 1 s limit, never stale numbers.

If the tunnel carries Modbus TCP, apply the same discipline on the protocol side; testing a Modbus TCP gateway before you trust the data pairs with this bench work. Whatever the protocol, give the application a timeout and a defined communications-failure behavior before any value it shows is trusted for operation.

Routed access and the internet are a separate job

After the bench proof, the remaining questions belong to the network owner: subnets, routes, firewall rules and who may connect. The converter does none of that work, and a straight port forward from the internet to the converter hands the PLC serial port to the whole world, so that path stays closed.

The order that works: keep the converter and the PLC on their own subnet or VLAN, allow only the clients that need them, and reach that subnet through the site's managed remote-access path, normally a VPN. Test the path one hop at a time; the port forwarding test sequence splits it into steps that either pass or name their failure. Routing around a serial bridge has quirks of its own, and a serial-to-Ethernet routing fix documents one case where the cure was the direction the connection is made in. If a remote client talks but the panel times out, suspect the single-client limit described in the FAQ below.

Make it permanent and keep a way back in

For the cabinet build, put the whole chain in the panel binder: PLC serial settings, converter serial settings, converter IP address and TCP port number, client timeout. Power the converter from the cabinet supply the way the PLC manual shows; cabinet controls commonly run from a fused DIN-rail 24 V DC feed on a switched breaker, so a lockout takes the bridge down with the rest of the panel. Keep the bench cable and a spare converter on the shelf: if a network fault ever blocks the path, a temporary local connection restores maintenance access in minutes.

One screen may still be missing when the trainer becomes a working cell. A line-side board for shift targets, safety messages and quality results is a separate display loaded with posted content from a memory card, and our shop-floor screens are built for that job; they are not part of this PLC link.

The decision

So the decision, case by case. On a bench or trainer: the serial-to-Ethernet converter is the right piece, configured to match the PLC and released only after a read and a controlled test write pass on the local switch. Across a routed network or the internet: the same converter still carries the transport, and it goes live only behind the site's managed access path, with the bench proof on record first.

Recommendation: leave every PLC serial setting unchanged, set the converter to match them, and treat a read plus a controlled test write on a local switch as the release gate for any serial-to-Ethernet install; open routed or internet access only after that gate, through the site's managed VPN, never as a public port forward.

Questions