This problem happened last Wednesday and Thursday. I was forced to roll back to SGP 3.2 on my observatory computer to avoid wasting a few hours with clear skies. Was able to do some follow up testing during daytime on Thursday. Just tried to use the “Report a Problem” function, but even moving the logfile of that session back to the correct %appdata% folder does not let SGP pick up the logfile. Hence this post, will try to attach the very short logfile here.
Sequence created for this purpose only has one (daytime) target, mount, focuser and camera connected. No guiding, no rotator, no safety monitor, no observing conditions, no dome. Yet when I start the sequence SGP appears to get stuck on “Validating sequence and connections, please wait…”. Then nothing happens anymore, but the GUI remains entirely responsive where normally many controls would lock until the sequence is paused or aborted. The “Run sequence” button changes to “Pause sequence”, but does not react anymore.
It all appears to go wrong just after “Switches: Set state for sequence start…”, which I also noted in other (longer) log files. I suspect there is something wrong with SGP 4.1 attempting to connect to the Lunatico Dragonfly switch as reported before in this post, but there is no proof of that in the SGP logfile.
Thing is: most people seem to be perfectly happy in running a sequence with SGP 4.1 and mine won’t start on either of my computers. Will remove all switch drivers from one of these computers and see if that makes any difference.
It may have been addressed in 733, but this seems like a different issue. Not having a dragonfly to actually connect to, I think maybe the best course of action is to add more verbose logging. Maybe it’s a timing issue, but Im not sure.
Hi @Ken , I have also been in touch with Lunatico developer @jaime who has kindly offered to supply you with a Dragonfly if that would help resolving these issues. Theoretically that should not be necessary if everything is ASCOM compliant, but I am also suspecting timing issues here as SGP 4.1 communication with Dragonfly is erratic and non consistent. Certain situations are hard to reproduce.
Either way, will test with 733 and also with a setup where Dragonfly drivers have been removed and cleared from the ASCOM profile. Let’s see how that goes and if it provides further clues. Should be able to report updates in coming days.
I’ve been digging here because this is one of a very small number of issues preventing release. I think I have found an issue that could be caused by something like this:
SGPro has never seen or connected to a switch device (like dragonfly)
SGPro connects and writes out a cache file with all the switches so that switch device does not need to be connected in order to make a sequence using those switches.
Going to the control panel, you can set the state of a switch for sequence start / end. Nothing new here… this is just context for the problem
When the sequence is saved, it is, of course saved with some very specific information about the switch you want to use during the sequence.
Now… if this sequence is transported to a different machine that has never connected to a dragonfly and the sequence is loaded, these switch states appear to be orphans as SGPro has no parent switch device with which to associate.
Starting the sequence does not attempt to connect to the switch device (dragonfly) because SGPro has no idea what device the orphaned switch belongs to.
The sequence attempts to connect to a non-existent switch device and it fails badly. This part is easy to fix, but it doesn’t fix the issue.
I think the fix is to figure out how to “re-parent” these switch states. Just need to figure out where… The bigger problem here is that there may be a machine that can never be connected to a switch device and, because of this, never have access to switches available for use. It forces you to make certain changes on the observatory machine. I need to think on this for a minute, but I think the answer lies in having a sequence carry info about the entire switch device and not just the parts it wants to modify.
Alright… so this will delay release a little bit, but it needed to be done. The changes were more invasive than I’d like this late in the beta, but now sequences that use switch state are now truly portable. Beta 734 has the following changes:
When a new sequence is created from a profile or an existing sequence opened, it will check for and potentially restore information about the existence of child switches for every ASCOM switch device. This means that the switch cache travels with the sequence now. Older sequences with no values stored here will continue to use the original non-sequence cache until they are saved again.
SGPro will continue to write the non-sequence switch cache, but it’s really just for new sequences / profiles.
When a sequence is saved, it will potentially re-write the sequence switch cache (if it established a connection and synced the actual switch list)
When a sequence starts, it will issue a warning if the sequence wants to alter the value of a switch that no longer exists (maybe renamed, deleted or driver uninstalled, etc). It will also check to ensure that the state to use continues to be a valid state for that switch. It will allow the sequence to continue if you want, but will ignore switch state commands for those switches.
Just used the “Report a Problem” feature to submit a new report on this issue, with a logfile attached. Unfortunately it will not let me. “Unable to create new topic” and then just closes the window where I had described the entire problem. Fortunately I had made a copy of that so I can copy it here:
Sequence will not start (4.1 beta 733)
Created a sequence with minimal equipment, only a camera, focuser, filter wheel and mount. Defined one or two targets that would be high in the sky during daytime testing. Sequence has the mount slew to target, but obviously no auto center, no auto focus, no guiding, no nothing.
As I previously suspected a communication issue with my Dragonfly switch, I deleted that key from the ASCOM profile. As a consequence SGP no longer launches the Dragonfly application when it starts and it no longer shows the Dragonfly switch in the Control Panel. Since the problem continues (unable to start a sequence and slew to the first target location), I now suspect the root cause has nothing to do with the Dragonfly.
Prior to running this final test, I had uninstalled SGP and even deleted the program folder. Furthermore I had left the %appdata%/local/SequenceGenerator folder, but emptied its AscomOptionsCache subfolder where entries of three switches were kept (apparently for their switch elements): Simulator, Pegasus UPBv2 and Dragonfly (Seletek).
SGP logfile now shows that it can not find the cache file for the Switch Simulator. Is that really the issue that prevents the sequence from starting? Will try to recreate that cache file by running the ASCOM Switch Simulator in another sequence.
Will also try the beta 734 when it becomes available. Any further help in analysis is much appreciated.
I responded in the thread that SGPro created. Not why it lied to you, but it did actually create the new thread. I’ll see if I can spot why it thought it couldn’t