Maybe I misunderstand the issue?
From what your saying, is either:
Whatever handle is given, closing 0 to 5 clears connection issues?
If a scope stops responding, you try to re-open using the given handle, rather than closing it first?
I'm assuming the latter, by which closing the driver handle first is the correct action if the connection has failed.
There's no need to close them all - just the failed connection.
You had a handle of '16394' - trying connections, I've had greater and lesser, not necessarily in any real order.
As an aside:
It's best to write your code to handle 'handles' dynamically. Not only from a tidy-code/readabillity point or expandability point, but to handle such issues as above with minimal effort.
My code typically consists of:
- Create Handle Array (to remember all handles)
- OpenCode (When connecting to a scope, a handle is generated/returned and I add it to my array - this is always needed to actually talk to the scope, so if your talking to many scopes, you have many handles)
- TalkCode (again, I have a list of handles, so I tell the driver to get or set info with handle, of which a particular scope that the driver assigned a handle will respond. Here, If a scope fails because I've told it something silly, I'll close that handle and re-open. The new handle gets added to my array in the OpenCode, in which TalkCode just uses what that array lists.)
- CloseCode (I can close any scope in any order, using my handle array)
The handles assigned are moot point, so far as it could give you any number, be it 1 or 10000, it's just it's 'ticket' for this session, issued by the driver. Tomorrow, the 'tickets' (handles) could be issued in a different order.
If you wanted to be clever, your code could differentiate the scopes by requesting their serial numbers, then with a look-up, tie the handle to the serial, then request data in the physical order you have assembled your experiment.
This way, no matter what order they are initialized and whatever handle they are given, you know who is who.