Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

viOpen returns the error code −1073807194 after instrument reboot

We are using Visual Basic code to control our own instruments via VISA over TCP/IP. After performing some calibration process, we need to reboot the instrument. We close the VISA session before power cycling the instrument. When we recreate a VISA session using viOpen, we end up with error code −1073807194 i/e. "The connection for the given session has been lost". This does not happen always!!! Once this error code is seen though, we can continuously try to reconnect but we continue to get the same access code. However, another VISA session through another copy of the application from the same machine works just fine. Has anyone else experienced this weird behavior? Needless to say, the TCP/IP connectivity between the PC running VISA and the instrument is good. Any ideas will be greatly appreciated as this problem is driving me crazy.
0 Kudos
Message 1 of 7
(6,482 Views)
Did you allready try to add some additional delay between the viClose and the reboot ? The idea is that  viClose works asyncronously and there is still some work to do for shutting down the TCP-IP connection when viClose returns. If you reboot before the shutdown of the TCP-IP connection you will get the error condition.  However I'am not really familiar with the inner workings of VISA . So the asyncronous operation is only a guess.
0 Kudos
Message 2 of 7
(6,474 Views)
Can you attach your vi?
0 Kudos
Message 3 of 7
(6,467 Views)
First of all thanks for your quick response. Yes! We had delay of 1 sec. We increased it to 5 secs yesterday but have not been able to test it after this change as of yet. We will test it this morning, US time. I did not know that viClose is an Asynch call. I am not a VISA person; is there away to complete the call synchronously or better yet to test that the connection has really closed by making some harmless call before sending the reboot command to the instrument.
0 Kudos
Message 4 of 7
(6,458 Views)

Hi Dan,

 

The TCP connection should be pretty simple in code and I'm not finding anything on that error.  I was wondering if you could post a small portion of the code that covers the openning and closing of the connection as you have it in your code. That way I can try to replicate what is occuring.

Ryan T
National Instruments
Applications Engineer
0 Kudos
Message 5 of 7
(6,439 Views)

Hi Ryan,

 

It looked like that the problem had been resolved but it popped up again. I was waiting for confirmation of the status of the issue before responding. We found that in one scenario where the problem could be reproduced easily, we were not closing the vi session/RM session. Once we took care of that, that particular problem disappeared. The other occurrence is still a mystery. Here is a question that perhaps you can answer easily -What is the best way to work in situations where the instrument gets rebooted but the remote application continues? Should we close the default RM as well as vi session or only only one (defaultRM only) or none before sending the reboot command. And is there anything we can do after the instrument is rebooted which resets the state of the vi connectivity completely beyond what viOpen command achieves. The reason for this question is that another application session from the same host works well, so is there a way that I can get my application to behave as if it is building a brand-new connection with the VISA RM etc. and that the state of the previous connection should be completely wiped clean. If such a thing exists, that will serve as a good workaround for now.     

0 Kudos
Message 6 of 7
(6,398 Views)

Hi Dan,

 

The best practice is to close the instrument session, but not the resource manager session.

 

Thanks

Ryan T
National Instruments
Applications Engineer
0 Kudos
Message 7 of 7
(6,304 Views)