LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

serial port

I have just upgraded to Labview 2011, running this on Windows 7, and running Labview RT 11 on a PXIe-8133, with NI-RT Serial 3.8.0 for a PXI-8430/16.  Previously I was running Labview 2010 on Windows 7.

 

After I installed Labview on the PXIe-8133, it appears that the default numbering for my serial ports has changed.

 

Previously, the serial port on the PXIe-8133 was COM1, and PORT1 of the PXI-8430/16 serial card was COM2, and numbered sequentially.

 

Now, PORT1 of the PXI-8430/16 is COM3, as shown in the attached MAX screen shot.

 


This is resulting in an VISA error 0xBFFF0011 after trying serial activities to COM2 (which seems to make sense).

 

 

Why has this changed? and can something be done to restore the old numbering and to ensure consistent enumeration?

 

0 Kudos
Message 1 of 12
(4,841 Views)

I am really sorry for the bad subject -- I thought that it posted with a different topic name.  The full topic of this post should be "Serial port enumeration on Labview 2011 RT"

0 Kudos
Message 2 of 12
(4,840 Views)

The serial port number has nothing to do with LabVIEW, as it's not controlled by it. Your screenshot does show a COM1 already there. What is that resource?

0 Kudos
Message 3 of 12
(4,835 Views)

The serial port number has everything to do with the Labview RT operating system, right?  Remember, I am running Labview RT on the PXIe-8133 controller.  The screen shot you see is from the host machine which is running Windows 7.

 

The resource name of COM1 is visa://192.168.1.21/ASRL1::INSTR

 

The resource name of COM3 is visa://192.168.1.21/ASRL3::INSTR

 

 

0 Kudos
Message 4 of 12
(4,824 Views)

Gregoryng,

 

Here is a link to some information from our site that I believe will be useful for your project.

 

http://ae.natinst.com/public.nsf/web/searchinternal/8cf2cc91e5ee54b086256e9000689894?OpenDocument

 

If for some reason that link does not work, go to www.ni.com and type in "port settings com retained" into the search bar on the upper righthand corner. The document should be the first in the list of search results.

 

Regards,

Renee

Applications Engineer

National Instruments

Regards,

Renée M
Applications Engineer
National Instruments
0 Kudos
Message 5 of 12
(4,758 Views)

Thanks for looking into the knowledge base for me.  This KB article appears to be relevant for Windows.  I am not sure that the information can be translated to be applicable to the real time operating system on the PXI controller.

 

I did try the advice in the article to go to MAX and try the "Tools -> NI Serial -> Recover Unused COM Numbers" menu command, but this did nothing.  The ports are still numbered the same.  I have a feeling that the command only works for the local machine, because it asked me to run MAX as administrator when I did that.

 

I think that there may be a more fundamental subsystem issue occurring which i have no expertise in.  You will notice from a previous post that I mentioned the VISA path of the first port on the card is visa://192.168.1.21/ASRL3::INSTR .  This VISA string is actually how I enumerate the ports in my software.  So I don't know how this path is assigned but I bet that might be at issue.  

 

Is there perhaps a phantom device occupying ASRL2?  (The error message when running says "device not found" or something similar, so I think this is probably not the case) Has this resource for some reason been reserved in LVRT 2011?  Perhaps it is an interaction with the PXI-8133e?  All just conjectures.

 

 

 

 

0 Kudos
Message 6 of 12
(4,743 Views)

Renee,

 

The link you posted is not accessible to anyone outside of National Instruments.  ae.natinst.com is a private domain only available to employees.

0 Kudos
Message 7 of 12
(4,710 Views)

Hello gregoryng,

 

First, be sure the PXI chassis is turned on before booting up the computer. Serial boards are assigned COM ports on installation. With the serial boards in a PXI chassis, if the computer was booted with the PXI chassis off, and then re-booted with the PXI chassis on, the overall effect of this is the same as if the serial boards were physically removed and then reinstalled. Therefore, it is this effective "reinstallation" of the serial boards that caused the COM ports to be reassigned. The VISA addresses you list are correctly formatted, as the PC will first recognize the network location, and then the port. This Knowledge Base article describes why some PXIe boards will receive new serial port assignments.

 

Regards,

Deborah Y.

Deborah Burke
NI Hardware and Drivers Product Manager
Certified LabVIEW Architect
0 Kudos
Message 8 of 12
(4,697 Views)

Deborah,

 

This is an interesting explanation.  But I am a bit confused about the mechanism that would be behind your explanation, and I would be hesitant to accept your explanation without some elaboration on the underlying mechanism. 

 

In my case, I have a PXIe-1075 chassis with a PXIe-8133RT controller in it.  The PXIe-8133RT controller runs the full LVRT real-time operating system.  You said, "be sure the PXI chassis is turned on before booting up the computer."  By "computer", I assume that you mean the host PC (running Labview for Windows) which is deploying an application to my real-time controller. Can you explain how the presence or absence of the Labview for Windows PC on the ethernet network can affect the VISA numbering on the real-time controller?  If this were the case, it would be a rather suspicious dependency in the operating system software stack.

 

You should also keep in mind that I have always had the Host PC booted before the RT controller when previously (before LV 2011) using the controller, and previously, I have often remotely rebooted the PXIe-8133RT controller from the host PC.

 

In any case, I tried your suggestion.  I shut down my host PC and the PXIe chassis/controller.  Then I turned on the PXIe controller, allowed it to completely boot, and then turned on the host PC.  I used the host PC's MAX to find the PXIe controller on the network, and I got the same result as above. 

 

I don't currently have a PXI-8133RT running LVRT 10, but I do have a PXI-8130 running LVRT 9.0.  But I assure you that when I ran the PXI-8133RT with Labview RT 10, the same behavior occurred as the PXI-8130 running LVRT 9.0.  I swapped this controller into the chassis and powered it on (while the Host PC has been running the whole time) I have attached a screen shot from MAX that shows that the VISA resources came up differently, even though they are installed in the same chassis with the same cards.  Both PXI controllers have one serial port built-in to the front panel (which in both cases comes up as COM1)


My expectation of software behavior is that the mapping of VISA resources to hardware resources is should be consistent from version to version of the RTOS.  

 

0 Kudos
Message 9 of 12
(4,678 Views)

Hello Gregoryng,

 

I appreciate the extra details. When upgrading to RT 2011 on the PIXe-8133 did you just push the new software over through MAX or complete a full reformat? It seems like there may be some remnant of what was reserved from 2010 that may be manifesting itself as a phantom that can't be found. The next step I would try is to reformat the controller, add RT 2011, and repair the PXI Platform Services Driver.

 

Thank you,

Deborah Y.

Deborah Burke
NI Hardware and Drivers Product Manager
Certified LabVIEW Architect
0 Kudos
Message 10 of 12
(4,644 Views)