I have had a couple of issues on my last two nights out … My scope hasn’t parked and has continued tracking in RA. It has worked perfectly well before… the only difference between the good and bad is that one the two bad nights SGP has gone into recovery mode due to cloud.
Tonight I have done some testing… Please bear with me.
Slewed to a target - Pressed park in SGP - Perfect
Ran a sequence - Parked perfectly at the end
Ran a sequence with a time limit - Parked perfectly
Ran a sequence and went into recovery mode by covering the scope… Did physically park the scope and reported it as parked in StarGo, but SGP hung with the parking scope message.
I left everything running totally unattended as it was when I was asleep… when it came to the end of the recovery the scope parked according to the Avalon StarGo software. I checked in the observatory and the scope was indeed in the park position. But SGP wasn’t reporting it as parked.
SGP was on the other hand reporting in the bottom left as ‘scope parking’ … Nothing was clickable and despite leaving this for 10 minutes nothing changed. In the end I had to kill SGP in Task manager.
The worry was that the RA axis was still tracking and now I can see why everything has crashed into a wall for two nights.
Can anyone shed any light on this? I do believe that it is something in Recovery mode as otherwise it would have happened each of the previous 3 parking times … The problem only appears to happen when the system is in recovery mode. If it was an ASCOM issue for example then the parking problem would happen in every scenario… but it’s not… only in Recovery.
I experienced something very similar a couple nights ago. In my case I aborted a sequence manually when clouds came in and checked the option “Run end of sequence options”. The status bar showed “Parking telescope…” and in my case the telescope did park, but after that SGP was hung and I could not click on anything and I also had to kill SGP using Task Manager.
Also just as a finish - This morning exactly the same has happened. I can put the log up if needed.
The scope has parked physically and also acording to my StarGo system… SGP is showing a parking scope message in the bottom left and its hung and been impossible to do anything except killed via task manager.
It’s also worth pointing out that tonight I switched off recovery and it parked according to an end time on the target.
There seems to be a connection for me at least with cloud coming across and the guide star in PHD2 being lost. When SGP parks from that point it seems to show this problem… but if it parks from a perfect PHD2 guide all is fine.
I have uploaded the guide log and SGL log from last night so that the timings can be confirmed and hopefully we can get to the bottom of this issue.
I was running a sequence and a sub was in progress. I wanted to abort the frame so I could run AF. I clicked Pause in the sequencer window, and got prompted to wait for current frame or abort immediately. I selected abort immediately (leaving Run end of sequence actions un-checked.) At that point the button on the sequence window changed to Aborting… but the status bar stayed at “Integrating ; Event 1; Frame 6 600s (594s)”.
At that point the UI was completely unresponsive (could not drag any window or click anything). I waited a while then killed the Application using Task Manager.
When Task Manager tried to close SGP, SGP put up the dialog “SGP still has gear connected. Are you sure you want to exit?”. I clicked No, and the dialog went away but the SGP UI went back to being stuck. I used Task Manager again to kill SGP, got the same dialog, clicked Yes, and SGP closed.
Admittedly, I am at a loss. These are not all the same issues. There are at least 2 issues here:
Abort seems fine, but Park never gives control back to the calling function.
Some other thing that, by all accounts in the logs, looks like everything worked just fine
I have been looking at this for hours… going on vacation and will try to pick it up again in a week or so. In the meantime, if anyone is easily able to reproduce this behavior (I have tried everything I can think of and the sequence aborts exactly like it should…) using simulator gear (that way we are guaranteed to have the same set of gear), I would be immensely grateful.
Strictly speaking, reproducing a situation like this is a deliberate exercise not an accidental occurrence like I had, hopefully there is something in my uploaded files which will give Ken a eureka moment. If not then I will be putting in some time to deliberately produce this problem in the hope that I will be able to reproduce it time after time and offer something solid for Ken to explore.
Thanks, Paul! That would be great if you could repro it. It repro’d for me every time I hit pause with my imaging system regardless of whether I selected abort immediately/wait for current frame/run end of sequence options, but it did not repro for me when I tried with with simulators.