Re : Executable does not release serial port after being stopped

[LazerBoi64]

Greetings:

I have created an executable that communicates through a serial port.  However, if I stop the executable (not close it), the executable still has control over the COM port.  This causes issues if I need to jump on Hyperterminal to send a couple quick queries to my system.  In order to send the queries, I have to actually close the executable in order to release the COM port.  It's problematic because I then have to start the executable back up, go through another configuration query, etc. and there are parameters from the previous run I would prefer to not lose.

Is there a way to force a LabView executable into releasing it's hold on a COM port after it's stopped, without closing the executable completely?  If it makes a difference, I'm using LV 7.1 on a WinXP machine.  Thanks for any help!

[nathand]

Try setting the "Automatically close VISA sessions" option. Or, add a VISA Close to the end of your application, although that will not close the session if you abort execution of your VI (using the toolbar STOP button).

EDIT: Sorry, read too quickly, didn't realize you were referring specifically to a compiled application. In that case, try using VISA Close to release the serial port when you stop your application.

[GerdW]

Hi Gumby,

---

I stop the executable (not close it)

---

Why don't you close the executable when it is stopped? That's the main point here...

How do you stop the executable?

[Eric.M]

Hey,

VISA sessions are not closed automatically when the calling VI (or exe) goes idle and/or is stopped. This is where you need to :

- handle various cases that quit your application

- Add a VISA Close and make sure you execute it when you close your application

Regards,

[LazerBoi64]

I changed the settings to have the stop button visible in the menu bar along with the start button.  This is because the user has to select their COM port before continuing.  If I let the executable run on startup, it will error out for no port being selected and then the user has to restart it anyway.  This way, I force them into selecting it at the beginning.  It can't be a fixed value because of different computers, different number of ports available, etc.

With regard to automatically closing VISA sessions, I thought I had that selected, but will double check.

Thanks for the suggestions!

[RavensFan]

This is where a proper user interface will allow the program to always run, but handle errors or changes in the com port.

Your VI should be something that begins running, but doesn't go into a mode where it works with the com port until after someone changes the settings, or presses some sort of Go button, or Open port button in your VI.

Have an event structure that if someone changes the com port, it will properly close down down the current VISA resource and open another.

Also have a Close port button that will allow a person to close the current com port, yet still keep the VI running, waiting for the user's next actions.

[Hooovahh]

---

@gumby_Dammit wrote:

I changed the settings to have the stop button visible in the menu bar along with the start button.  This is because the user has to select their COM port before continuing.  

---

Raven has already said it but I'll say it a different way.  No user should ever interact with the front panel unless the VI is running.  And when it is running the user should never have access to the abort button in the toolbar.  When you open Internet Explorer do you first need to click the run button?  No it runs when you run it.  Write your program so it is always running, and doesn't have an abort so if the user closes the program you can run the proper clean up like closing COM ports.

[JÞB]

---

@Hooovahh wrote:

---

@gumby_Dammit wrote:

I changed the settings to have the stop button visible in the menu bar along with the start button.  This is because the user has to select their COM port before continuing.  

---

Raven has already said it but I'll say it a different way.  No user should ever interact with the front panel unless the VI is running.  And when it is running the user should never have access to the abort button in the toolbar.  When you open Internet Explorer do you first need to click the run button?  No it runs when you run it.  Write your program so it is always running, and doesn't have an abort so if the user closes the program you can run the proper clean up like closing COM ports.

---

And exiting the application.  (having a dead application sitting idle is sort of pointless unless you are doing some debugging.  don't write bugs and you don't have to worry about pointless application states

[JOHNNA]

Is this final solution to this issue? "Design a app without pointless states"

[Hooovahh]

I'd phrase it different, but sure.  The solution is to write an application that starts running when executed, and cleans up when it is asked to close. That might be a bit broad of a statement but I think it states what we've suggested.  The extra steps aren't always pointless.  As Raven mentioned you may want to run an application in more of a debug mode where it doesn't run on startup, or exit on close.  But as a user you bet I want it to do those things.