I’m setting up an older industrial device that only talks over a physical COM port, but my new PC doesn’t have any serial ports. I’ve read about serial port redirector / COM port redirection tools that can create virtual serial ports over TCP/IP, but I’m overwhelmed by the choices and mixed reviews. I need something reliable for continuous operation, with good Windows support, logging, and minimal latency. Can anyone recommend specific serial port redirector software, what features to look for, and any pitfalls or compatibility issues I should watch out for?
If you are trying to forward a serial device over the network, yeah, a serial port redirector is usually the way to go. There are a bunch of tools floating around for that, but the one I’ve actually had decent results with is this one:
Basic idea: it creates a virtual COM port on your machine that talks over the network to a real serial port somewhere else. If you have some ancient software that only understands local COM ports and refuses to evolve, this kind of thing lets you trick it into working with remote hardware without rewriting anything.
4 Likes
If your main issue is “new PC has no COM, old gear only speaks COM,” you’ve actually got two different paths, and which one you pick matters more than which redirector app you install.
1. Figure out what you really need
-
If the device is physically next to the PC and you just need a COM port:
A good quality USB‑to‑RS‑232 adapter + solid driver often beats any virtual magic. Industrial stuff can be very picky about timing, handshaking, and weird baud rates. Cheap adapters = random disconnects and phantom framing errors. -
If the device is remote and you want your legacy app to think it’s talking to a local COM port:
That’s where a COM over TCP redirector actually makes sense.
A lot of folks skip step one and jump to network tools when a $30 adapter card or USB dongle would be more stable.
2. About software choices
@mikeappsreviewer already mentioned one solid option and they’re not wrong. Tools like
turning any network link into a virtual COM port
do exactly what you described: create a virtual COM port that tunnels all serial data over Ethernet to some real COM somewhere else.
I’ll slightly disagree on the “just pick one redirector and go” idea though. Things to actually test before you commit:
- Latency & jitter:
Some redirectors buffer too aggressively. For industrial gear that’s time‑sensitive or uses tight polling intervals, that can break protocols in really subtle ways. - Hardware flow control:
Make sure RTS/CTS and DTR/DSR really get passed correctly. A lot of tools claim “full handshake” and then silently fake some lines. - Service/logging:
For production or plant floor environments, you want it to run as a Windows service and give you real logs when the line glitches at 3AM.
3. When you want something more “industrial‑ish”
If your plan is to talk to that device from multiple PCs or from a VM or over VPN, I’d seriously look at Serial to Ethernet Connector. It’s built for exactly this use case: create virtual COM ports that map to remote serial endpoints over TCP/IP.
Typical pattern:
- Install Serial to Ethernet Connector on a machine that either
- has a physical COM port connected to the industrial device, or
- has a USB‑to‑serial adapter plugged in.
- Share that serial port over the network inside the app.
- Install the same software on the new PC, create a virtual COM that connects to that shared port.
- Point your crusty old industrial program at COM3 or COM5 or whatever it expects, and it “thinks” it’s still talking to a local port.
What I like there is that it handles multiple connections, encryption options, and generally behaves better under flaky network conditions than some of the bare‑bones freeware stuff. Less fun to troubleshoot, more fun to forget it’s running.
4. Quick sanity checks before you choose
Whichever tool you go with, I’d test it like this:
- Use a simple terminal program (PuTTY, Tera Term, etc.) on the new PC.
- Connect via the virtual COM the redirector created.
- Confirm:
- You can send/receive basic data.
- The app behaves at the weirdest baud rate you’ll need.
- Toggling RTS/CTS on one end actually changes on the other.
- Then run your real industrial software and watch for:
- Timeouts during initialization.
- Random disconnects when traffic spikes.
- Problems after a network hiccup or sleep/hibernate.
If any of that fails, no fancy marketing text about “virtual COM magic” is going to save it.
5. Short answer version
- Local-only, short cable: try a good USB‑to‑serial or a PCIe serial card first.
- Remote, over LAN/WAN: use a serial over IP tool.
- Among those, something like Serial to Ethernet Connector is worth a look, and the tool @mikeappsreviewer mentioned is fine too, just make sure you actually test flow control and timing with your device before deploying it on the line.
And yeah, expect to spend more time fighting drivers and timing quirks than the brochures suggest. Industrial serial gear never dies, it just makes your Windows config life miserable.
Short version: you don’t pick a redirector first, you pick an architecture first. The tool is secondary.
@mikeappsreviewer and @vrijheidsvogel already covered the classic “virtual COM over TCP” approach pretty well, so I’ll skip rehashing that whole playbook and poke at a few angles they didn’t focus on.
1. Are you sure you even need a redirector?
This is the part people hate to hear:
- If the device is sitting right next to the PC and only one PC will ever talk to it
→ A decent USB‑to‑RS‑232 adapter or PCIe serial card is usually less painful than any COM redirector stack.
Redirectors add:- Another driver layer
- A network dependency
- One more failure point you get blamed for at 2 AM
I’d only bring in a redirector if:
- The serial device must be shared between multiple PCs, or
- The device physically lives somewhere else on the LAN, or
- You’re stuck with a VM / RDP / thin client setup where local COMs are awkward.
If none of that is true, I’d actually disagree a bit with the “just use a redirector” suggestion and try real hardware first.
2. If you do need redirection, think “device server” not just “driver”
The piece almost nobody mentions: a lot of the “serial port redirector” pain goes away if you terminate the serial line on a small hardware box instead of another Windows PC.
Pattern that works well in plants:
- Use a dedicated serial device server (or a small PC) that:
- Has the real RS‑232/422/485 port
- Sits close to the industrial device
- Runs something like Serial to Ethernet Connector to expose that COM over TCP
- Your new PC only runs the client part:
- It gets a virtual COM port
- Your old app thinks it is talking to COM3 locally
Why this beats “USB dongle into your new PC + redirector”:
- Cable length & noise: RS‑232 over long runs in industrial noise = fun random errors
- Stability: the box next to the machine never reboots for Windows updates right in the middle of production
- Easier to swap PCs: new PC → reinstall client → same virtual COM mapping
So if this is on a line anyone cares about, I’d lean toward that over a purely PC‑to‑PC arrangement.
3. What actually separates “okay” from “useable for industrial stuff”
Everyone advertises the same features. Stuff I actually test that will kill you quietly if you ignore it:
-
Break signals & edge cases
Legacy protocols sometimes use “BREAK” or ugly timing quirks. Some redirectors either drop that completely or translate it badly.
Try:- Weird baud rates (e.g., 134400, 76800)
- Non‑standard framing (7E1, 5N2, etc.)
- See if break conditions show up correctly on the other end
-
Recovery behavior
I care less about raw throughput and more about:- What happens when the network cable is briefly yanked
- What happens after Wi‑Fi roams or VPN blips
- Whether the virtual COM silently hangs instead of failing loudly
-
How it behaves as a service
Some tools look fine in a GUI and then misbehave when run as a Windows service at boot.
For production: service mode + logs with timestamps + automatic reconnect are non‑negotiable.
This is where Serial to Ethernet Connector tends to be a decent choice: it is built specifically to turn serial ports into network‑shareable resources while still presenting clean virtual COMs to Windows. Not saying it’s magic, but for “industrial, legacy app, don’t touch the original software” scenarios, it checks the boring boxes that matter.
4. Software choice: try more than one, and ignore marketing fluff
@mikeappsreviewer and @vrijheidsvogel already pointed out a specific redirector that works for them. I’d add:
- Different redirectors handle buffering and flow control differently
- Some are “tuned” for lab gear, some for SCADA / fieldbus‑ish traffic patterns
- Latency that looks fine on a graph can still break an old polling loop
If you want to actually test a few options, grab something like Serial to Ethernet Connector from here:
reliable virtual COM tools for industrial devices
Then run a quick shootout:
- Start with a simple terminal program on the new PC.
- Connect via virtual COM.
- Hammer it at the exact settings the real software will use.
- Only then fire up the actual industrial app and watch for:
- First‑time init failures
- Random “lost connection” errors under load
- Weird behavior after a few hours, not just 2 minutes of testing
If one tool survives that with no drama, that’s your answer. If they all suck, that’s your sign to retreat to a physical serial card or a better network segment.
5. When to stop being clever
Blunt reality:
- If this device controls something expensive or dangerous, I’d avoid stacking:
- Redirector software
- Wi‑Fi / flaky VPN
- Old app that was written when 10 Mbps hubs were cool
In that case, a boring PCIe serial card in a PC in the cabinet often beats any fancy TCP tunnel. No one gets points for “cool architecture” when someone has to explain why the press stopped mid‑stroke because the virtual COM driver glitched.
So:
- Local, single PC, no sharing: real serial hardware first
- Remote / shared / VM / central control room: use a redirector, and Serial to Ethernet Connector is a solid candidate to try
- Always test with your actual protocol, not just “I see characters in a terminal”
If you can share what device and baud/protocol you’re dealing with, you’ll probably get people chiming in with “we run that exact thing over virtual COM and it works / totally doesn’t work,” which can save you a few days of swearing.
Short version: pick the topology first, then the tool, and keep it as boring as possible.
Since @vrijheidsvogel, @sonhadordobosque and @mikeappsreviewer already walked through classic virtual COM over TCP and specific redirector picks, I’ll focus on what actually helps you decide.
1. Physical vs virtual: when a redirector is worth it
I slightly disagree with the idea that “if it works, it’s fine.” For older industrial stuff, the cost of one random hang can be higher than the license fee of a more robust setup.
Rough rule I use:
-
Use a USB to RS‑232/422/485 or PCIe serial card when:
- The device is near the PC
- Only one PC ever talks to it
- You are not in a VM / terminal server situation
-
Use a serial redirector when:
- The device is in a cabinet far from the PC
- Multiple PCs / VMs may need access
- You want the flexibility to move the PC without touching wiring
If you check even one of the second group, virtual COM is usually justified.
2. “Serial to Ethernet Connector” in that picture
You already saw recommendations for other redirectors from the others. I’ll add Serial to Ethernet Connector into the mix specifically because it plays well in industrial “leave it for years” scenarios, not just lab use.
Pros:
- Handles client/server roles cleanly
- Good if you put a small box near the machine and expose its COM over TCP
- Solid service mode
- Starts with Windows, reconnects automatically, logs events
- Flexible serial settings
- Non‑standard baud rates, parity, data bits are usually not a problem
- Can share one serial port to multiple clients in some modes
- Handy for monitoring plus control (with care)
Cons:
- It is not free
- For hobby use or one‑off home projects, that can be annoying
- Added complexity
- One more service, one more config to back up and document
- Still limited by the network
- If the LAN is noisy or flaky, no software magic will make that disappear
If you go this route, treat it like infrastructure: document COM number mappings, IPs, and reconnect settings so future you does not have to reverse‑engineer it.
3. How it compares in practice to what others mentioned
Without repeating specific products that @vrijheidsvogel, @sonhadordobosque and @mikeappsreviewer brought up:
-
Some options are lightweight and great for quick lab work, but weaker on:
- Logging
- Auto‑reconnect
- Oddball serial formats
-
Serial to Ethernet Connector is more “industrial‑plant oriented,” which typically means:
- More setup time
- Fewer surprises during long uptimes
So if this is a one‑day test, almost anything will do. If this is a production line that runs 24/7, I’d personally lean toward the heavier but more predictable option.
4. Concrete decision checklist
Before choosing:
-
Distance & environment
- Same rack, low EMI: try a physical serial card first
- Across the building or in a noisy environment: prefer a device server + redirector like Serial to Ethernet Connector
-
Access pattern
- One PC, one device, no sharing: simpler is better
- Multiple operators / SCADA / VMs: virtual COM is much easier to scale
-
Tolerance for downtime
- If “oops, need to reboot” is acceptable, any redirector is fine
- If a reboot at the wrong time ruins product or causes alarms, choose something with strong service behavior and logging
If you share the exact protocol (e.g. Modbus RTU, proprietary ASCII, 7E1 at a weird baud), people can usually say whether they have run that combo successfully over a redirector like Serial to Ethernet Connector or if you are better off biting the bullet and installing a hardware serial card.