I think having it in the mount tab as an option to flip exclusive of any imaging might be handy for some or at least as an optional safety to keep a mount from a pier crash if it is incapable of saving itself from that kind of doom. Maybe use it as a means of overriding whatever default behavior the mount itself might do (some mounts will autoflip on their own or just stop).

However, it would be handy to override even those basic functions within some part of the imaging sequence control, whether in the capture module or (even better IMHO) the scheduler. I say this because it moves the control to a single point - where you're controlling your imaging.

I suppose it's possible to have the switch in 3 locations (mount, capture, scheduler) and have an order of priority such as scheduler overrides capture overrides mount setting for the flip.

Also nice would be to be able to set both positive and negative HA values for when the flip happens for mounts that can flip well outside of the meridian. Right now it seems it only accepts positive values.

- Greg

I woud be wary of adding more complexity to something that is already causing support problems becuse of it's complexity.

Doing the pier flip early will probably need further information from the mount and also a bool SetSideOfPier(PierSide ps); function. The driver would need to implement this, including reporting an error if it can't be done. Many mounts can't flip early so some way of notifying the user that it's possible would be needed. Some indication of an allowable hour angle range would be one way.

I have submitted a change to Kstars eliminating the meridian flip from the Capture module: phabricator.kde.org/D21222

Feedback warmly welcome!

As next step I would like to add a warning dialog before a meridian flip is executed. I think this makes sense, since an unexpected flip may create serious damage. For those wanting unattended flips (like myself), I will add an option to turn off the warning.

What do you think is the best solution? Having it on or off per default? Issuing a warning in the EKOS log?

- Wolfgang

I mostly use unattended flips so for me no warning should be issued. However, I do understand that this could be useful to some users. Perhaps a "Show warning popup when meridian flip starts" checkbox right under the meridian flip checkbox in the mount tab could be the clearest way of introducing this?


Thanks, Wouter

I think most users expect unattended meridian flip. So if there is a warning, it should be opt-in.

I agree with Jasem and Wouter. An unattended meridian flip that is coordinated with my imaging strategy is a required feature for me. A merdian flip is a "major" action in an imaging sequence, much as guiding, focusing, capturing are. It would be frustrating to wake up to a dialog asking if I want to flip and find that the system sat waiting for input and stopped imaging.

As an imager, I primarily interact with the capture and scheduler tabs. I can agree that maybe the flip feature might be better located elsewhere (like in the scheduler). However, it may make it unclear from a planning point if or when the flip may occur if it is no longer associated with one (or both) of these tabs. It will also make it easy to forget to consider it as part of the imaging sequence if it becomes otherwise "hidden" by relocating it away from these tabs. I think the flip *during imaging* should be well coordinated with the imaging sequence, and highly visible within the sequence, and predictable.

A fair point. I admit I am unfamiliar with out Ekos presently initiates a flip. I suspect it may just be a normal slew command?

In the case of my equipment (paramount), TSX mostly controls when the early (or late) flip is available I. Generally, I keep the flip point as far east of the meridian as possible. As long as the mount has passed that line, issuing a slew is enough to get the job done. In a case like this it could be as simple as re-issuing a slew command and trusting that the mount knows what to do.

I guess a complexity in this is ensuring that Ekos knows to reset guiding and the model due to the flip. In that case it would need to know the change in the side of the pier.

Come to think of this, with a telescope on the west side of the pier, not automatically doing a meridian flip (because there is a popup waiting for confirmation of the user) "may create serious damage" (quoting from Wolfgang) as well if tracking continues. What would be the course of action in that case? Suspend tracking until the user has confirmed?


Wouter

If the mount tracking can be disabled that would be ideal.

I wonder if it would be best to handle these details in the driver's though as a set of limits that fall within the mount's capability. These would be exclusive of any flip function requested by Ekos.

A well designed mount will have hour angle axis movement limits, it will stop tracking, or any other movement, past the limits. Similarly for the declination axis.

Personally I see no need for an automated pier flip when an automated process is not running. The mount stops at it's soft limit.

ASCOM has a number of properties and methods associated with pointing state:
PierSide SideOfPier(); // normally get but can be set.
bool CanSetpierSide {get}
PierSide DestinationSideOfPier(rightAscension, Declination); // returns the pointing state that the mount will end up in if the slew to the specified position is done now.

Only a few mounts can do a flip early, one I know of is the Celestron GEMs, they have a Meridian Mode state which can be set so the mount will do a pier flip up to 20 degrees early, determined by the Ra limit settings. Once the mode is set a normal slew to the current position will do the flip. DestinationSideOfPier can be used to check if the pier flip will be successful and throw an exception if the pier flip will not happen.

One thing that is very useful in the automation application is to check that the flip really has happened and to retry at the next opportunity if it hasn't.

Well, then I guess my SkyWatcher HEQ5 is not a well designed mount since I have had more than one occasion where the meridian flip failed to initialize and the mount kept on tracking all night long. I was asleep at those moments and when I woke up next morning I found the telescope hanging at the lower side of the hour axis and still tracking. Fortunately it was pointing at a safe declination... I guess what I am trying to say is that it may not be wise to depend on these soft limits. Perhaps there is a way to check if the mount has soft limits and, if not, enforce a limit?

Anyway, as I wrote in an earlier comment, as long as it is possible to do an unattended meridian flip this is all fine by me.


Wouter

Seems like nobody needs such a dialog - myself included.


The design idea is slightly different. The meridian flip behaviour is simply an attribute of the mount and not of a capture or schedule sequence. As long as you do not change the meridian flip behaviour, it remains the same for all your captures and schedules. I do not see a reason turning this behaviour on and off for specific sequences.

Yepp, this remains unchanged. The Mount module requests a meridian flip permission from the Capture module. As soon as a frame capture is completed, the Capture module grants the permission and waits, until the flip is completed. As soon as it is completed, it re-aligns and restarts guiding. By the way, this behaviour remains untouched.