how to get access to a serial port after a labview crash?

[eximo]

Hi Knights and members!!!

It's happened to all of us, labview crashes in the middle of doing something, no big deal, restart the application and continue except.....

I had the visa resource open to a com port, (usb to serial) and now I can't get access to the com port.  After reading http://digital.ni.com/public.nsf/websearch/6807113B057FDE4C86256B41008212ED?opendocument&Submitted&&..., the article about how com ports are only able to be used by one application at a time i fear that the com port has been tied up by the previous instance of labview and is forever lost!

Currently I'm getting the error 

Error -1073807246 occurred at VISA Open .....

VISA:  (Hex 0xBFFF0072) The resource is valid, but VISA cannot currently access it.

I don't like answers that involve the words "unplug" or "reboot"  (perhaps that should become my signature  🙂  )

How do I get access to it again?

Is there a visa driver close?

[JÞB]

in 1000 words

Let LabVIEW automatically do it for you.

[eximo]

Yes, I've already done that, but it didn't work.  Sadly, even if I close labview and unplug the device, and plug it back in labview still thinks its valid but unaccessable.  The only time this has type of behavior happens is when one of theVIs causes a crash.  Sadly, I can't troubleshoot the crash if I have to reboot the computer every time I run the application.

The other way I can get it to release the port is by plugging the usb into a different usb port (not the same one), results in a new port address and i'm guessing a new instance

[JÞB]

---

eximo wrote:

The other way I can get it to release the port is by plugging the usb into a different usb port (not the same one), results in a new port address and i'm guessing a new instance

---

AHHHHHHH... silly Windows!  Silly, silly Virtual Com Port driver. 

While the FTDI VCP has some serious shortfalls, it a least behaves well for exception shutdowns.  I'm just guessing but you have a "Prolific" usb-ser converter? 

In other words this isn't a LabVIEW issue its a "Plug-n-Play" "Feature" and you need a better PnP implementation to get around it.

[gosenbach]

We have this exact same issue.  Is there a way anyone know of to force windows to give up the port via win32 dll calls or anything?

[eximo]

welll as it turns out, windows probably would have given up the gold except, when it was crashing each time (labview GUI dissapearing act) it wasn't unloading from memory.  Under the task manager i had 8 versions of labview running (one for each crash) 

In case you are wondering, i don't don't know what caused the crash, but performing a "replace subvi" from the right click menu with the same subvi fixed the problem

[gosenbach]

Hmm..  ok, I'll have to try that Automatically close VISA sessions option.  I wonder how well it will work though since I am having issues with VIs using VISA over proflic USB adaptors running in LabVIEW runtime and being called from TestStand...  🙂

I'll try to report back after I get an oppertunity to give it a try.

[falkpl]

I had a very bad experience with prolific usb driver, It actually always lead to a blue screen on windows (within a few hours depending on the frequency of the calls to visa).  I looked in the crash log files and chased it down to the prolific driver dll call.  Replaced the usb to serial converter with a different brand and the application is running without anm issue for over a year now.  This was not a Visa or Labview issue but some wierd compatability issue.

[gosenbach]

The problem we have is every once in a while if something wierd happens and the software gets bungled up and the teststand sequence stops executing before getting to the cleanup where the ports are closed, they remain open and then we cant close them because we lose the VISA handle.  the entire station generally requires a reboot.  I would like to figure out ho to make sure the ports get closed somehow so the station can get going again gracefully without rebooting..  the production guys don't like to hear the word "reboot"  🙂

[JÞB]

number one- get better hardware.  those prolifics are not designed for high reliability purposes.

2) windows power options (don't let Windows go green on you and shut down the USB hub.

3) the HUB- use a high quality externally powered hub (the one on the tower is the cheapest the mfg could find and was designed to support occaisional temporary conectivity) I have no affiliation with nor am I invested in Belkin but their products have worked well for me. 

4) the HUB again- Protect it! hide it, put a lock out mechanisim on it, whatever.  DO NOT allow users to plug anything else into your hub!!! if the device is USB 1.0 the whole hub may shift to slower speed, if its damaged the whole hub may see a surge (and reset)