If it means anything, I made a bogus password in the ASCOM table and reran SGP. I don’t get any orphaned switches on applying the profile. After changing to a valid password and re-running SGP, no orphaned switches until I apply the profile.
Kent
The above is Pegasus, not DigitalLoggers. Here is the normal appearance of the DigitalLoggers switches:
Sure. What I mean by deleting the switches in the profile I think can be better explained using a series of steps:
- First, using a sequence that does not show the orphaned switches, make sure you are connected to them and that SGPro can control them. This will verify that the current switch set is not orphaned.
- Next, still connected to the switches, open the Equipment Profile Manager and make a copy of the problematic profile. Doesn’t matter what you name it.
- Load the profile copy and go to the
switchestab. The profile manager is designed to always show current switches (i.e. the ones you are connected to), “not connected” switches which means you likely have a driver installed, but no hardware present and orphaned switches. - See what shows up here. Does the profile now. Does the profile now also show 2 different switch sets? Theoretically it would…
- If that is true, just try and delete the switches that are not currently connected.
- Attempt to appl the profile copy to your sequence and see how it goes.
It seems to have been an intermittent error. I indeed have access again. I have started investigating but am very curious what results the above yields. In either case, the information will be helpful.
Interesting. When I apply the equipment profile to the sequence with switches connected, no orphaned switches. Also, whenever I load any sequence, no orphaned switches. They only come back after applying any profile, even old ones.
Following your instructions, only one set of DigitalLoggers switches show up. The key seems to be whether connected or not. If I disconnect and load that test profile the orphaned switches appear.
OK, thanks. That’s odd for sure. It’s almost like the switch connected state is altering the internal ID of the switch. I am continuing to look, but am at a disadvantage now since the primary clue requires specific hardware to reproduce. Not the first time though… I’ll update here.
OK. Thanks! One other thing: even with no orphaned switches shown (i.e. a clean sequence), I get the following error:
Switch actions appear correct - all the ones scheduled to turn on do so.
Another item: In the sequence, with a start time, the switches operate immediately upon running the sequence. This isn’t really helpful to me. There might be hours before the sequence is activated with equipment on the whole time. I understand that if the equipment is not immediately checked, there might be a failure when actually started. A pre-check with power on and fallback to power off might be needed. New feature, I guess, or live with it (I guess I can, but I don’t need the switch start capability). The power off feature at the end is still useful - if it worked. Right now, it powers off immediately before the dome and scope are parked. I have another report on that.
Just an update.
Now, after starting, SGP shows my USB Contol Hub as “not installed on this system” below where it shows the switches properly and disconnected (as they should be). It doesn’t show them as orphaned like DigitalLoggers. It seems to work, though, except for the switch 5 error which I click through.
Kent
Yes, to you and lots of other folks. Adding user-customizable delays is definitely on the 4.4 maintenance list. It required some refactoring of the UI, but we agree this is a necessary addition.
Ok… started investigating this. Of course, I don’t have the hardware you have, but I’m wondering if I might be able to install the drivers anyhow because they seem to be software switches? I dunno maybe not… If it’s possible I’d like to install what you have installed just so I can get the “Disconnected” state instead of the “Not installed on this System” state. Are you able to provide guidance to me here?
In any case, when I open the sequence from the first log you posted, I see this:
You also posted a similar screenshot, but for me, this is expected, because I truly do not have the drivers installed. Ignoring that, does this look right? It looks like 3 switches repeated 2 times. Is that expected?
None of that looks right to me. It may be “right” but I don’t think so. What looks right is the screenshot that i posted which has the ASCOM profile above it. That shows all the switches but doesn’t show the header. Here’s what it looks like:
Kent
Note, it says WPS Driver and doesn’t have the “series” description. BTW, I can run a “clean” sequence (no orphaned switches) with switches enabled and get the initiation error. With all switches set to “Unchanged”, no error. So it’s trying to initiate one of the “series” switches which is not even shown in the “clean” sequence list.
Kent
Also, I really meant to refer to the next screenshot after the one with the ASCOM profile that shows Pegasus switches.
Kent
DigitalLoggers Web Power Switch LPC9 has a web interface. You can get the 2019 ASCOM driver from:
https://ascom-standards.org/Downloads/SwitchDrivers.htm
Kent
The switches are installed on the LAN by doing this. I don’t know what the ASCOM driver will do if they aren’t physically present on the LAN.
OK, so good news and bad here…
The good is that I believe I have located the issue. In some cases 9especially for Switches) SGPro uses the “Name” of an Ascom device to generate internal IDs. The major clue here was that things appear to work OK when the switches are connected vs when they are not. In this case, the DigialLogger actually changes its name based on its current state (like DigitalLoggers - not connected then later DigitalLoggers -connected). There is literally nothing in the ASCOM spec that says drivers shouldn’t do this… it’s just that we were not expecting it.
The bad news is that the fix here will likely fundamentally alter the entirety of SGPro’s ASCOM initialization pipeline. I am not saying we won’t do it… just that it’s not a simple change.
Okay. Is there any way for you to fix the bogus switch activation error so it won’t require operator intervention? Also the Pegasus switches seem to generate a similar condition, although not orphaned;
As you can see in this screenshot with limited real estate, the USB 6 is part of the normal disconnected switch set which is above the “Not installed on this system” set. Should there be a “not connected” and a “not installed” in the same list? I don’t use those with SGP so I don’t know if there is any other issue.
Kent
Ken,
If you ask at support@digital-logger.com they may be willing to change that behavior. They’ve fixed a few things for me over the years.
Eric
Appreciate it, but, in this case, I think we were wrong and there is a better thing we can use as the switch device’s ID. I have already made the necessary changes and will be putting a 4.4.1 beta out soon. I’ve also tidied up several other bugs I have located as a result of investigating this issue. I will respond with more detail in a bit.
Some additional information on upcoming switch-related changes here: