the connection for the given session has been lost

[shda1]

I connecting to the IDRC DSP-300-02.5HR power supply via ethernet by VISA. After system starts connection is normal. I send commands and receive answers. But when I shutdown power supply and start it again VISA don't refresh information about it. Power supply obtain IP by DHCP, but even IP not changed I receive error "VISA: (Hex 0xBFFF00A6) The connection for the given session has been lost" when try to write command by VISA Write function. Information about visa resources in the system I obtain by VISA Find Resource vi. How to solve this problem?

PS Power supply connected to second Ethernet adapter in the system. 

[shda1]

Update.

I checked the connection of the power supply to both the first and second network cards. The result did not change.

[crossrulz]

I would try closing the VISA reference and then opening it up again.  VISA likely need to establish a new TCP connection.

[mikeporter · Accepted solution]

Yes, what you describe is expected behavior. When you turn off the power supply the connection is broken and has to be reestablished. How often do you need to.communicate with this device? It might be more efficient to open a connection, do what you need to do, and then close the connection.

Mike...

[shda1]

---

@crossrulz wrote:

I would try closing the VISA reference and then opening it up again.  VISA likely need to establish a new TCP connection.

---

After VISA Find Resource I use VISA Open, then VISA Write, VISA Read and VISA Close. It gives nothing. New connection establish only after restart LabView.

Can I restart VISA programmatically without restart LabView?

PS I tried to work with the power supply via the TCP connection. Everything is good except for auto-detection.

[Hooovahh]

It really sounds like an error is happening, and that error is preventing the clean-up process, which would close that session, releasing that hardware, and allowing a new session to be made again.  Post your code and we can try to determine why the close operation isn't happening.  But I agree with mikeporter in this situation.  If the power the device might come and go at uncontrollable times, and the operations are small, it might be a better design to open a session, perform the action, and then close it.

[buttersworth]

Adding my experience for anyone encountering this problem. I wasn't able to close the visa session (gave me a different error). Clearing the buffer seemed to solve the problem though.

[Tomwell17]

I would like to add my input as I just solved my issues on this topic. 

I have a weather station that uses Serial Modbus to communicate with LabVIEW, through a RS485 to USB converter. I previously tried to use a case structure to build a methodical reconnection process but it never worked. Just like in the post from Proven Zealot, the issue was that there was not a clean process to close the session and release the hardware. Therefore, it would throw errors during reconnection.

The solution that I chose was to open the Modbus connection, read the desired registers, and immediately close it. This works in my case because I do not do any data collection faster than a minute (I tested that it is fast enough at 15 seconds of elapsed time in idle). I also saw from another post that error handling for Modbus is a big role as well to ensure that the program does not get stuck. I disconnected the error wire from the shift register and just have the error message reading out to the front panel, staying inside the while loop of the data collection. The picture attached is a screenshot of the block diagram in case people are more visual.

I hope this helps if anyone else comes by!