How to close a serial port that is accidentally left open.

[ASH2020]

Hi all.

I have 2 vi's which will be running one after the other (not written yet so can't attach them). Let's call them A and B. They will both use the same serial port, Com1. When vi A is run, it will open the port and initialise it, then when the stop button is pressed, it will close the port and exit. Same thing with vi B. No problem so far.

However, suppose the user is running vi A and hits abort instead of stop, or there is a hardware error, the vi will crash, but leaving the port open. Is there a way to then close the port in vi B without having to quit Labview and start all over again?

Thanks

Andrew

[RavensFan]

I think you can just go ahead and close it.  Even if it is already closed, you can close it without error, and if it is open you can close it.

Give it a try.  I don't have it handy at the moment, but I think I just created a simple VI I could call up that I could pick a com port and just hit close.  And I never had problems with it.

I don't think it matters to LabVIEW if another LabVIEW VI had opened it.  I only needed it for when LabVIEW left a port hanging open and I needed to close it for when a non-LabVIEW application needed to access that same port.

[ASH2020]

Thanks for that. I must admit, I hadn't actually tried that. I've just assumed that the vi that opened it must be the one to close it. It seems to be that once a port is left open it isn't accessible from elsewhere. I'll give it a try though.

Cheers

[RavensFan]

You're right, but I don't think it is at the VI level, but at the application level.  Two VI's can access the same open port because they both exist in the same context as part of the LabVIEW development environment.  Now if one VI was within LabVIEW development, and the other is in an executable built from the LabVIEW IDE, that is within two different applications and would fail to open.

[Bob_Schor]

It really can depend on the instrument sending data.  We have some balances that communicate serially, sending strings that say "S S 12.345 g 10/26/2017 9:30 am" (where the first characters are "status" information, then weight and time).  We set the balances to start spitting out messages at 10 messages/second, and if the balances are not closed properly, they'll eventually "fill the buffer" and communications can go awry.

What we try to do is catch Aborts and Close requests (including Error exits) and have a shutdown of the Serial Ports, including telling VISA to clear its buffer.  Also, when we start the Balance, we open VISA, send the Balance a "Reset" command, close the Balance (all using sub-VIs that "hide the messy details), and then start it again (as before, doing another Reset).  This usually works ...

Bob Schor

[ASH2020]

Thanks. That's a clue. They are both going to be built executables eventually but for the time being it would be nice if they would both play nicely together!

[ASH2020 · Accepted solution]

Thanks Bob. That prompted me to reboot our hardware and, sure enough, the vi isn't the problem, it's the hardware at the other end of the wire. If I crash one vi, as long as I reboot the hardware, the other vi will run fine. So now all I have to do is reboot the hardware at the start of each vi and I should be OK.

Cheers

Andrew

[ASH2020]

Bob, just a minor point I noticed in your reply previously. You say you try to catch aborts and close requests. Please could you explain how you catch aborts, I thought that once the abort button had been pressed there wasn't anything you could do.

Thanks

Andrew

[JÞB]

---

@ASH2020 wrote:

Bob, just a minor point I noticed in your reply previously. You say you try to catch aborts and close requests. Please could you explain how you catch aborts, I thought that once the abort button had been pressed there wasn't anything you could do.

Thanks

Andrew

---

First, there should be no abort button in your executable

Now you only need to catch the Windows X in the top right corner.  You do this with an event structure and a case for the Application Close? Filter event.  Discard the event and perform a controlled shut-down that releases your resources (files ports whatnots)

Last there should be no such thing as the "User" accidentally leaving a port open.  You, as the application developer, should never let your user have accidents.

"All code is perfect! until you give it to a user!"

[Bob_Schor]

That's just "sloppy terminology".  I have never used the LabVIEW "Abort" function.  However, I have not infrequently used the term "Abort" (and have created a Boolean button called "Abort") which means "Branch over all other code and Go Directly To Exit".  What I was trying to say was that instead of also saying "Do not Collect $200", I tried to say "Clean up before you exit so it doesn't cost you $200".  [Sorry about the silly references ...]

Bob Schor