Auto Connect and Start Sequence

I’m not sure if I totally understand the situation, maybe what you need is a way to let your control-PC or mini-PC know the AAG status? Something on that PC can control doom, mount etc. based on the status, am I right?

No, if you run out of time on your targets then SGP will run your end of sequence events (parking mount, closing obs, etc) and then (should) wait until your targets are available. I’ll be honest that it’s been a while since I’ve imaged like this or touched this code. I can’t immediately recall if SGP will then wait for the next night (this would be my assumption) or if it will shutdown the “Restart on safe” behavior as it’s “done for the night”. Sadly there’s also a gap in our documentation here. I’ll try and do some testing this evening if weather allows.

https://help.sequencegeneratorpro.com/RestartSequenceonSafe.html

Jared

@Alistair_MacDonald
Hi Alistair,
Sorry - I wasn’t sure where exactly you were running into challenges with day/night and SGP control.

I’ve just had to replace my AAG CW after 6 years (including 2 previous repairs). My environment/weather is particularly brutal!

As you’ve been finding, SGP does not handle things in quite the same way as NINA. And SGP (to the best of my knowledge) has never put any focus on juggling multiple targets to optimize imaging based on target altitude etc. Or on trying to support multi-night imaging for that matter. SGP just runs through the target list sequentially and if it gets to “the end” (by reaching target “end time” or reaching the set # of images, with no other active targets after that) it will end the sequence.

My focus has been primarily on single night automation (having it run while I sleep or am otherwise occupied). Restarting on a subsequent night (based on safety/daylight) is something I’ve only dabbled with - sometimes by accident!

Doing what you want I think might be achievable if you use target end-at-altitude (no point imaging trees/houses!) instead of end-at-time, and making sure there is always another target in the queue that is active (with remaining images to capture, and is above it’s set altitude) until dawn arrives for AAG to detect. But SGP will not go back to a previous target in the sequence unless you manually intervene.

@Jared
Would appreciate any additional insight you can provide on the intended functions of the safety device. Especially how “sequence recovery” (recovering from problems guiding/centering) is meant to coordinate with going into UNSAFE mode based on the safety device.

My experience is that the safety device (as I’ve configured mine anyway) will not go into UNSAFE mode based on time or guiding/centering problems, only on clouds/rain/daylight ‘problems’. When things become “safe” again, it will just pick back up where it left off in the sequence. This seems to override the “sequence recovery” operations (which I think is a good thing, because “sequence recovery” does not close the dome shutter, but the UNSAFE mode does). And to the best of my recollection when returning from UNSAFE mode, it will resume the “sequence recovery” (which should go smoothly in theory, if the guider/plate solver now has access to clear sky?).

Dave

UNSAFE and Recovery are 2 different concepts that don’t really interact. UNSAFE is controlled by your safety device. When things go into an UNSAFE status SGP will run your End Of Sequence options and shutdown the imaging ASAP and close your dome. Basically your safety device should indicate UNSAFE whenever you want to close your observatory for the night. This could be heavy cloud cover, rain, sunshine, etc.

Recovery is basically a “Something bad happened, but we’re still fine to image” status. That could mean a cloud is parked in front of your target and we can’t guide. Or something happened with your slewing and we’re off target. Recovery can be a number of things that go bad during the night and SGP is just trying to get back on track.

UNSAFE always wins and is handled immediately no matter the status of things. UNSAFE will cancel recovery or cancel your current image. It doesn’t care. It’s an immediate abort of the sequence. When things clear and are SAFE again SGP will look for the first available target to start imaging.

Jared

Don’t apologise, your information is very useful indeed. I have been using SGPro in the same way you have for unsupervised overnight sessions and it works extremely well for that purpose.

My mind turned to greater automation when I got to four weeks after purchasing a Paramount MyT and I still had barely seen a star to point it at! If I am to justify the expenditure I need to take advantage of clear spells and not just clear nights.

The difference between NINA and SGPro is interesting, and perhaps a good example of the different points the balance between user friendly and user configurable can be placed.

I will keep at this and let you know how I get on - when these damn cloud clear.

Many thanks again for your help.

Many thanks Jared, that would be extremely helpful.

Thanks @Jared for the clarifications. So when you say …

this means SGP is starting at the “top” of the sequence and looking for the first active and unfinished target?

Also, while testing on a rare clear (but intermittently cloudy) night on Friday past, I noticed that on UNSAFE, SGP was not closing the dome, or parking the mount etc… This is new behaviour for me. Perhaps I have inadvertently responded to a dialogue, to not run End of Sequence options (and checked the ‘not ask again’) on UNSAFE? If so, how can I revert that selection?


Thanks,
Dave

@Alistair_MacDonald
Glad you found it somehow useful!

Apologizing is a Canadian obligation - lol.

I have always been intrigued by the possibility of multi-night observatory/imaging control. Going back to when i first heard of it as a possibility for amateurs (I think it was Prism?). However, in practice I have not (yet?) found it to be a critical/must have feature. For instance, I usually have long periods in between clear nights and therefore need to rethink my targets by then anyway (change in moon/moonless, change in season, change in interest etc). And I generally always have remote access to the observatory at some point before the next imaging night, even when travelling.

However, single night/overnight automation is a key feature for me, one that has helped me make the most of whatever clear nights come along. Getting reliable equipment has also been critical for this (my previous Foster Systems observatory dome control was not reliable and I’m glad it is in my rear view mirror!). I believe your MYT will justify itself, in this regard!

Wishing you clear skies!
Dave

Targets are “sticky”, so SGP will attempt to startup on target that you were on when the abort happened, but if that fails due to time restrictions it will continue on through all the targets until it finds an available one to run.

You can reset those here:

Are you slaving the dome in SGP or are you using an external app to slave your dome to your telescope? SGP needs to be connected to the Dome and Mount and have them slaved together.

Jared

Thanks for this clarification @Jared. So, fair to say that returning from UNSAFE is like a “Resume Sequence” instead of “Run Sequence”?

Tried this but no luck (there was no dialogue asking if I wanted to “ignore end-of-sequence options”).

In fact, on further testing, it seems that the UNSAFE actions not closing dome/parking mount etc only occurs when I had Autoflats set to run as part of the sequence (“after” sequence). This is perhaps related to the “bug” that @Ken was referring to in another thread (Autoflats when set to run as part of a sequence is not even supposed to run if the sequence runs into an UNSAFE condition). But it still causes this issue for me, even with the latest 1317 beta. When I disabled the Autoflats option, the UNSAFE behaved normally.

Dome is slaved via SGP (Maxdome connected via ASCOM Device Hub Dome driver - “Slave to telescope” is checked in Control Panel). But as just mentioned above, I think my issue has to do with Autoflats running as part of the sequence and not playing nice with the Safety monitor process).

Dave