LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Virtual seral port (COM port) without NI-VISA

Solved!
Go to solution

I have a plug-and-play instrument, with USB plug, that installs under COM3, as a (virtual) USB Serial Device.  The windows device manager says that the device status is OK.

 

However, I could not open a connection in powershell: "mode com3" replies with an absurd baud rate. When trying to modify the parameters, windows replies that it is impossible. The command "Get-CimInstance -ClassName Win32_SerialPort -Property *" gives an avaibility of 2, that is "unknown", and no communication is possible.

 

With NI-MAX, the port ASRL3::INSTR "COM3" get a yellow exclamation mark, the "validate" button for the parameters returns a VISA error code 0xBFFF0000, and same error if I try to open a test panel.

 

I am able to communicate with the instrument with API commands using the Termite 3.4 software.

 

In Labview, the VISA Initialization fails, before I can even configure the transmission.

 

Therefore I developed a solution that by-passes NI-VISA.

 

I have been able to design vi’s to communicate with the instrument using kernell32.dll WINAPI functions: CreateFileA(), CloseHandle(), ReadFile() and WriteFile(). I have to manually add a NULL character at the end of the "COM3" string in the CreateFileA(). I add a \cr character at the end of commands, as specified by the instrument documentation. I could not configure baud rate, parity, and so on, but it might not be important: communication with Termite also does not care of the actual values. On the ReadFile(), I discard the last two characters that are actually \CR\LF for this instrument.

At beginning of the day, the first try might be not successfull. If I runTermite before, and sends a "*IDN?" command for example, then the transmission is OK for the rest of the day. The library may lack a PurgeComm() or ClearCommError(). I have to use a wait time between write and read, otherwise it may happen that there are no string in the buffer, and at the next try the old answer will still be there.

0 Kudos
Message 1 of 12
(2,821 Views)

What instrument are you having to do this with?  I suspect you are missing a driver to properly configure the COM port.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 12
(2,793 Views)

Indeed, during the installation, an event is reported in the windows event manager saying that a permission is missing. I have asked the instrument company: they say that labview is not supported. I suspect that something bad happened at the installation. A new version of the instrument software is expected in a few months. Anyway, there is a way to bypass NI-VISA.

0 Kudos
Message 3 of 12
(2,761 Views)

*sigh* LabVIEW is always supported.  It's just another programming language.  If you can't implement a driver in LabVIEW, then you can't implement it in any other language, either.

 

Now whether they want to support it - e.g., sending you the source code to a dll so you can hook into it with a CFLN, or something like that, well... that's another story.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
Message 4 of 12
(2,748 Views)

I could not communicate with the instrument via powershell either. This means that communicating is not easy, even in an other language.

PS> [System.IO.Ports.SerialPort]::getportnames()
COM3
PS> $port= new-Object System.IO.Ports.SerialPort COM3,9600,None,8,one
PS> $port.open()

 

The open() operation fails. I have read here that the virtual serial communication might not be reliable with .NET System.IO.Ports.SerialPort. Is that possible that NI-VISA is based on that library rather than kernell32.dll ?

 

0 Kudos
Message 5 of 12
(2,730 Views)

I have seen virtual serial devices that don't play well with Windows. They would connect fine for the first time after power cycling, but then, with a system dependent probability, would fail to connect again, freezing the process.

 

Have You tried resetting the connection (via hardware or by resetting the VCP device driver)? I found that the first fresh connection is often very reliable. You also may want to try different (older) computers or different OSes.

0 Kudos
Message 6 of 12
(2,689 Views)

Thanks.

Yes, I have tried to reset, and uninstall, several times, the COM3 device, unplug and replug the the device... without success.

I have tried to communicate via PUTTY: no success.

I have tried on a different computer, running windows 7 (instead of W10) : not better.

I have tried to modify the permissions of the faulty GUIDs according to the windows event manager, modifying the register following suggestions on the net: bad guess, the windows menu got frozen, I had to reinstall windows from scratch.

The VirtualSerial library works, and that's fine.

 

 

0 Kudos
Message 7 of 12
(2,642 Views)

Here is a new version of a library to access a serial communication port without NI-VISA, based on WINAPI (kernel32) commands.

 

I had to develop that library because of an instrument that is not delivered with a driver. The "plug and play" instrument installs COM3 as a virtual com port. Ni-MAX is not happy with that installation and reports an exclamation mark with an "unknown" status, so that it is not possible to proceed with NI-VISA. The Ni-visa wizard fails to create a driver: it creates a .inf file but complains it may not have appropriate permissions from windows. The inf2cat.exe is not available on my computer. The instrument serial communication was possible with TERMITE3.4 software.

 

The previous library version (VirtualSerial.zip) neeeded a communication with TERMITE at the beginnig of the day, or otherwise Labview would crash. In this version, a SetCommTimeouts() right after the com opening solves that issue.

 

I have tested that library with a Virtual Com Port (VCP) only. In my case, the instrument does not care about parity, baud rate, etc.; it only requires to terminate command lines with a \cr.

 

 

 

0 Kudos
Message 8 of 12
(2,609 Views)

That seems very strange to me.  Any COM port that shows up in Device Manager as a COM port will be usable by any application, period.

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 9 of 12
(2,594 Views)
Solution
Accepted by topic author fb35

@fb35 wrote:

I could not communicate with the instrument via powershell either. This means that communicating is not easy, even in an other language.

PS> [System.IO.Ports.SerialPort]::getportnames()
COM3
PS> $port= new-Object System.IO.Ports.SerialPort COM3,9600,None,8,one
PS> $port.open()

 

The open() operation fails. I have read here that the virtual serial communication might not be reliable with .NET System.IO.Ports.SerialPort. Is that possible that NI-VISA is based on that library rather than kernell32.dll ?


No! NI VISA is multiplatform and does not rely on .Net for its operation. It does internally use plugins for the different resource types and the serial port plugin directly interfaces to the COMM API in kernel32.dll.

 

Your problem is definitely in a bad device driver installation. This could be a specific kernel driver module that is not working properly, or if it is using the standard Windows serial.sys kernel driver, the actual USB COMM implementation of the hardware or the driver installer INF file is bad. That .Net would have problems with proper USB COMM hardware is a myth put into the world by lazy hardware manufacturers who do not want to bother about debugging their hardware and making it work properly.

 

My suspicion is that the USB COMM hardware of your device does not properly support some or all of the configuration methods such as setting the baud rate and other serial port parameters. NI-VISA and most other higher level APIs such as the .Net IO library will try to query these parameters on opening the port to properly initialize everything. And when that fails, it makes the port appear unsupported. There is no easy way to disable that in such APIs and it is actually unreasonable of hardware to require that this should be disabled. They should at least provide default implementations for these methods even if they intend to do nothing with it.

 

My conclusion would be that it is most likely very cheap hardware and I would doubt its actual measurement implementation too.

Rolf Kalbermatter
My Blog
Message 10 of 12
(2,572 Views)