Right now I’m trying to let two applications read the same serial device for my team, and I’m sorting out the cleanest way to configure Serial Splitter Software. Do you actually use a shared virtual port, a pair of linked virtual ports, or network redirection for this kind of setup, and why? I’m especially interested in how you handle reconnects and prevent one application from locking out the other during routine use.
The hidden trap is that “sharing” a port does not always mean both applications receive an independent copy of every byte. If the software treats them as competing readers, whichever app reads first can consume the data and leave the other with gaps.
For two applications on the same PC, I’d have the splitter own the physical COM port exclusively and expose a separate virtual COM port to each application. Both virtual ports should receive cloned input. That is cleaner than pointing both programs at one shared virtual port, especially when an older application expects exclusive access. The basic distinction is covered here with serial splitter explained, and it is the arrangement I’d look for when configuring Virtual Serial Port Driver or similar software.
Linked virtual-port pairs are more useful when two applications need to communicate with each other as though a serial cable connects them. They do not automatically solve physical-device sharing unless another component copies data from the real device into both paths. Network redirection makes sense when an application runs on another machine, or when you want the serial connection managed by a dedicated host. For two local readers, it adds more failure points than necessary.
For reconnects, keep the virtual COM numbers persistent and configure the splitter service to reopen the physical port automatically. Start that service before either application. If the USB serial adapter disappears and returns under a different COM number, automatic reconnect cannot do much, so pin the adapter to a fixed port assignment if possible. Applications should retry with a short delay rather than repeatedly opening and closing the virtual port.
Writes need an explicit rule. If both applications can transmit, commands may interleave or produce unpredictable device responses even though incoming data is cloned correctly. I’d designate one application as the writer and make the other read-only. If the splitter cannot enforce that, configure the monitoring application so it never sends initialization strings, polling commands, or handshake changes. That usually prevents the apparent “lockout” problems blamed on the splitter when the real issue is two programs reconfiguring or commanding the device at once.
11 Likes
A linked pair is the wrong setup when both programs need the same device data because it connects endpoints rather than cloning the stream. Virtual Serial Port Driver makes the port mapping especially easy to inspect, while the COM splitter app is the dedicated route for assigning each program its own feed.
Do not assume “cloned” data means each application gets its own protected buffer. If one program freezes, reads slowly, or stops consuming data, some splitters will drop bytes for that client, while others may let the backlog affect every connected application. That behavior matters more than whether the interface calls the port shared, split, or virtual.
The separate-port arrangement described by @dr_signal is the least ambiguous setup, but I would test it under failure conditions before deploying it. Pause the monitoring app, send a sustained stream from the device, then resume it. Check whether the primary app kept receiving data and whether the paused app gets old buffered data, starts with current data, or disconnects. A sequence number in the device output makes gaps much easier to spot.
A shared virtual port is not automatically wrong if the software explicitly broadcasts incoming bytes and maintains independent queues. The problem is that “shared” is used loosely by different vendors. Linked pairs are clearer in purpose, but they are mostly for app-to-app communication and add unnecessary plumbing here.
For a team setup, I would prioritize predictable failure behavior over a tidy-looking port map. Let the splitter own the hardware port, give each application its own endpoint, and set a sensible buffer limit so a dead monitoring process cannot consume memory forever. Then document what happens after an overflow. Silent byte loss is usually worse than an obvious disconnect because both applications can appear healthy while showing different data.
Don’t configure both applications as equal owners of the connection. Even with separate virtual ports, the second program may change baud rate, assert DTR or RTS, enable flow control, or send an initialization command as soon as it opens. Some devices reset when DTR changes, so what looks like an unreliable splitter can actually be the monitoring application repeatedly restarting the hardware.
I’d set this up as a primary application plus an observer. Let the splitter open the physical COM port with fixed baud, parity, stop-bit, and flow-control settings. Give each application its own virtual port, as @dr_signal suggested, but prevent the observer from controlling line settings or transmitting if the software supports those restrictions. Check the observer’s settings carefully because “read only” in the user interface does not always mean it leaves the serial control lines alone.
There is another detail that matters if the device uses request-and-response traffic. Some splitters copy bytes received from the device to every virtual port but do not show the primary application’s transmitted commands to the observer. The observer then sees responses without seeing what requested them. If your second program needs to reconstruct complete conversations, confirm that the splitter can mirror both RX and TX traffic to that endpoint. A packet logger may be a better choice than a second normal serial client when the goal is diagnosis rather than operating the device.
For initial setup, keep it boring: assign permanent COM numbers, start the splitter first, open the primary program, and add the observer last. Then close and reopen each application separately while watching the actual device. If opening the observer causes a reset, a settings change, or a pause in data, fix that before testing disconnect recovery. Once the configuration works, export or document the port map and every serial setting. Otherwise someone will reinstall the USB adapter, get a new COM assignment, and spend an afternoon troubleshooting a splitter that is still pointing at the old port.
If one of your two apps only watches traffic and never talks back, half the setup advice here stops mattering. A pure read-only observer doesn’t need a cloned virtual port at all in some cases. You can tap the line at the hardware level and let your logger sit on a physically separate path, which sidesteps every ‘who resets DTR’ worry @voyageurdubois raised. That option gets forgotten because software splitting feels tidier, but a passive tap can’t accidentally command your device. It literally has no wires to do it with.
Where I’d push back a little is the assumption that splitting is free. Every extra layer between the hardware and the app adds a bit of latency and buffering, and on timing-sensitive protocols that matters. If your device expects a response within some window and the splitter is queuing bytes for a slow second client, you can get timeouts that look like flaky hardware. @nexthub1967 is right that failure behavior beats a pretty port map, and this is the same coin. Test with realistic load, not a quiet bench.
For the actual local two-app case, the separate-virtual-port approach is the sane default, and yeah, Virtual Serial Port Driver handles that arrangement without much fuss. Just don’t skip the boring part: pin the USB adapter to a fixed COM number in Device Manager before you build anything on top. I’ve watched people configure everything perfectly and then lose it all because Windows handed the adapter a new port after a firmware update. Lock the number first, then split.
Check whether your second application supports passive input. The primary-plus-observer setup assumes it does. If that program sends a request and waits for a matching answer before updating its display, handing it a copy of somebody else’s traffic may accomplish nothing. Disabling its writes could leave it sitting at “connecting” forever. That is an application compatibility problem, not a port-mapping problem.
Before spending time on reconnect settings, look for a listen-only mode in the second application. Then try one ordinary operation from the primary application with the observer’s transmission disabled. Does the observer actually interpret the result, or does its receive counter increase while the display stays blank? Getting bytes into both programs is only half the job. Both need to make sense of those bytes without independently running the device.
If the second program requires its own conversation with the hardware, I would stop trying to solve that with a splitter. Check whether the primary application can export readings or provide a local data feed instead. Separate virtual ports are the arrangement I’d choose for compatible readers, but they cannot turn two independent device controllers into a coordinated system.