Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

error opening COM ports with VISA when system is first started

Greetings. I am writing a simple application to read data being streamed to a serial port from a device.

Problem: Unless another application (eg, HyperTerminal) opens the serial port first, the application cannot access the serial port and prevents all other applications from accessing it until the PC is rebooted.

When executing my application, I get the following error:

Error -1073807246 occurred at VISA Open in VISA - serialExample.vi.
Possible reasons:
VISA: (Hex 0xBFFF0072) The resource is valid, but VISA cannot currently access it.


LabVIEW 6.1
VISA serial interface.

I've included the application as an attachment to this post.

Any ideas?

Dennis Jackson
0 Kudos
Message 1 of 9
(5,843 Views)
Dennis,

either another part of your code or another thread (yours, MAX, whatsever) has opened the port. This error message means, that your resource description is OK.
0 Kudos
Message 2 of 9
(5,836 Views)
That's the thing -- no other thread or software is running. I reboot the computer and the first thing I do is open my application. That VI is the only thing running and I get the results I described above.

Dennis
0 Kudos
Message 3 of 9
(5,836 Views)
And MAX itself?
MAX is started whenever a new VI with device descriptors is loaded. This is to fill the device descriptor selection box. Maybe you must wait a little longer before trying to access the port. You may as well open the taskmanager or something else and have a look for a task named NIMAX (do not know if this is the correct spelling), if it is active and using a fair amount of CPU cycles. If so, just wait.

There was a huge discussion on this topic on info labVIEW about one or two years ago, maybe with LV61. NI changed the behaviour later.

What you can do now is to do a VISA device search with an apropriate filter. Search for serial devices only, maybe just for your port. Unfortunately I have no LV availabel at this moment, so you have to find the proper path to a VI named 'VISA find resources' or so, yourself. This one would force MAX to locate the port and to release it afterwards.
This might help!

Greetings from Germany!
--
Uwe
0 Kudos
Message 4 of 9
(5,830 Views)
I believe I have determined the source of the problem.

The device I am using is a Nonin Integrated Pulse Oximtery Device; it requires a 9V battery in order to operate. If the battery is connected when the PC is booted, the PC cannot access the serial port. If it is not, then the PC can. Why? I do not know.

Problem seems solved for now.

Thanks for the ideas.

(Greetings from NH)

Dennis
0 Kudos
Message 5 of 9
(5,828 Views)
Dennis:
I noticed this thread regarding utilizing Nonin's Pulse Ox from a year ago and wondered if you ever discovered what the issues were in regards to why the data collection did or did not work correctly.  I seem to be getting the same screwed up data but can alleviate if I change the order of connection or stop/start the VI a couple of times.
thanks
Jan
0 Kudos
Message 6 of 9
(5,589 Views)
Jan-
Sorry but I don't remember discovering anything else about this issue besides making sure the device was not powered before starting the PC.  Since the device is constantly streaming data maybe MAX cannot properly access the port.

Unfortunately, I moved on to another company so I no longer have access to that setup and equipement.

-dennis.
(now in CA)

0 Kudos
Message 7 of 9
(5,585 Views)

This thread is years old, but it was the only relevant one I could find on NI site for this problem, so I'll hijack it to add what I think the problem was, and to comment about its solution. I hope this may help others!

 

There is a common reason for this error under XP, which is trivial, and took me a long time to identify.

 

If windows at boot finds a serial device already transmitting data, it may incorrectly identify it as serial mouse (usually: "Microsoft Ball Point"). In this case, the port becomes inaccessible to VISA, and as an addtitional symptom, the mouse may become very jerky, depending on what data the device sends out. A lot of serial devices just work dumping out data at constant rate, or it may happen that the host computer is rebooted while they are already transmitting. Going to the Device Manager and disabling and reenabling the relevant port solves the problem, but just until the next reboot.

 

There are a few workarounds suggested on the net to tackle the problem permanently. The one, which worked for me, is to let windows identify once the device as serial mouse, and then disable it as such in the Device Manager. Other workarounds I've found suggest to add the option /NoSerialMouse to the file boot.ini, but conflict about syntax proposed and with regards to OS applicable.

 

A few links out there:

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q...

http://www.pcmaritime.co.uk/leisure/support/jumpingmouse.html

 

HTH, Enrico

 

Message 8 of 9
(4,980 Views)

In fact, there is this

 

http://digital.ni.com/public.nsf/allkb/73657DE26CE76D8686256C44007D9439

 

but it talks about 2000, and about editing the register. Probably not relevant to XP.

0 Kudos
Message 9 of 9
(4,964 Views)