Adrian Lewis
Adrian Lewis

Reputation: 19

Accessing Serial Port With Multiple Programs

I am trying to access a single COM port connected to an instrument. The COM port is intended to be accessed by a Python program and LabVIEW program who both read data from the instrument. They are each expected to be able to run independently of each other since they each serve different functions, but should also be able to run simultaneously (they will pull data periodically, approx every 10 seconds). I understand that serial ports cannot be connected to more than one program at the same time, but I have been told and have read that using a TCP may make this possible.

Does someone have an idea of how this might work or is there a misunderstanding that I have? I have been told about TCP sockets, but do not understand what that would accomplish. I have also looked into software (such as HW VSP3), but they cost money and I do not want to purchase something unless I know that it will work.

Upvotes: 0

Views: 2360

Answers (3)

Fourier
Fourier

Reputation: 111

You should create a third application (in python, labview or whatever you want) which is the only program that access to the COM. This program should also acts as a TCP server. The two programs you mentioned will act as TCP client and the will connect to the above mentioned application (the TCP server). The TCP server sends (via TCP/IP) the data read in the COM.

Upvotes: 0

tolgahann susur
tolgahann susur

Reputation: 1

I have a suggestion but you need to use couple of simple extra hardware. You can try to create usb to wifi converter by using ESP32 and save response in global variables as array or any data type you want and broadcast them on wifi over UDP. There is no limitation of connection over UDP. You can access your variables on phyton, labview or any interface you want.

Upvotes: 0

Yair
Yair

Reputation: 2276

In any scenario, I think the first assumption is that all communication is initiated by the PC and not the instrument.

If the programs really are communicating with the instrument only once every ~10 seconds and the communication is relatively short, you could probably get away with simply opening and closing the serial port for each command and retrying on errors. This will make the code on both sides simpler, as it won't require any synchronization other than handling the errors by retrying a few times.

I'm assuming that the port will be OK with being opened and closed all the time by multiple programs, but I don't think I ever did anything like this and it would probably depend on the quality of the driver for the serial port.


The other option, as suggested by the others, is writing a server program which will be the one actually using the port. It would have to listen for incoming TCP connections and then keep those sockets open. Whenever a request comes in on a socket, it would be added to a queue to be handled and when handled, it would be sent to the serial port and have the reply forwarded back to the socket.

In this case, I would suggest the server should be ignorant of the data it's passing and simply serve as a channel, but it will need to have enough logic to handle things like timeouts on the serial or TCP side, not letting the queues grow too much, etc.

Note that I said TCP here, but you could probably also use a program like com0com (which I have no experience with) or another virtual port program to make the channels to the server be COM ports as well. That way, you don't have to modify the programs to use TCP and they can keep using a COM port. That COM port will just be a virtual COM port managed by the server program.

You should be able to write the server in either Python or LabVIEW, whichever you're more comfortable with.

Upvotes: 1

Related Questions