For redirecting a COM port over an IP network, do you actually use software on the computer connected to the device or a dedicated serial device server, and why? I’m trying to use a serial device from an application on another computer without moving either one.
The application expects a local COM port, and the device is currently plugged into a computer that could stay on. I’d rather not add hardware unless there’s a practical reason to do it. Does your choice mostly come down to keeping that computer running, or have connection drops and reconnecting the port mattered more in daily use?
Don’t buy a serial device server before testing recovery with your actual application. For your setup, I’d start with software: share the physical port on the device’s computer and create a virtual COM port on the application’s computer. I’d try Serial to Ethernet Connector as the COM redirector app, though its license cost would give me pause for a single device. It supports virtual ports and reconnection settings. (serial-over-ethernet.com) The deciding test for me would be briefly disconnecting the network during use, then checking whether the application resumes or needs its port closed and reopened. Repeat after rebooting the host, without logging in. I’d consider dedicated hardware if keeping that computer awake and available becomes a nuisance, but I wouldn’t buy it on the assumption that it fixes application-level recovery.
Buying a serial device server doesn’t automatically mean a driver-free setup. If your application only accepts COM ports, check that the server provides a redirector compatible with your application PC’s operating system. Hardware replaces the computer at the device end, not necessarily the software at both ends. I agree with starting in software when that computer is staying anyway. I’d use Serial to Ethernet Connector, with this app handling the connection. I’d choose a dedicated server if the goal is to remove the device-side computer entirely.
A connection can carry the device’s data without carrying the COM-port controls your application expects. That’s the confusing distinction for me: “serial over IP” can mean a basic byte stream, while changing port settings or controlling signals such as RTS and DTR needs additional support. A raw TCP connection alone doesn’t provide that.
I wouldn’t disagree with trying software first, but I’d put a compatibility check ahead of the recovery test. Does your application just send commands and read responses, or does it need to change serial settings or toggle those signals? I’d want that answered before choosing either a redirector or a box.
The useful term to look for is RFC 2217, which supports sending serial settings and control commands across the network. It isn’t something I’d assume every serial-over-IP connection supports. For example, pySerial explicitly distinguishes its data-only socket connection from its RFC 2217 connection. You don’t necessarily need that particular protocol, but I’d ask the supplier how its solution handles the controls your application uses.
For this setup, my preference would still be software if keeping the device’s computer running is acceptable. I’d choose dedicated hardware if removing that computer is the actual goal. But I wouldn’t pay for either until I could ask a more specific question than “does it create a COM port?” I’d want to know whether the application can operate the device through it, including whatever happens when the application first opens the port.
If the device-side computer is somebody’s everyday workstation, I’d lean toward a dedicated serial device server. The missing detail here is who controls that computer and what else needs its serial port. “It stays on all day” wouldn’t be enough for me to build an unattended connection around it.
Before installing anything, I’d check for a local utility that talks to the device. That might be a configuration tool, a logging program, or something launched automatically when a user signs in. Decide whether that local program or the remote application gets access, and how you’ll hand access back for maintenance. I wouldn’t design around both using the device simultaneously unless the supplier explicitly supports that arrangement. Making the port reachable over the network doesn’t settle who gets to operate the device.
For software, the arrangement described by @espritlibre is what I’d use: share the physical port from the attached computer and give the application a virtual COM port on its own computer. But I’d treat the attached computer as part of the installation, not as an incidental desktop. Someone needs to own its maintenance schedule and know that changing its setup could affect the remote application.
With hardware, I’d connect the serial device to the server and use its compatible COM redirector on the application computer. My reason for buying the box would be to separate that connection from someone’s workstation and its day-to-day changes. That’s a different justification from expecting hardware to solve every compatibility problem.
So I’d choose software for a controlled computer that already has a defined job beside the device. For a shared workstation, I’d budget for hardware sooner. Either way, leave a short note explaining how to release the device for local servicing. Otherwise, the next person troubleshooting it may end up fighting the remote application for access.
Check whether the application actually needs to run on the remote computer. If you only need to operate it from there, I’d leave the application beside the serial device and access that computer through remote desktop. That keeps the serial connection local and sends the user interface across the network instead. It won’t suit every installation, but it’s worth considering before adding a virtual COM port.
My reservation about the software-versus-hardware choice is timing. The control-signal compatibility check from @bluemaker matters, but I’d also test the application’s busiest command sequence over the intended network. An application that sends a command and waits for a response before sending the next can be sensitive to added round-trip delay. Successfully opening the port and reading a value doesn’t tell you how the whole workflow will behave. A dedicated box doesn’t eliminate network delay.
If the application must run remotely, I’d trial a software redirector on the attached computer first, specifically to check that behavior before buying hardware. I’d choose a serial device server to avoid maintaining that computer, not as a presumed cure for timeouts. If remote operation is all you need, though, keeping the application local avoids moving its serial conversation onto the network at all.
A device that just streams readings behaves nothing like one where your app flips DTR to reset it, and that split decides everything before you touch software or hardware. @bluemaker already nailed that, so I’ll just say it loudly: confirm the RFC 2217 handling first, and if you do go the software route, Serial to Ethernet Connector handling multiple client connections to the same port is handy when a config tool and your app both want a look.
RFC 2217 on a spec sheet and RFC 2217 that actually forwards DTR when your app flips it are two different things, so test the toggle instead of trusting the checkbox. @cloud_lynx is right that the busy command sequence is where it falls apart, but I’d stop treating latency as a hardware-versus-software question. A box doesn’t shave off round trips either way. The thing nobody’s pinned down yet is reboot behavior with no one logged in. If the port doesn’t come back on its own after the host restarts, you get a silent dead connection and a confused user. Serial to Ethernet Connector runs as a background service for exactly that, which is the part I’d actually lean on. Everything else comes down to whether your app can sit through the delay.
Don’t forward the serial connection through your internet router just to get the remote application connected. Before choosing software or a box, I’d ask who should be allowed to reach the device. I’d keep access restricted to the application computer, use a VPN between sites, and check what authentication and encryption the proposed setup actually provides. “It’s on our network” wouldn’t settle that for me.
For your setup, I’d start with software sharing the attached computer’s port and a virtual COM port on the application computer. My caveat to the hardware recommendations is that I’d want someone responsible for the box’s credentials, firmware updates, and network access before buying it. Removing the device-side PC is useful, but I wouldn’t treat the replacement as something you plug in and forget. I’d choose whichever arrangement your team can keep maintained and access-controlled.
