I have been using Pico 4224 and more recently 4227 for a few years, and I am programming with LabVIEW.I work with one scope at a time, and I had notice that the handle returned by the dll function call that opens a connection to the scope was typically always 0 or sometimes 1.

Based on this, in my code, I would run a loop on handles = 0 to 5 (just to be safe) and run a Close function call, to insure no handle was left open by mistake.

Now on the latest 4227 I got, I noticed a handle value of 16394. Are you aware of any changes made in the firmware or dll driver? Is there some rule behind the handle number generation ? Thx.

I had situations where an error would occur and the handle would remain "active", and it would become impossible to re-open a connection unless the scope USB cable is unplugged/replugged. This is not possible in some situation, and the most successful approach I used was to preempt the issue by first closing handles 0 to 5, just to be sure.

Is Pico aware of at least what is the expected range of handles produced by the driver?

From what your saying, is either:Whatever handle is given, closing 0 to 5 clears connection issues?orIf 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.

Also: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.