VISA RS232 read freeze -> LV stuck on "resetting vi" -> VISA resource inaccessib

[mkossmann]

Is the USB to serial converter still OK in Windows device manager, when the problem shows up  ?

Did you try to deactivate/activate it there ?

There are only a few manufactorers of USB to serial chips and these chips a sold under different brands. So even if you tried two different brands to may have used the same chip/driver.  

[giacomociani]

---

@Dennis_Knutson wrote:
No. If you request 20 bytes and the VISA Read returns 10 without a timeout error, it is detecting a termination character.

---

My bad. You are right! I hand't realized it before. In the light of this, I did change my program to always check how many bytes are available and never ask for more (this way, even if the instrument is not transmitting as it is supposed to do, or the cable is disconnected, the program will not freeze).

Still, I wish that when I abort a program, it will really abort instead of hanging on "resetting VI...".

Thanks

Giacomo

[giacomociani]

---

@mkossmann wrote:

Is the USB to serial converter still OK in Windows device manager, when the problem shows up  ?

Did you try to deactivate/activate it there ?

There are only a few manufactorers of USB to serial chips and these chips a sold under different brands. So even if you tried two different brands to may have used the same chip/driver.  

---

I don't remember exactly the details (and can't try right now), but I remember trying everything: resetting the adapter, disconnecting and reconneting, unistalling and reinstalling.... some of the actions don't change anything, other require to reboot to complete, so they are no goo either...

I see your point about the chips, but at this point it's not clear to me if it's a problem with the adapter or not. It is true that I shouldn't be asking to read bytes that don't exist in the buffer in the first palce... still, it seems an error small enough not to require the rebooting of the system to recover!

Giacomo

[partial]

Dear giacomociani,

I have the same problem as you (it is a very annoying problem due to its arbitrary nature).

But the explanation of EccentRick and the successful modification of your code seem to be a solution for this.

Now I want to modify my code too. Unfortunately, you did not mention detailed how you modified your code.

Could you (or the other participants of this discussion) please explain this a bit more in detail (or could you post the newest version of your code)?

I would be very happy to get a reply!

[giacomociani]

Hi Partial. Please find attached a snapshot of my routine. I think it's pretty self explanatory. (if the case structure is false, nothing is done and the values are just passed ot the output nodes).

Let me know if yuo need any clarification.

Giacomo

[partial]

Dear Giacomociani,

Thank your for your reply and help.

In the meantime I found this/a similar solution too (by the help of some similar topics here).

But when I tried the same solution as you, my program still froze (but more seldom). I can’t tell you how disappointed and annoyed I was!

But I could fix this in the following way (see also attached picture):

As you, I check if I have more than 0 (in my case 15) Bytes at Port. If so, I use the VISA read, but instead of using a fixed number of byte count at the VISA read input, I read only as many bytes as Bytes at Port returns.

Since then my program never froze again!!

I also want to mention that I had the freezing problem only with LabVIEW on Windows8, never with LabVIEW on Windows7 (perhaps it is not a question of the operation system but of the different hardware I use for my Windows7 and 8 computers).

Anyway, with your/my modified solution the freezing problem totally disappeared!

[giacomociani]

Glad it worked!

Just for the record:

- my problem was on windows 7

- i read a fixed number of bytes because I have reason to believe that they should always be there (if there are more than 0), but your solution si certainly more robust

[ErikMansson2]

Hi all,

I made two comments and attached a test VI on page 8 of a thread about very similar issues: https://forums.ni.com/t5/Instrument-Control-GPIB-Serial/VISA-Read-hangs-Get-Resetting-VI-dialog-on-a...

Basically, I have one serial-over-ethernet (virtual COM port) where Read does not respect a timeout setting (the VI and LabView freezes if the device is not sending enough data). But I also have other COM ports directly in the computer, and a MOXA PCIe card with four COM ports. These other drivers are respecting timeouts.

So beyond basic configuration and programmer mistakes, it is quite likely that issues with serial communication via any kind of adaptor/extender are caused by its driver not working as NI VISA desires/expects, or not supporting all functionality.

For this particular timeout issue, the workaround already explained by others and seen in Giacomo's PressuresVI.PNG, is to check the number of bytes at port and only call Read when it is certain to have data to return.