Jump to content
Sign in to follow this  
BrokenArrow

Relinquishing LabVIEW's hold on the serial port

Recommended Posts

Hello all,

Once LabVIEW takes control of the serial port (sets it up, starts reading and writing to it) it doesn't want to let go, even if you've closed VISA, etc.

In my experience, when your hardware freezes up (lets say due to a bad command sent to a device), you have to quit LabVIEW and restart. No number of serial port stops, breaks, closes will make it re-open the port with success. You have to close LV. On a similar note, If you've started LabVIEW and had any kind of serial comm going on, you have to quit LabVIEW in order to use Hyperterminal (or anything else). These two scenarios are related in that I don't know why LabVIEW holds the port hostage.

Is there a way, while LV is still up and running, to simulate whatever is happening when LV closes and opens?

Thanks,

Richard

Share this post


Link to post
Share on other sites

QUOTE (BrokenArrow @ Oct 28 2008, 10:30 AM)

Hello all,

Once LabVIEW takes control of the serial port (sets it up, starts reading and writing to it) it doesn't want to let go, even if you've closed VISA, etc.

In my experience, when your hardware freezes up (lets say due to a bad command sent to a device), you have to quit LabVIEW and restart. No number of serial port stops, breaks, closes will make it re-open the port with success. You have to close LV. On a similar note, If you've started LabVIEW and had any kind of serial comm going on, you have to quit LabVIEW in order to use Hyperterminal (or anything else). These two scenarios are related in that I don't know why LabVIEW holds the port hostage.

Is there a way, while LV is still up and running, to simulate whatever is happening when LV closes and opens?

VISA Close works just fine for me, but other VISA calls will auto-open the port. Therefore you have to make sure that after closing, you don't call any other VISA functions on the port, even in other loops. I just tried it again.

Write some characters to COM1, and I can't open my terminal (PuTTY). Run VISA close, and then it opens OK. Can you post some sample code?

Share this post


Link to post
Share on other sites

QUOTE (jdunham @ Oct 28 2008, 11:14 AM)

VISA Close works just fine for me...

Me Too.

Share this post


Link to post
Share on other sites

QUOTE (jdunham @ Oct 28 2008, 02:14 PM)

VISA Close works just fine for me, but other VISA calls will auto-open the port. Therefore you have to make sure that after closing, you don't call any other VISA functions on the port, even in other loops. I just tried it again.

Write some characters to COM1, and I can't open my terminal (PuTTY). Run VISA close, and then it opens OK. Can you post some sample code?

Thanks jdunham. I think you are spot on. I don't have the code with me at the moment, but the state machine takes us back to Idle where there's a Bytes at Port that runs once every few seconds, maybe that's what's reopening the port. I bet that's it. I need to wrap that in a False statement if the user has tried to re-link to the port.

Overzealous use of the Abort button is also to blame. I need to hide it. :ninja:

Share this post


Link to post
Share on other sites

QUOTE (BrokenArrow @ Oct 28 2008, 12:25 PM)

Thanks jdunham. I think you are spot on. I don't have the code with me at the moment, but the state machine takes us back to Idle where there's a Bytes at Port that runs once every few seconds, maybe that's what's reopening the port. I bet that's it. I need to wrap that in a False statement if the user has tried to re-link to the port.

It could also be caused by poorly-written drivers for your USB-to-serial converter (or serial-port PCI card) if you've got anything like that in the loop.

Share this post


Link to post
Share on other sites

QUOTE (Justin Goeres @ Oct 28 2008, 05:26 PM)

It could also be caused by poorly-written drivers for your USB-to-serial converter (or serial-port PCI card) if you've got anything like that in the loop.

This last program does use hardware with a "virtual com port". It's giving me fits. I'd like to be able to have a "rescue" button to reset comm with it, but when it locks up, so does my program.

Share this post


Link to post
Share on other sites

QUOTE (BrokenArrow @ Oct 28 2008, 07:04 PM)

This last program does use hardware with a "virtual com port". It's giving me fits. I'd like to be able to have a "rescue" button to reset comm with it, but when it locks up, so does my program.

Could it be that you have an long timeout, like never, on a visa component that is waiting for a response from the closed port?

Just a thought,

Jason

Share this post


Link to post
Share on other sites

QUOTE (jasonw @ Oct 29 2008, 03:27 PM)

Could it be that you have an long timeout, like never, on a visa component that is waiting for a response from the closed port?

Just a thought,

Jason

Good troubleshooting point, but I do report timeouts (10 seconds) and give an option to quit the program or close VISA + reinit the port.

I found the main issue with this one program: A PWM output was being set with a prescaler that was causing the cycle to be on the order of a few hours! That gave it the illusion that it was locked up.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.