Serial COM port multiplexing

Greetings EE Gods.

I have a piece of hardware that talks to my computer via COM3 USB-to-SERIAL.  works great.
I have five programs, who connect to the COM port, which all five connect to COM3.  

The problem is that when one program is connected to COM3, none of the others do.
Is there a way to multiplex them, so all of the programs can work with the piece of gear?

ie, a virtual COM switch or router?  something I would run on the computer?

I am also a programmer, C# and VB...any coding ideas would be great too.
Evan CutlerVolunteer Chief Information OfficerAsked:
Who is Participating?
Davis McCarnOwnerCommented:
I have gotten good feedback on Com@Anywhere which costs $50:
If they are connected simultaneously, are you using 5 usb com ports? You can renumber them in device manager - ports to avoid conflicts. Can't see how more than one device at a time can think it is com 3. Because USB connections tend to be volatile, you would probably be better off with a digi or moxxa multi port device. More info?

Chris B
It can be done, but need to be careful.

I have never used the software. but quick search come back with this
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Evan CutlerVolunteer Chief Information OfficerAuthor Commented:
I can build either.
I'm just looking for the ability to do it.
Either way.
I can't see a simple software solution working. How could it distinguish between devices? Since COM ports (RS232) only expect to be connected to a single device, the protocol doesn't expect a virtual port ID in the messages.

Presumably you have five applications running, one for each device. If your current adaptor cannot be configured to use separate COM ports, then you need to buy one or more adaptors that can do that.
I think the idea was one RS232 device, but let X applications talk to it.
The way the deivce works needs to work with it, but it can be done.

Assuming the device simply reponds to a request from a computer, then the com port share software tracks who made the request and sends the answer back to that device.  You can think of it as a device Proxy, where the applications are the clients.

If the device sends events at any time, then I would expect that event would get sent to ALL devices, at which point does the device expect a response, if so who replies.  The proxy could send the first reply back and drop the others....
Evan CutlerVolunteer Chief Information OfficerAuthor Commented:
well, with one of the applications, I can actually see the ASCII code being sent to the device, then see the device's response.

That being said, I <operative word> assume </operative word>  that comms will go to the device, then the device will send an acknowledgement, or data back.

That being said, I was thinking of some sort of programmical queue that would bring in all the information it needed.
If you want to do it in your code and your are writting ALL applications, then you could create a service "comm port access", which connects to the comport and has a TCP server for client app connection.  Clients then send via the TCP to that service.

You could write your own proxy app, so you will need to learn how to create a virtual serial port (I had a quick look once, but never spent too much time on it).

Or, just use what someone else has already developed as per some the products listed, or search for others (now that you know the sort of app you need to find).

 In general with serial communications you do not get the level of information that you would on a TCP style communication.  This extra TCP information allows a router to spoof the request and send it out.  When the response comes back the router will interpret which IP address sent the request and redirect the response back to the source.  In serial communications you do not have the extra information necessary to accomplish this the same way.

  If a device is MADE to work this way then each request would have some ID associated with it so listeners could identify which communications belonged to them.  If your device allows this then you can make it work, but I would use the first approach mentioned by m_walker on his previous post (make your own server that the programs talk to which then forwards the COM traffic).

  If the device is not made to work with multiple programs at one time then it could become very easily confused.  Imagine a COM printer where one command could request status (expecting a response) and another command could be sent (perhaps to print one line) that does not respond with status (timeline below).  When the response is made to the status request, who gets it?  For that matter, has the status been corrupted by the request to print a line (thus wiping out the previous status)?  This is only a simple example.  If the attempt to send were truly at the same time then the requests could really get messed up.

If I had to approach this type of problem I would handle it like this:
1) Design a server portion that allows you to lock the device for use by one program, then free it IMMEDIATELY when done.
2) Design your programs to handle communications through the server making sure to do everything possible to make sure the lock is released ASAP.

Since this approach would allow a single program to handle it's own responses the extra ID would not be required.  It would have the effect of serializing the program's requests to access the device.

1                     2                           3                                                    4
Device                           Receive Status Request      Process status request and receive print request     Respond to Status request
Program 1  Send Status Request                                                                                
Program 2                        Send Print One Line Request

Open in new window

Davis McCarnOwnerCommented:
The low level flow control on a COM port consists of reading the status port to see if a character has been received (or a different bit on the same port to see if it is ready to send) followed by sending or receiving the character to the data port.  But (!!!), once that character is received or sent, it disappears.  There is no ability in the hardware to receive the same character twice.
So, what that Com@Anywhere software does is to create multiple, virtual copies of the "port" so multiple programs can access it and, while I must have written hundreds of machine language utilities to handle serial and parallel ports in the 1970's and 80's, I wouldn't even want to try creating multiple virtuals especially given the complexities of a Windows system.  Since it also adds TCP/IP access to those virtual com ports,  I'd guestimate at least a couple of man months to get it done so I'll spend the $50, thank you.
COM ports, BTW are character devices meaning you have to check the status port for each character in or out.
Evan CutlerVolunteer Chief Information OfficerAuthor Commented:
Do you have the link to Com@Anywhere?  Google is having a fun time finding it where I am at.
Davis McCarnOwnerCommented:
My first post:
 have gotten good feedback on Com@Anywhere which costs $50: 
Davis McCarnOwnerCommented:
I gave him his answer in http:#35226026 and http:#35234762
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.