VISA Read hangs. Get Resetting VI dialog on abort.

[JÞB]

---

@SyrinxIndustrialElectronics wrote:

I have tested it verry wel now. this problem starts in visa read and hangs there.

the device i have connected is a usb to serial converter and i have connected the TX to the RX.

everything i send is every thing i read. and when it hangs i get a bluescreen BSOD.

the vi whit my test is attached.

---

Stop that!  You should not open and close VISA Sessions inside a loop.  Don't through out errors! Pass them to the next iteration on a Shift Register.  Your code has no means of stopping unless an error is seen at the case structure.  Open Sessions Then set the properties! You really are implicitly opening a session to the resource by calling the p-node and the Open Session will see that a session is open already and do nothing.  same on the next loop since you unecplicably close it just before iterating.   Of Course you only request to close the session (the OS will get around to cleaning it up eventually) so you may just get a handle to the stale, about to be closed by the OS, session that is late in being destroied when you call the P-node on the next iteration.  SO when the OS finds the time to service your request and destroys the session (That you are now using after requesting its destruction) Windows pulls the rug out from under you down the line.  Leaving you in an "unexpected state" right in the middle of a VISA transaction when the TMO value (and every other VISA Property) Poofs merrilly out of existance.

Stop That!

[SyrinxIndustrialElectronics]

@Albert.Geven

The problem is probably not visa but the usb to serial converter.

i dont think it is the serial converter, because we use it here for many applications.

but this is the first time i use it with labview and i get a error.

i've you have anotherone, can you test it for me? i already tested two different kind of converters.

whit the vi i've attached a 2 days back. 

just connect rx to tx.

and where i test with the visa components i get a bsod in 40 seconds

and whit the .NET i dont get a error in 2 hours. i will test it longer today

@Jeff·Þ·Bohrer

Stop that!  You should not open and close VISA Sessions inside a loop.

the reason why i'm doing that is, because it is a little part of my application.

and for trouble shooting i want to test only this part as many time as possible.

i didn't read in the help function of labview that the property node also open the connection.

thats the reason why i use p-node and Open.

thanks for your reaction

[guytesting]

I've been having the same isses here.  I'm using a USB to serial converter too to control an Associated Research UltraHypot III hipot tester running along side a USB-6525 Daq.

The system runs perfectly fine all day but after I go home towards the evening LabView will freeze and when trying to close the program I get the Resetting VI error.

Has anyone firgured out a solution to this problem?

Using LabView 8.5.

[MilanR]

Hi guytesting,

The "Resetting VI" message occurs when a thread is attempting to finish an "I/O, CIN, or DLL operation" as mentioned in the article What Does the "Resetting VI: (VI name)" Message Mean in LabVIEW?. In order to prevent the error message from occurring one would have to know what action is preventing the threads from exiting. When you try and close the program are you pressing the abort execution button? Usage of the abort execution button or Stop VI is discouraged because it can leave the VI in an unknown state. It is recommend that instead a button, functional global variable, etc. is used that can properly stop loops in the application and safely close connections to hardware. Because multiple I/O types are being used (DAQ and Serial) you have to determine what I/O or action is preventing LabVIEW from stopping to try and prevent the behavior.

[guytesting]

Quick question. 

I was told to not to run VISA commands inside a whileloop.  If so, then how do you keep the program running continuously if you don't have a whileloop?

[johnsold]

Who told you that?  What you do not want to do is to repeatedly open the session (configure) and close the session inside the loop.

Typically the configuration is before the loop, Reads and Writes are inside the loop, and Closing the VISA session occurs after the loop.

It is very rare to have in instrument communications porgram which does not use a loop.  If you use a state machine, everything is inside the loop because initialization (configuration) and shutdown (close session) are often states of the machine.

Lyn

[JÞB]

---

@guytesting wrote:

I've been having the same isses here.  I'm using a USB to serial converter too to control an Associated Research UltraHypot III hipot tester running along side a USB-6525 Daq.

The system runs perfectly fine all day but after I go home towards the evening LabView will freeze and when trying to close the program I get the Resetting VI error.

Has anyone firgured out a solution to this problem?

Using LabView 8.5.

---

Let me guess.  You are running this USB device on a Windows OS and hyou haven't changed the default power management options ?

I'd bet Kudos to donoughts that unchecking that box will help a bit

[sjrosen]

I am experiencing a similar issue with my system. We are running a VI that continuously communicates (for many minutes, or even hours) with several instruments. We recently modified the VI to include communication with a new instrument (an SR830 lock-in) over serial. At an arbitrary point in execution (usually 1 to 10 minutes in) after thousands of successful read/writes, this new version of the VI hangs indefinitely on a VISA read to the lock-in (at a different place in the code each time). Occasionally, we have seen LabVIEW crash or a system BSOD, but the hanging VI is the usual failure. We have not set the VISA timeout property, so I assume it should still be at its default value of 2000 ms.

We are using a USB-to-serial converter for the lock-in, but we are using the same converter for many other instruments as well, so the issue is unlikely to lie there. I have attached a trace log from one example of this hanging behavior. Please let me know if there's any other information i can supply that might be helpful.

[JÞB]

It looks like you tried to read 100,000 characters from COM31 @7367 and the read never returned is that the the new SR device?  whos usb to ser converter are you using?

[sjrosen]

Yes, COM31 is the new SRS box. The 100000 byte read is part of the LabVIEW drivers supplied by SRS. That read succeeds for hundreds or thousands of iterations before hanging, and it isn't always the culprit. We hang in a different place each time, but always on some attempt to read from COM31 (mostly on reads that ask for a small byte count like 20, rather than 100000).

The Serial-to-USB converter is from pluggable.