I have a self-developed ASCOM switch driver for controlling ports on a RigRunner 4005i. Seems to work well, however SGP 4 presents a bit of a goose chase for getting it set up or reconfigured.
The IP address of the 4005i is set in the driver’s setup dialog…however, SGP won’t OPEN that dialog in Equipment Profile Manager, and won’t even show the switch in a sequence, unless it can connect to it.
Since SGP can’t connect, it won’t allow the settings page, and since one can’t get to the settings page, one can’t tell SGP where to connect to the driver.
I can work around it by going to the ASCOM profile manager and manually entering the IP, but this seems a bit clunky and “not like other ascom stuff”…it also means having the switch’s property page able to configure its IP address is pointless since if you ever changed the device’s IP…you couldn’t use the setup page to inform SGP of this.
It seems like every other ASCOM device type you can open the setup dialog, and tell the driver where to find the device…the com port for you FW, or the IP of your focuser, and so on…BEFORE telling SGP to try to connect to it.
We’re still trying to work out how best to do this with switches. It’s a very likely use case to have multiple switches even on a single scope setup. So the 1:1 device type to connection doesn’t really work well in this regard. But yes, we may end up changing the auto connect behavior in the future as it seems problematic in a couple of cases, this being one of them.
Fair point…it certainly seems like it would be a common use case, I agree. But 2 questions
Why not rely on a Switch Hub to exist to support multiple devices, and otherwise limit to 1, same as any other driver?
E.Q. You currently only support a single connection to a safety monitor, but it wouldn’t be unusual to have more than one of those. You’ve left it to the user/community to make use of the standard method of connecting multiple devices there.
I don’t understand how this situation…highly likely to have multiple devices…dictates that SGP must try to connect before giving the user an opportunity to tell it how to do so, and refuse to give the user that opportunity if it can’t connect. If SGP can handle multiple switch connections…why can’t it handle being told “Connect to this one now…connect to that one after I tell you how”?
I mean…I’ve learned many times you’re smarter than me. So I don’t mean to criticize, I just don’t understand.
It doesn’t…we’re just trying to simplify things from a user perspective. Less clicks to get stuff connected and not having to worry about connecting 12 pieces of equipment. We may end up reverting this…it’s a beta, it makes sense to try things out here in this regard. If it’s painful and everyone hates it will change it or find a better way.
Switches are a little more complex than Safety Devices. Basically a hub of safety devices is just a bunch of dev1.IsSafe && dev2.IsSafe && dev3IsSafe where switches can be much more complex (read only, analog vs digital, named, etc) and I don’t think having another link in the chain is helpful in this scenario. I can see the argument … but just don’t completely agree with it for most cases.
Fair enough, and I see the point. Lots of clicking to connect a boatload of switches.
Of course, putting a device that needs configuration to connect (and to be fair, the vast majority of ASCOM devices do) in a “must manually edit ASCOM profile” state doesn’t seem to achieve simplification for the end user.
Perhaps a toggle? Start with “Show all the drivers found” (which EPM does now) and “allow driver configuration while disconnected” (which EPM does not) and then a “connect at application startup” toggle for…perhaps…each switch, or even all switches?
True. The hub would be a good bit harder to build, for sure…and waiting around for such a thing to be contributed by someone in the community might well put V4 in a “supports switches, but only 1!” state for far too long.
So I don’t mean to criticize, I just don’t understand.