Loop when SafetyMonitor !=True does not cancel immediately

[Ruediger]

Hello,

just tested Safety Monitor loop condition and found out it is not canceling a sequence immediately, since it finishes the exposure first, before exiting the loop command block.

This could be fatal if you have long exposures e.g. 20 minutes and wind gusts or rain trigger Safety false state. In worst case your obsy is already flooded before NINA reacts.

Cheers
Rüdiger

[Stefan B]

Yes this is a current limitation of the sequencer. However you can use the “Close Dome on unsafe conditions” flag in options->dome settings to let the dome close immediately independent from the sequence

[Ruediger]

Hi Stefan,

unfortunately this is not an option for me, since I have no dome.
Under unsave conditions like wind gusts, I move the scope to certain safe position with least surface exposed. Or if there is the danger of rain, I slew it so electronics is covered and no rain can fall directly into the tube. Of course that is not perfect, but minimizes or prevents capital damage.

Also in such case it would make sense to run an alternative, dedicated sequence (a sepecial instruction block) . Here it would make sense to extend the AS logic to real If the then else structure, and not only loop while.

An other option would be to define a block with unsave == False. Currently you can only check for Safe == True. That would also be an option resp. work around.

BTW: We are working on an ASCOM driver (SafteMonitor) which bridges the ASCOM Observation HUB to SafteMonitor. So you can check for wind, rain or what ever to control the IsSafe status from any source. Beta is running and passed the tests successfully.

Cheers
Rüdiger

‌

[Stefan B]

To fall out early with conditions will likely come in a future update. However complex control structures aren’t planned, and are not always necessary.

Here is an example how you could have recovery options on unsafe conditions and imaging options with the current setup. The target will run until dawn and imaging block will be looped when safe and until dawn. If unsafe it skips to the recovery block and repeats that one until it is safe again.

‌

[Ruediger]

Hi Stefan,

thanks for the idea with the sequence, but if I understood the concept right and a short test confirmed it:

1. The unsafe instruction block gets looped too till sunrise. Makes no sense with park, warm or alarm script (send SMS, telegram, etc…).
2. The Unsafe block is executed any way regardless the is safety condition. Just tested.
3. Tested with a message box in Recovery and produced a situation I could not terminate the sequence at all. The pop up came up over and over.

The script is identical to have a loop while safe for imaging itself and have the same end-sequence. But this has the advantage that the end sequence is only execute once.

I fear that with current functions no real bail out is possible. It needs a trigger for bail out with an dedicated instruction block.

Rüdiger

‌

‌

[Stefan B]

It all depends on your use Case and the above is Just one of many examples. The unsafe Block can only be reached when it is unsafe, otherwise the imaging loop Runs all the time. And at Dawn the target Container exits completely after whichever step it was.

You need some delay in the Recovery otherwise you get spammend with your Message Box example of course.

[Ruediger]

Hi Stefan,
this makes things almost unhandable if you have multiple targets without any “external” loops (e.g. fixed number of exposures). and if you have a park, warm up, slew it makes no sense to loop it. With message box you are right, but for all commands which need only a single time execution it is not suitable.

[Stefan B]

Forgot to update this issue - the latest nightly should immediately cancel current running instructions when the safety monitor condition is inside and flips to unsafe.

‌

[Stefan B]

Related fix - https://bitbucket.org/Isbeorn/nina/pull-requests/894

[Stefan B]

Removing version: 1.11 Nightly (automated comment)