What a serial to ethernet converter actually does, and where it stops

Green link light, clean ping, and a controller that has never seen a single byte out of the thing. A serial to ethernet converter sitting in that state is usually not broken. It is doing exactly what it was built to do, which is less than most people assume when they order one.

A serial to ethernet converter moves bytes. It does not know what those bytes mean, and it will not hand your PLC a tag it can read. Here is what happens inside one, and how to tell when the thing you need is a protocol gateway.

Serial is not a protocol

Calling serial a protocol causes more wrong purchase orders than any wiring mistake I have run into. RS-232, RS-422 and RS-485 are electrical specifications. They describe how bits get down the wire, and say nothing about what the bits mean.

Modbus RTU is a protocol. So is Modbus ASCII, and so is whatever proprietary string a weigh indicator throws out at 9600 baud when somebody hits print. Those ride on top of the electrical layer, and a serial to ethernet converter does not care which of them is on the wire.

Ethernet is serial too, if serial just means bits going down a wire one after another. What people mean by "serial" is closer to "old point-to-point copper, not networked."

A serial to ethernet converter lives on the electrical layer and nowhere above it. It reframes whatever the UART receives into TCP packets and puts those on the network. Something at the other end has to unwrap them and hand the original byte stream to software that already knows how to parse it.

The virtual COM port is where it turns brittle

Say the software on the PC only knows how to open COM3. That is normal for older HMI packages and for anything written back when an IP stack was still optional. You cannot point that program at an IP address and a port number instead. Windows treats a serial port as its own species of object, not a stream you open by address.

So the vendor ships a driver that fakes one. It creates a COM port with no hardware behind it. Anything the program writes to that port goes over the network to the serial to ethernet converter, and the application never learns the difference.

It works. I have kept lines running on exactly this arrangement for years. It is also the piece I trust least. COM numbers get reassigned when somebody plugs in a USB adapter. The driver is desktop Windows only, so it will not follow the application onto a thin client or into a VM, and I have watched an otherwise clean HMI migration stall on that one detail. A Windows update can leave it behind.

Nobody can find COM3 at three in the morning, and this is usually why.

When the software allows it, skip the virtual COM port and open a raw TCP socket straight to the serial to ethernet converter's data port. These devices listen on a fixed port for that purpose and the number is in the device's own manual. You do not need the driver at all, and the same setup works from Linux or from a controller that can do socket messaging.

Where a serial to ethernet converter runs out of road

All of this assumes the far end already speaks the protocol. Put the same serial to ethernet converter between a CompactLogix and a Modbus RTU power meter and watch what you get.

Nothing.

The controller speaks EtherNet/IP. Nobody told the meter, which has been doing Modbus RTU since the day it was commissioned. Delivering its bytes intact across the network changes nothing, because the controller cannot read a Modbus frame however cleanly it arrives.

That is the line. A serial to ethernet converter changes the transport and leaves the protocol alone. Turn that around and you have a gateway, which rewrites the protocol and does not much care what carried it in. Catalogs use both names loosely.

The PLX3x Series user manual, in its June 2026 revision, puts the internal database at the center of the whole design, and that is exactly how it behaves in a panel. The gateway shares one database across every communications port and uses it as a conduit between the two networks. There is a block of memory in the middle: ten thousand 16-bit registers of user data, addresses 0 through 9999, with a separate status area up in high memory starting at 14000. Each protocol driver works against the user data on its own schedule. The Modbus master driver polls the meter and drops values into registers. On the other side, the EtherNet/IP driver reads those same registers whenever the controller asks. Neither side knows the other exists, and no ladder code has to parse a foreign frame. The one catch is that high memory: a Modbus request cannot reach it at all, so anything you want out of the status area has to be mapped down into the user data first. People skip that and blame the slave.

Pin down the addressing before you configure anything. Internal database address 0 is Modbus 40001, so subtract 40001 to convert: an external master that asks the gateway's slave port for holding register 41101 is reading internal address 1100. The same memory is visible in six data types at once, all aliases of the same registers. The manual's mapping table makes it concrete: database address 1000 is Int_data[1000], BoolData[16000], BitAData[500], SIntData[2000], DIntData[500] and RealData[500], all the same place. Write a float where you meant an integer and you will quietly flatten the register next door.

Ten thousand registers in the middle, two protocol drivers reading and writing them on separate schedules. That is a gateway, not a serial to ethernet converter.

The middle case, same protocol on a different wire

Modbus RTU on one side, Modbus TCP on the other. That is the job people buy a serial to ethernet converter for, and it is the one where a plain converter comes closest to working without actually working. The protocol is already the same on both ends. Only the framing and the transport differ.

The feature is called Pass Through, and the name promises more than it delivers. What it does is take an incoming Modbus TCP message and hand it straight to a Modbus RTU slave on the master serial port. It strips the MBAP header off the frame, adds an RTU slave address and a CRC-16, and puts the result on the wire. Real frame conversion rather than tunneling, and the gateway keeps no copy of anything it passes.

The restrictions are in the manual and I still get called about all three. Pass Through exists only on the PLX31-MBTCP-MBS, so an EtherNet/IP variant will not do it. Modbus ASCII is not supported. The serial port has to be set for master operation.

Then there is the port number, which costs more hours than the rest put together. Pass-through traffic goes to TCP 2011 by default, while ordinary MBAP traffic on that model defaults to 501. ProSoft puts both of those on one configuration screen, and notes right there that most applications expect port 502. Defaulting a Modbus product to anything but the reserved Modbus port is a choice I have never understood. A correctly wired, correctly configured gateway sits there silent while the master knocks on 502.

One more parameter from the same place. MBAP Pass Through Slave ID is documented as 1 to 125, and the same entry then says a 0 makes the outgoing RTU message inherit the Unit Identifier from the incoming MBAP header instead. Leave it at 0 with a master that sends 255 there and you are addressing a slave that does not exist.

Modbus TCP in on the Ethernet port, Modbus RTU out on the serial port, and no database in between.

The parts that actually bite in the panel

The box you picked does not change any of this. Serial to ethernet converter or full gateway, the serial side is still the serial side, and it breaks in the same short list of ways.

Start where the trouble usually is. Serial TX blinking while RX stays dark means the gateway is asking and nothing is answering: baud rate, parity, node address, or A and B swapped. Roughly in that order, though I check the swap first now, because it costs nothing to look.

RS-485 on these gateways means two-wire half duplex. A four-wire full-duplex device still connects, but you have to tie TxD+ and RxD+ together on Pin 1, then TxD- and RxD- together on Pin 8. That is the manual's own workaround, with RS-422 as the fallback if the device misbehaves.

Four-wire device on a two-wire port. If it still misbehaves after this, RS-422 is the way out.

Termination is where the two ProSoft families part ways, and it has caught me moving between them. On the PLX3x the manual's advice is external: 120 Ω resistors at both ends of the RS-485 line if you are seeing echoes or reflections. The PLX51-PBM, which is the PROFIBUS box in the same lineup, carries a 124 Ω resistor on the board for its auxiliary Modbus RS-485 port, switched in by a setting called Terminate RS485. Note that this is the auxiliary Modbus port, not PROFIBUS. The PROFIBUS side gets no on-board help and still wants proper active termination in the DB9. So an auxiliary Modbus segment may already be terminated by a setting nobody can see from inside the cabinet, and a PROFIBUS segment never is.

One more, and it is specific to the RS-232 null-modem case: if you wire that way and still set the port for RTS/CTS handshaking, you need a jumper between RTS and CTS at the gateway end. The parameter is called Use CTS Line on the Modbus serial driver, and Handshaking on the ASCII driver.

The LED states, and the one that gets units returned

NS and MS only apply to the EtherNet/IP models. Flashing green on NS is the state that gets good units sent back as dead: the gateway has an address and nobody has opened a connection to it.

Worth knowing alongside that: the Class 3 server closes an idle connection after roughly 40 seconds with no data. So NS solid green that quietly goes back to flashing green is not a fault. It is a client that stopped talking.

Three things to check on a used unit

The serial ports on a PLX31 are RJ45, so a new unit ships with adapters to get to anything else. The datasheet lists an RJ45-to-DB9-male cable, a DB9-to-screw-terminal adapter and the J180 power connector; the manual gives part numbers for the first two, CABLE14 for the cable and 1454-9F for the adapter. Without them there is nowhere to land a DB9 plug or a pair of bare RS-485 wires. I ask for a photo of what is actually in the box before anything ships, because CABLE14 is the piece that goes missing. Models in this family ship one to four of those cables depending on port count, and the PLX31-EIP-MBS datasheet lists Number of Serial Ports as 1.

Firmware is the second one. On the PLX51-PBM, Modbus TCP and Modbus serial support arrived in firmware 1.001.035, and function codes 5 and 6 came later still, in 1.001.041. The release notes run to 1.001.045, dated June 17, 2025. A unit that has sat on a shelf a while can genuinely lack the function code you are configuring against. From the outside that looks identical to a configuration mistake.

Power is the third, and the two documents disagree. The datasheet rates the PLX31-EIP-MBS at 300 mA at 24 V nominal and 610 mA worst case across the 10 to 36 V range. The PLX3x manual gives the family 208 mA normal at 24 V and 300 mA maximum. Size the supply from the datasheet, since that one is written for this specific model. None of those numbers is big enough that anybody meters it, which is how a shared 24 V rail at its limit leaves a good gateway looking dead while the rest of the panel runs fine.

Questions I get asked

Will a serial to ethernet converter work with a ControlLogix or CompactLogix?

Not on its own. Logix controllers have no driver that unwraps a tunneled serial stream. Either you write socket-object logic in the controller and handle raw TCP yourself, or you put in a gateway that presents the data as EtherNet/IP. For most people the second is the right call, and the comparison stops being close once you have maintained the first.

Do I need a virtual COM port driver with a serial to ethernet converter?

Only if the software on the other end insists on a COM port. If it can open a TCP socket, use the socket. One less driver to maintain, and it survives being moved to another machine.

Can a serial to ethernet converter turn Modbus RTU into Modbus TCP?

A plain one cannot. It wraps the RTU frame, CRC and all, inside a TCP packet. A Modbus TCP master rejects that: it wants a seven-byte MBAP header on the front and no checksum at all, so the RTU slave address lands where the transaction ID should be and the CRC is left dangling on the end. You need a device that actually understands Modbus, either through a pass-through function or through a mapped internal database.

How much can one gateway handle?

On the PLX31-EIP-MBS the Modbus side takes up to 100 commands per master port, with node addresses from 1 to 247. The EtherNet/IP side has five Class 3 server connections and two Class 1 I/O connections, and the datasheet puts Max RPI time at 5 ms per connection. In practice the ceiling is poll time, not the count.

In stock, tested, and backed by a 2-year warranty

If a serial to ethernet converter is the wrong tool for your job, the ProSoft gateways above are worth pricing as surplus rather than new. We keep the PLX31-EIP-MBS for EtherNet/IP to Modbus serial, the PLX31-MBTCP-MBS for the Modbus TCP to RTU case including Pass Through, and the PLX51-PBM when PROFIBUS DP is in the mix. Everything ships with our own two-year warranty, which matters on surplus, since the original manufacturer coverage does not come along with the unit.