Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for GPIB Device Connecting? #344

Open
roboguy222 opened this issue Apr 26, 2016 · 8 comments
Open

Suggestions for GPIB Device Connecting? #344

roboguy222 opened this issue Apr 26, 2016 · 8 comments

Comments

@roboguy222
Copy link

I am using your GPIB Bus Server and your GPIB Device Manager, and have run into the following problem:

When a new device is connected, and we refresh the devices using the GPIB Bus Server, a named message "GPIB Device Connect" is sent out. The GPIB Device Manager hears this message and starts querying the device for it's name, etc. The problem lies when we have another server that hears this device connected message and asks the device manager for the available devices. Since it takes the device manager time to query the device for it's name, the new device does not show up until after the other server asks the device manager.

The obvious way to fix this would be to refresh the devices, and then wait some time before asking the device manager for its devices. This seems clumsy, though. Is there a better way to do this?

@pomalley
Copy link
Contributor

I believe the GPID Device Manager has a named message that it sends out when it identifies (or fails to ID) a new device. The other server should listen for that message instead.

An easier approach would be to use subclass the device server, which handles much of this stuff for you, especially if your devices responds to *IDN?. Let me pull up an example for you...

@pomalley
Copy link
Contributor

Sorry, I meant to say "managed server" not "device server", to get the lingo correct.

Take a look at the Lakeshore 218 server as an example: https://github.com/martinisgroup/servers/blob/master/lakeshore218.py

Does this make sense?

@roboguy222
Copy link
Author

Yep, I am using the GPIBManagedServer already for my devices. The "other server" I was talking about is a server that manages a lot of devices, not represents one. The device manager doesn't have named messages it sends out, but on closer inspection, it looks like I can subscribe to messages about certain devices, which should work.

@pomalley
Copy link
Contributor

Ah, that makes sense. It does appear I misremembered named messages vs subscribing to messages, etc, but it looks like you know more about that than I do.

@pomalley
Copy link
Contributor

Yeah, I've done two different "meta-servers" like that (the ADR server and the DR logger), and neither of them did I do particularly well. I think if we came up with a standard way to do that similar to the managed device server way that would be beneficial.

@roboguy222
Copy link
Author

roboguy222 commented Apr 26, 2016

Yep I am enhancing our ADR server. The way we have it now, it takes an input server name and device address for each measurement type (magnet power supply, for example). It seems that to subscribe to the messages in the device manager (using register_server, right?), I also need a device type. I would prefer not to do this, since it complicates the modularity of each system. Is there a way around this that any of you can think of by any chance?

@roboguy222
Copy link
Author

Have you looked into this any more? I think all that is needed is a method to send messages out when devices in general are connected, as opposed to specific devices. Do you think this make sense to have? Is there a specific way you would prefer to have it done? I can put something together and do a pull request, or if you know a specific way you want it written, I can let you?

@maffoo
Copy link
Contributor

maffoo commented May 16, 2016

I think it makes sense to have the gpib_device_manager server send out messages about all devices; this can use a labrad.server.Signal object to manage the list of parties who are interested in receiving this message. The main thing to decide is what info should be included in the message. If you'd like to take a crack at this and make a PR, that would be great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants