LabVIEW
Creating a virtual COM port
Solved!
Hi AeroSoul,
so you want a "virtual virtual COM port" and not one of those "real virtual COM ports" (aka USB-to-RS232 devices)? 😄
I don't know if there is a software/driver that simulates COM port (like there is for CAN ports with the NI-CAN driver). But you may use several of those "virtual COM port" USB devices to solve your problem!?
It's still all a bit vague. So this other application is not a LabVIEW application but something existing? And you want to write a LabVIEW application that reads from the USB virtual COM port, mangles the data somehow, transfers it to a virtual virtual COM port that your application then can connect to?
If this describes the thing you face then you would have to look into com0com as mentioned already. This software lets you create two virtual virtual COM ports that are connected together through the com0com driver. Your LabVIEW opens the USB virtual COM port AND one of the com0com virtual ports and translates the data between the two as needed. Your app connects to the other com0com virtual port instead of the USB virtual port and sees whatever your LabVIEW writes into the other side of the com0com link and anything that it sends will then be read by LabVIEW.
It is a little complicated as your LabVIEW app needs to handle incoming data from both sides properly in parallel, so your loop needs to monitor both ports in parallel for incoming data and process it to send it to through the other port out. This is one point where the Bytes at Serial Port would have some merits, not to read how many bytes you must read but to see if there is ANY data to be processed. If that value is not 0 you need to read data according to whatever the communication protocol would demand, most likely until a termination character is seen, process that data to massage it into the other format and then send it out through the other port. You would have to do that for both ports in parallel (in the same loop).
Alternatively you could do a separate loop for each port which monitors the incoming data and transfers any such data to the other loop through a queue after having it properly transformed.
Yeah you want a simulated loopback COM port. Try this:
https://www.hhdsoftware.com/virtual-serial-ports
It's got a free demo you can use. It makes two COM ports that loop to each other and will be totally transparent to your computer. Your program than then read the actual device on a real COM port then shoot the sanitized data out the mirrored port. com0com may work too but I haven't tried that one myself.
com0com does work but it is open source and with the normal warranty that comes with these free things: If it works it works and if it doesn't it's up to you to make it work! 😀
Most commercial tools providing this feature are more or less based on the com0com code or its predecessor but cleaned up, with neat installers and scripts that make everything work more smoothly on different Windows versions, including newer ones.
If you care to tinker or rather pay is everyone's own decision. 😁
@AeroSoul wrote:
Alright, the solution is already accepted and it's com0com, works fine tho two way communication was a bit of a pain to implement.
Yes I was imagining that it might be a bit of a challenge to write a piece of software that crossbars two serial ports. Although your device seems to be a talker only device? That would make it fairly simple as you don't have to worry about one direction of the data stream. If you need to support bidirectional data transfer the challenge is to handle both incoming data streams in a way that neither of them blocks the handling of the other when waiting for data.
This second string breaks the OG application, as it was not designed to handle it (it is a labview application AND i have the source code... but i'm not allowed to change it). So the "MitM" basically receives the data and removes any error strings and then send measurements to the OG application.
One wonders about the reasoning of such management decisions:
No it is a critical application and you can NOT make any changes to it before 500 security officers have read the proposal, gave their mustard to it and eventually signed it off, but installing an additional device driver (which is always a significant change to a computer) plus creating a new application that massages the strings and fakes things is no concern whatsoever. 😁
You have to love such hypocrisy.
Luckily the talkback is minimum, only several commands are sent, so my solution was to just stop reading a port while Bytes at port was not empty. Only delays the stream by one second and in the end it still gets updated because termchar was enabled.
Actually in this case i kinda agree with not changing OG source code, as the test was made to see if negative values (or more precisely calculations with negative values) are supported by the OG application.
I will admit that i also wanted to change the source code but creating a port forwarding was actually easier in the end (despite using third party program)
