Labview installation / background processes interfering with Serial Port (COM1)

[Steve76]

Hello-

We are running a Windows XP PC that communicates with several different instruments through several different busses (USB, serial, TCP/IP, etc.). We communicate with one of the instruments (an Agilent device) through the COM1 serial port using a piece of software from the instrument manufacturer. This was working fine, but after I recently installed Labview, it has ceased to work - the program produces a communications error. This occurs whether or not Labview, MAX or anything else is running. We have checked the COM1 settings through the Windows Device Mgr and also through MAX, and they all look okay (19200 baud, 8 data, no parity, 1 stop bit, no flow ctrl). 

I notice that several processes that start with "ni" are running on the system in the background, even when none of the NI applications have been started. Could one of these be interfering with communications on COM1?

Perhaps relatedly, after installing Labview we had another (Agilent) device that did not work, even when no NI applications were running, in this case a USB device that we communicate with using a VISA library and C code. We discovered that this was a VISA aliasing problem, albeit a weird one:  Agilent's diagnostic program identified the device with the correct VISA alias. However, exploring the device in MAX revealed that MAX had not assigned an alias to the device. When we set the alias correctly within MAX, the C code talking to the USB device worked again. Thus I conclude that somehow, even though Agilent's program had correctly assigned the alias, MAX overrode this setting with no alias assigned, even when MAX was not running.

I am not sure if the two issues are related. As I said, we checked the COM1 settings in MAX and they look okay; I can't see a comparable aliasing issue.

Can anyone explain what Labview / MAX / NI code are doing in the background regarding communication ports? Can I disable whatever they are doing? I only need Labview on occasion, and only to talk to a PXI device over Ethernet.

Thanks in advance for your help,
Steve

[Scott-M]

I would try reinstalling the drivers for your agilent device, the com ports should not be reserved by any NI software so it seems more likley that the drivers have been altered by the LabVIEW install, a reinstall should fix this.

Scott M

[Steve76]

Hi Scott M-

Thanks for the reply. I got a similar reply through NI support. They pointed out that most likely NI-VISA was overwriting Agilent VISA, and presented several options for side-by-side VISA installations (including using NI as primary or Agilent as primary). As it turned out, I could only get it to work with Agilent as the primary VISA installation. This may later have a negative impact on my ability to use NI-VISA devices, but for now I don't need that, so it should work fine, and it appears to so far.

Thanks for your help,
Steve

[Scott-M]

I found these instruction for VISA side-by-side operation, I'm not sure what you saw before but these might be worth a look:

In a versions of Agilents VISA software (after version K), they have a compatibility mode that allows their VISA to operate as a secondary VISA when another VISA is already installed. Then, Agilent applications should be set to work with Agilent's VISA, instead of the default. All other applications (including LabVIEW) will use the default VISA. More information can be found on page 35 of the Agilent IO Libraries Suite Getting Started Guide, which can be found here:

http://cpliterature.product.agilent.com/litweb/pdf/E2094-90004.pdf

You would have to install NI-VISA first as your primary. Then, reinstall your Agilent VISA in side-by-side mode as outlined in the above document. Finally, your Agilent applications may require that you select communication with Agilent VISA instead of the default VISA (which will be NI VISA).

Scott M.