Hi there,
I created flats using the Flats Wizard with the “New Target” radio button selected. However, after unchecking all the targets, except for the Flats, the sequence still does not run because it says conditions are unsafe.
How would I run the flats during the day while keeping the overall equipment settings untouched?
Clear Skies,
Paul
Hi,
I found out that by simply disconnecting the safety and environmental equipment in the sequence allowed it to run!
Never mind, problem solved.
Paul
Hi Paul,
Glad you got it sorted.
Some of us are hoping SGP will be updated at some point, so that it can recognize only calibration frames are involved, and therefore bypass the safety requirement (after roof/dome is closed!). Or perhaps give the user a checkbox option to bypass, if desired. Something like:
“If only calibration frames remaining, bypass safety Y/N”
Dave
The upcoming 4.3 release will have more flats/calibration control and will allow for calibration frames to be captured during unsafe conditions. We’re very close to getting it out in a beta.
Jared
Looking forward to it!
DaveNL
I think Jared was referring to AutoFlats which is (optionally) able to run in unsafe conditions.
Thanks @Ken. Taking a look at the Autoflats function now - it is quite comprehensive!
Will give it a try and let you know how it goes with respect to Autoflats working post sequence while ignoring “unsafe” status. Unfortunately, this will have to wait until I get my AAG Cloud Watcher repaired or replaced :=(
DaveNL
I was thinking about this the other night and I think there may have been an oversite with respect to full automation here. When you start an AutoFlats run manually, you will be presented with a checklist (of sorts). At the bottom of said list is a checkbox that allows you to sync with or ignore the safety monitor that should work as you expect. The oversight though, is with respect to automation and running AutoFlats as a part of your sequence. It appears as though I did not extend this option to the AutoFlats Scheduler. I’ll take a look and modify if required.
@Ken
I’ve only had one chance so far to experiment with this in real-world situation (ie. Autoflats as part of sequence). In that example, when the safety monitor kicked in (clouds), the Autoflats routine did start. The Autoflats process failed due to errors (same as posted in a previous thread).
However, the safety monitor did not re-initialize the sequence once the clouds departed. The sequence just completed (even the safety monitor disconnected, if I recall correctly). Maybe this happened because of the particular Autoflats errors.
So I guess one obvious question - how would/should SGP handle a situation where autoflats kick in while the gear is under unsafe conditions, and then the conditions become safe again. I would hope it would want to start capturing images again (prioritize target images over flats). This adds more complexity of course.
Dave
For clarity, I have not yet made any changes here (still hunting the double auto focus issue). I think you’re not implying that we have, but just making sure.
In any case…
In general:
When AutoFlats is using the safety monitor:
When AutoFlats is NOT using the safety monitor:
This may be a bug? I will audit AutoFlats and safety monitors here in the next few days I hope.
@Ken
Thanks for the clarifications!
I understood that you have not made changes on this yet :=)
Having the options to use or not use Safety Monitor during Autoflats (manual, or part of sequence) sounds reasonable. I recognize that different folks use safety monitors in different ways. For my purpose (safety monitor responds to clouds/rain to primarily close the observatory dome), I would prefer for Autoflats to ignore the safety monitor even if Autoflats is configured to run after a sequence that has the safety monitor in-play.
Questions:
If the intent is that Autoflats (run as part of a sequence) would have an option to ignore the safety device, presumably there will be capability in the Autoflats Scheduler window (or Preview window) to see (and possibly change) this status?
In the case where:
Autoflats is configured to run at end of sequence
that sequence has a safety monitor in play
Autoflats is configured to ignore the Safety monitor
the sequence encounters an UNSAFE event (ie. passing clouds)
a) the Autoflats will kick in because it is technically an end-of-sequence situation (as handled by UNSAFE)?
b) if SAFE condition returns, there is no return to regular imaging because Autoflats has already kicked in?
c) is it possible in the above scenario to have the sequence (“conditions are now SAFE”) override the Autoflats progress (even though Autoflats itself is not using the safety monitor), and return to imaging?
As for “sequence recovery” (not resume after UNSAFE) - I presume this would not be generally applicable to flats activity anyway, because SGP would not be trying to guide/center/meridian flip during flats activity?
I was pointing this out because you weren’t sure (as I understood it) whether Autoflats would actually kick in after an UNSAFE (with the code as currently developed/published). I’m a bit confused as to what aspect of this you might consider a bug? But either way, I need to stand by and be patient until you’ve had time to do auditing and further code development, before doing any more testing/feedback! :=)
Thanks again for your (and @Jared 's) efforts to continue the advancement of SGP’s capabilities.
Dave
correct. I think in “block 1” (upper left)
Correct, the safety monitor will have no bearing on AutoFlats startup in this case. Exactly how the sequence ended is of no concern to AutoFlats… it will just start as defined by the “after sequence” settings.
This is a good point, but for now, sequence restart will not be an option. Endin g the sequence, starting AutoFlats, then gracefully terminating and restarting the sequence when a SAFE signal is received, then afterward resuming AutoFlats where it quit last is not impossible by any means, but it is a complexity that is not yet accounted for.
General recovery only takes place during a sequence so it will never intersect with an AutoFlats run.
In it’s current form AutoFlats, when run as a child sequence, should always, without question follow the direction of the safety moinitor. There is currently no option to divorce the two and, as such, AutoFlats should not have started.
Thanks @Ken for the clarifications.
For clarity - this is the intention but is not in place yet (ie. I don’t see it there in 1317 beta)?
This might be a situation unique to me … but from testing on 1317 and previous beta, it seems that when Autoflats is set to run as part of a sequence (“after sequence ends”), and the sequence runs into an UNSAFE situation, the UNSAFE does not close the dome, park the mount, close the flip flat etc. (funnily enough, it did successfully resume sequence on SAFE). BUT, for anyone else who happens to turn on Autoflats as part of a sequence, be aware that the UNSAFE routine may not perform as you expect.
For now I will not be using Autoflats as part of a sequence, as the Safety monitor is too important for me :=)
As for 1317 beta, can confirm that the Chain Solver warning window did not appear.
Dave
Correct. I have a separate branch that contains the AutoFlats “safety monitor audit” changes. Still in progress… not too far out though.
This is problematic as AutoFlats should not control of affect any safety function. We can take a look if you remember the last time it happened.
Just tested again tonight using beta 1319. Manually triggered an UNSAFE by changing threshold for IR temperature (cloud detection). SGP recognized the unsafe but did not take any action (did not close dome, park telescope, even PHD2 keeps running). Check out this log file at approx 8:20pm local time:
https://1drv.ms/u/s!AnkB-cYBHJtTgeNOWQlJTHTm7CNSOg?e=Hl0044
Also, it did start the Autoflats process insofar as this prompt showed up:
I selected “yes” but it did not seem to continue with process of capturing flats.
Hope this helps.
Dave
