That’s fairly easy to fix but at present it crashes if you try to use an ObservingConditions monitor, possibly because that was a precursor to the Weather monitor and was never released. It was the Weather/Safety that killed this, it became impossibly complex to implement or to design a UI that was comprehensible to me - and if the developer can’t understand his own interface there’s no hope for anyone else.
I might revisit this over the winter, if I get sufficiently bored, but quite probably not. I’m not inclined to open the can of worms that supporting something like this would be.
I went through what is needed for a safety monitor based restart last night. I think we can get something pretty minimal up in the next couple of weeks. You’ll need to set the Start/Stop times on each target and the existing logic for choosing a target will be used. Essentially SGP will abort and restart the sequence if an unsafe condition occurs. The unsafe state will keep the observatory closed and mount parked. Once it becomes safe again SGP will pick a target and start imaging again.
To be able to successfully use this you will need to:
Set start/stop times on all your targets
Have all options set so that clicking “Run Sequence” will start your guider, center/slew, etc (essentially if you can run a time delayed sequence successfully this should work for you)
I have yet to determine where this option lives. But it will likely be part of the Equipment Profile/Sequence.
I’ll also be looking for a couple of testers who are already using a lot of automation with observatories @joelshort@buzz ?
Happy to help. I have independent failsafes on my observatory roof and mount that should trap any potential kissing. Not much in the way of night time in the UK at the moment…
regards
Haa… now that is the Spirit! Thank you for bringing this solution and creative idea on the table. Jared & Buzz thanks for your recent massages guys. It has made a difference for me.
We should all try (on this forum) to keep an open Agile mindset and stay genuinely focused on finding solutions (rather than arguing all the time or focussing on the problem).
Let’s look for solution, solve one problem at a time, make hypothesis, build, test, learn, prioritize, iterate and repeat until we find the right approach that suites our needs. That’s the Spirit we need in my opinion.
Thanks again for the above solution. That is a great first step in the right direction!
We almost always try to. We’ve been doing Lean/Agile/Kanban for many years and certainly find value in “putting things out there” early rather than attempting to find the best solution first. Perfect is not the enemy of good!
Sometimes things go off the rails and some nights I’m going through a LOT of messages at once so don’t always catch when things start to go in that direction and instead end up focusing on the bad. Certainly not the best approach, but I’m human after all.
Just thinking about this. If it requires start and stop times then one thought says the option to start again would reside in the target planning dialogue. I’m guessing that SGP would go through the same logic as when you hit the initial run sequence. If that is the case you may need to check the PHD2 resume logic. At the moment, this has some gremlins and can leave PHD2 behind in some cases after a pause/abort.
Another thought occurred Jared while setting up the new beta and disabling light level as a critieria - Chris wrote both an ‘OK to Image’ and an ‘OK to Open’ monitor . Using both of these allows one to set some hysteresis between a clear unsafe condition and a ‘its worth a try’ condition?
Yes, there are likely a lot of things that this will unearth. Essentially any dialog box that pops up at sequence start would cause a problem for a restart. Although you should have already worked out all those issues. It will certainly test how robust restarting PHD2 is as well as your ability to get back on target and start “from scratch.”
Yes, maybe something we can look at later on but for now I would prefer to keep things as simple as possible. Adding other permutations and logic will just muddy the waters initially. Right now there is only a single boolean that the safety monitor has to consider. I think this is going to be tricky enough without adding anything else to it
I could certainly see a state where we would disable tracking and guiding to wait for clouds to pass and then start again without parking and closing up shop while we’re waiting though…just not for the initial pass.
Yes… I was just musing. There are a lot of ex engineers who are astrophotographers!
Just let me know what you want me to test - I can start a sequence and fabricate an unsafe condition with a watering can and then dry off the sensor to see what happens, keeping log files along the way. It might make sense to run a screen capture video at the same time- that can be quite informative.
Jared - the most obvious of these is the ‘telescope detected but parked’ dialog - I’m assuming SGP will park the mount when unsafe conditions occur, but it requires manual agreement to unpark the mount when you run a sequence.
Currently - I have to run cloudwatcher which runs a script to close the dome and park the dome. I leave everything else running, but the mount stops tracking.
Cloudwatcher will run a (open up) script if conditions become safe again. Why can’t SGP just pause? It seems to already do this. The shutter closes. Since PHD can’t get a guide star, it kicks SGP into a (recovery state?) which is like pause - for about 90 minutes it will retry starting. If PHD finds a star (won’t it continue)? I think I already had that happen. So if cloudwatcher opens the dome… SGP should be able to continue?
That should work as long as SGP doesn’t get a shutdown message. In that case you’re essentially relying on the retry mechanism to get you going once the dome opens back up. That is very different than what we’re discussing here though. Where SGP closes the dome, then sits and waits, then restarts when conditions are safe. For your case it will likely work ok as long as you get good conditions before the retry timer (90 minutes) runs out. But for others with roll off roof observatories this wouldn’t be a good option.
I’ve been trying to have SGP automatically take calibration frames after a sequence is done, unfortuntely i stope after a while because of the safety monitor turning unsafe when it gets light, i think SGP should have a choice to ignore the unsafe condition when taking calibration frames, i hope this is something that will get fixed
If an unsafe condition is met SGP should try and take the calibration frames right off. If that’s not happening I’ll have to double check.
In other news I’ve made some good headway in the “Restart” territory. It needs some through testing but I think I have a decent start at it underway. Initial behavior will be to abort the sequence, run the “End of Sequence Events” and then immediately restart the sequence while “holding” for a safe condition.
As mentioned previously this assume a lot of things. Essentially if you can click “Run Sequence” and “Abort Sequence” without having to take any other action (starting the guider, etc) then this will likely work for you. If you can’t do that then it likely won’t.
Hope to have a beta out in a couple of weeks. Unfortunately testing this will take some time as I need to do it in some real conditions to make sure it’s working as expected.
I’m not sure if this topic picked up again in some other thread…?? I’m also extremely interested in the ability to restart a sequence after the AAG Cloudwatcher “unsafe” signal reverts to “safe.” Happy to beta test if that would help.
