LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial communication between a VI and a commercial software on the same computer

Hi everybody

 

I have a commercial software that requires entries from a VI via a serial port. Importantly, both the commercial software and the VI have to be on the same computer to run simultaneously.

 

I would really appreciate if somebody has a hint to give me to do it under labview 2009...

 

Thanks

Olivier

0 Kudos
Message 1 of 6
(1,093 Views)

The most easy solution is if you have two serial ports on your computer. Wire them together and assign one to your other app and access the other from LabVIEW.

 

If you want to do it without any physical hardware things get more tricky. You need a so called Virtual Serial Port that you can install in your computer and access from one of the applications. This is NOT a seamless thing. One of the applications needs to be specifically made to access the remote side of the Virtual Serial Port through calls to its driver interface. To the system it appears as an additional COM port that the other application can simply access through its serial port interface (in LabVIEW that would be the VISA interface).

 

So depending of your other application and who wrote it, you would have to modify it to access the remote side of this Virtual Serial Port driver or if that is not an option you would need to call  into the Virtual Serial Port driver from within LabVIEW using the Call Library Node.

 

There are likely also commercial virtual drivers that provide in fact two virtual serial ports that are internally connected in software together. That would be a no programming needed solution but definitely will cost you money to purchase and likely for each deployment you want to do with this driver.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 6
(1,053 Views)

@rolfk wrote:

The most easy solution is if you have two serial ports on your computer. Wire them together and assign one to your other app and access the other from LabVIEW.

 

I would have to agree this is probably the easiest and most robust solution.

 

Consider using two USB to Serial adaptors like this and connecting them together

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 3 of 6
(1,048 Views)

There also is an open source software only version. It is called com0com and located here: http://com0com.sourceforge.net

 

It should work but as always, YMMV! Support is likely on your own,:If it works it’s great, otherwise you are in for lots of debugging!

Rolf Kalbermatter
My Blog
0 Kudos
Message 4 of 6
(1,037 Views)

I would also recommend com0com. I have used it a few times and it works very well. The only problem it doesn't have a signed driver so if you have a fairly recent install on Windows 10 it won't run. There is a workaround which requires you to disable Secure Boot in your computers BIOS.

 

Alternatively I have also used this https://www.hhdsoftware.com/virtual-serial-ports

 

Its not open source and I struggled a bit with the free version.

0 Kudos
Message 5 of 6
(988 Views)

If you want to go commercial, one of the better solutions is probably Eltima Virtual Serial Port. It has many advanced options, especially in the Pro version and works flawlessly the few times I used it.

 

com0com does have properly cross signed drivers but not DevCenter signed drivers that are required for new Windows 10 1609 or newer installs.

 

Before that date you already needed a so called EV Code Signing certificate for cross signing drivers for Windows 7 and newer. If your certificate verified to one of the Microsoft trusted Certificate Authorities, the driver was considered valid to be loaded. This certificate costs around 300 to 400 Euro per year depending where you buy it and if you buy it for one or more years.

 

Since Windows 10 1609, Windows does not accept cross signed drivers anymore but requires that you submit the properly cross signed driver binaries together with the test reports for the OSes you want your driver signed for to the Microsoft DevCenter. There they will check that the driver is correctly signed with your EV Code Signing Certificate, that all test suites for the requested OSes have executed successfully and then replace the signing certificate in the binary with a newly generated one by themselves. Then you get the binaries back to be distributed as you see fit. In addition to a valid EV Code Signing Certificate, that requires a valid registered business address that the Certification Authority has to verify somehow, you also need a DevCenter account for your organization that has the according EV Code Signing Certificate that you want to use for signing your initial drivers for submission registered as well.

 

While this may sound like just another "simple" way to make a few more bucks, the issue is more complicated than that. Microsoft wants their OS to be used by governments as well, as that gives them some nice high volume license deals. But most governments require OSes and software in general to be certified with some rather stringent certification procedures before they can even be considered for purchase to install them on any government owned hardware. These certifications require that an OS can be verified to never ever allow to install untrusted software. This is especially true for software components that run inside the protected Ring0 of the OS kernel. A software running in this context can do absolutely anything it wants to the computer. And that means effectively ANYTHING. And device drivers run exactly in the kernel space, so it is very important to proof that such drivers can't simply be smuggled into a system by someone who happened to somehow trick the system into allowing its installation. For this the extra security of driver signing was invented. Now you don't only need to trick a computer into giving you administrator privileges to install a driver but you first have to sign this driver with your own certificate, go through the Windows DevCenter submission to have it approved and cosigned with a DevCenter certificate and then you can install it. I'm quite positive that one part of the DevCenter submission procedure is also to check the submitted binary for known attack patterns.

 

So this is in a nutshell why the whole shenigan about signed device drivers was invented. It may seem totally unnecessary to the casual computer user, but the reality is that there is a good reason behind it.

Rolf Kalbermatter
My Blog
Message 6 of 6
(979 Views)