The switches turn off correctly at end of sequence according to the log but closing shutter and mount parking activities all happen within a fraction of a second which is not physically possible. See time around 20:45:15 in the log:
Kent
Hi Ken,
Along with those other switch issues, I have this issue. The capability to turn the switches would sure be nice. Can you take a look at the log and see what might be happening?
Thanks,
Kent
I do beleive this issue occurs because SGPro is not currently expecting CCD wramup to finish prior to mount park and in this case, the camera already seems like it may be close to the warmup temp. This should be pretty easy to address.
Not sure I follow here. Do you mean “to turn the switches ON would sure be nice?” If so, you can absolutely do that, but maybe I don’t understand what youre asking.
Hi Ken,
I’ve been on vacation. That comment was poorly stated. I was really referring to turning the switches OFF after the end of sequence actions not, as was happening, before those actions. I guess you’ve fixed that. I’ll try your latest beta and check it out.
Thanks,
Kent
1 Like
Hi Ken,
I ran a sequence using Beta 4.4.1.1350 with switches set to turn on at the beginning and turn off at the end. I got error messages that SGP failed to turn them on, but they were actually turned on. The switches did not turn off at end of sequence. Nothing appeared to happen but at least they didn’t turn off before the dome closed and scope parked. The log is here:
Regards,
Kent
I think I may know what’s causing this (part of a pretty major refactor to swap internal IDs in support of DigitalLogger and other’s like it), but quick questions:
- Did you get a single error about setting switch state or did you get one per switch?
- Do you get this same error when you set thew state of a switch manually in the SGPro control panel (outside of a sequence)?
As for end of sequence state, it is clear what happened, but not why. End of sequence state will not start until end of sequence actions are fully complete. In this case, the mount reported it was done parking, but SGPro thinks that it hasn’t to it doesn’t set end of sequence state.
Looking into both of these now. Thx for your patience and feedback. These are pretty big changes…
Also… something odd here. It does seem like some switches were OK, like this one:
[06/25/24 20:55:52.282][DEBUG][Unknown][NONE] ASCOM Switch ASCOM.DigitalLoggers.Switch-5: Set switch state to True
[06/25/24 20:55:52.282][DEBUG][Unknown][NONE] ASCOM Switch ASCOM.DigitalLoggers.Switch-5: switch state reports True
and then immediately after, this:
[06/25/24 20:55:52.574][DEBUG][Unknown][NONE] ASCOM Switch ASCOM.DigitalLoggers.Switch-4: Set switch state to True
[06/25/24 20:55:52.574][DEBUG][Unknown][NONE] ASCOM Switch ASCOM.DigitalLoggers.Switch-4: switch state reports 0
[06/25/24 20:55:52.575][WARN][Unknown][NONE] Could not set switch "ASCOM.DigitalLoggers.Switch-4" to "1.00"!
Anything odd with the network last night? Maybe DigitalLoggers sometimes just requires a bit more sophisticated retry logic? In any case, I have added it and within a 30 sec period, it will reattempt to se switch state 6 times before giving up.
As for the other error where SGPro failed to set end of sequence switch state, I have this fixed. New beta today.
There were three error messages. I was attempting to turn on 3 switches and they did get turned on, just the error messages.
How do you set the state of the switches manually in SGP? I normally use DigitalLoggers web UI to do it external to SGP. The driver shows “Disconnected” in the Control Panel when I start SGP. When does it connect?
Nothing odd with the network.
I know how convoluted things can get in software. Scoping out the interactions and parameters to control them can get tricky. I appreciate your diligence in tracking this down.
Kent
You change the state of the switch manually using the exact same method for setting start / end state. Just click on the current state value and the field will turn into a dropdown menu field.
Ok. Well, at the moment, I don’t have any explanation for the switch getting set, but the driver not reflecting it. This is why the switch “failed”. It accepted the state change, but never updated its current state value.
Maybe the new retry will help or maybe this is a new issue… we’ll see if it persists.
OK. Duh, that works fine after I connect the switches.
Thanks,
Kent
I ran a simple sequence to test the switches. They turn off as expected but I still get this on start even though the switches are actually turned on:
The log:
There is a lot of activity in the log regarding the Pegasus switches. I don’t want to use them in SGP even though they are present in my system. Is there a way to ignore them in SGP?
I have been testing with this simplified sequence some more and it looks like the devices operated by the switches try to connect before there is power. If I rerun after getting the errors that the camera and Robofocus can’t start, it works because the power is there.
I get this after running SGP:
If I hit “Yes” right away, I get this:
Which is referring to the QHY camera I have. If I let the window time out, it will connect without the error.
I have also the same question for different switches (by RBFocus). I have been able to turn these switches on (outside of SGP) early as I wish (for a manual start of my sequence) up until these last two updates. I really don´t want SGP trying to connect to them - but just respect the “Unchanged” selection which it has been doing up until recently.
Hi Ken,
The switches now turn off during end action but the devices are left connected thus causeing my AP V2 Driver (mount) to hang which, in turn, hangs SGP. Task Manager to end the tasks is then required. Shouldn’t SGP disconnect the devices prior to powering them down?
For the above posts can you clarify which are using the new beta 4.4.1.1361 released yesterday (if any).
I’ll look into this… really what you’re seeing is just an internal switch inventory. You shouldn’t actually see it appear in the UI anywhere.
Have you setup the new switch delay in this beta. It is designed to give devices time to cycle on before an attempt is made to connect?
This is kind of a chicken and egg thing. If a switch device is installed we have to connect to it to get the switch inventory so we can just simply display it as an option for a sequence to use. I think the only way to do this is via explicit user interaction and not anything implied by an unchanged state.
Also, in terms of manual starts, the new beta should go a long way in terms of allowing previously manual starts to be automated (though you may have entirely different reasons for doing so).
Yes, I was using V 1361.
Kent
To be more exact, all posts after this one were using v1361;
I know this is super annoying and I apologize, but I just can’t pin down why DigitalLoggers will successfully set the state of a switch, but then, when it queries itself to ensure that it worked, the state still holds the old value. But…
Do you think you might be able to re-install the 4.1.0 release version (or maybe it’s still installed elsewhere) and, back to back do this:
- In 4.1.1 beta, connect to the switch and attempt to set state, observe failure (presumably)
- In the 4.1.0 release, do the same and… ???
This would be extremely helpful in pinning this behavior on new changes (or not)
I can’t produce any kind of similar behavior with other (non-network based) switches, but herein lies the other request. Can you also do that same test on the ASCOM simulator switch? Just connect and set any of the switch values and see if they are set successfully.