one additional question, what happened with the checkbox "Save Camera Position Angle to Sequence Job" ? I cannot see it. Is is possible to save such rotation to the job?

... what happened with the checkbox "Save Camera Position Angle to Sequence Job" ? ...

Actually it is not needed anymore. If you opt for "Preserve Position Angle" in rotator control, every job will be processed in the way that the rotator recreates the original camera position (*). Jasem was never happy with this checkbox and neither did I. So I removed it in favor of the new flip policy. If someone can argue for it, wen can put it back.

(*) As always this is only working if the key PIERSIDE is present in the fits header.

well, to be honest I agree with your statement in your first posts:
The user may need to load different jobs with independent angle, without using a reference frame.

This is my very particular situation: as I mentioned previously, my rotator produces some tilt at very specific angles. I created a sequence of 180 jobs automatically from a template, changing only the <Rotation> xml tag value increasing such by +5 in every loop (that is, I want to check the tilt every 5 degrees to avoid such angles in the future). When I loaded the .esq file the Rotation options was not recognized, obviously.

This is a very particular situation and I'm not going to ask to put the option back. If both of you consider is not needed, I would agree

m

I created a sequence of 180 jobs automatically from a template, changing only the <Rotation> xml tag value increasing such by +5 in every loop (that is, I want to check the tilt every 5 degrees to avoid such angles in the future). When I loaded the .esq file the Rotation options was not recognized, obviously.

What if you create a schedulerlist of one shot sequences, each one with different PA? I did not try out, it's just a very thought.

yes, I could consider that approach. Thanks

I had my first night out with an automated rotator today, and alignment worked flawlessly. However, I soon ran into the situation where the rotator motion started pulling the cables to the extremes and I had to intervene.
Thus, my question.

How is the reversal point defined and what is the suggested way of setting up mechanical zero in the rotator driver?

Having found out that the maximum limit that I can impose onto the rotator angle is 180 degrees, so I manually moved it to the extreme position (beyond which the cables are getting pulled too much), subtracted 180 from that, moved the rotator into the resulting angle (extreme -180) and set it to 0.
I think now it should not move beyond my extreme point, but will Ekos know to rotate into the opposite direction when the target camera angle requires so?

no afaik, and I've also been thinking about that. It would be very nice to have. Rotating for example 90d clockwise is essentially the same than rotating counter-clockwise. But one movement can be clearly better that the other. That would be a very nice feature to have

That would assume the resulting FOV is going to be inverted, so there needs to be some kind of an acknowledgement from the user they are OK with that. The "preserve rotator angle" checkbox in the meridian flip options could be adapted for that purpose (when checked it kind of assumes the user is OK with flipped images).

Once we have this and Ekos needs to change the rotator angle beyond the rotation limits:
1. Ekos tries to move the rotator to position x
2. Rotator drivers could return some special code/enum to indicate rotation request is rejected because of the limits.
3. Ekos instructs the rotator to move to position (x - 360). Or switch the rotator to the "reverse" mode and move it by the needed amount.

Of course the whole logic could be delegated to the rotator drivers themselves, kind of similar to how mount drivers handle meridian flips. Actually that could probably make more sense since different rotators may have different capabilities.

Of course the whole logic could be delegated to the rotator drivers themselves, kind of similar to how mount drivers handle meridian flips. Actually that could probably make more sense since different rotators may have different capabilities.
That's exactly the conception behind the buildup of the rotator control in KStars. It follows the idea of subsidiarity principle: EKOS is responsible for the highest level of control (setting angles, starting rotations, calibrating, define flip policies and so on), whereas lower level functions or settings are delegated to the device. A good rotator device should manage the reversal angle in the firmware. So indeed, the right place for this setting is the device driver.

this is not exactly what I would propose. I'm thinking about a 'Safe rotation' checkbox or similar:

- The supposed safe zone for the rotator is from 0 to 180
- If the rotator is requested to rotate beyond 180d, it will rotate x-180 instead (ie, a request to rotate 210d will result in a rotation of 30d)
- With this option activated, the user agrees the fov may flip

The reasoning behind this is that I (and probably many other users) consider is much safer to stay within 0-180 boundaries since the result is essentially the same (the user agrees a possible fov flip) and the risk for cable entanglement is lower. Even can prevent some tilting to appear.

This is my point of view

Two questions, Toni.

I just noticed that the forum is not showing the quote in one of my previous messages.

(Toni) NB: There is one situation which it is necessary to adjust the zero point of the raw rotator angle. That is, if you want to set the reversal point of the rotator in order to prevent a cable tangle. But this is done only once and readily done in the indi control panel.

So what is the reversal point and is it defined outside of the driver context in Ekos? I specifically want to know what is doable to prevent cables getting pulled too hard, so please share the recommendations to setting the mechanical zero from this perspective, if you have any. Thank you!

The second question is regarding the driver implementation of reversal when the target angle exceeds the limits (defined in the driver). Say, I go ahead and implement this function, it shouldn't be too difficult. But will Ekos be okay with the resulting image being flipped relative to the expectation? Will the alignment routine successfully finish in this case and not go into some infinite loop asking the rotator to move by 180 degrees?

So what is the reversal point and is it defined outside of the driver context in Ekos?
As I said above I wrote the new rotator module with subsidiarity principle in mind: Let lower levels of hardware/software do as much as possible. My rotator device is a Pegasus Falcon (rather lower price level) and it has reversal point built in (hard coded in firmware, but nonetheless usable). So I thought that the majority of the rotators in this price level and above have this option too (Correct me if I'm wrong). Thus I did not embed such an option in the rotator module.

.. so please share the recommendations to setting the mechanical zero from this perspective,
I personally have put the cables in such a way that they are wrapped partially around the camera in order to do a full 360° rotation. Then the Falcon has an option that syncs the rotator angle to zero, so I can set the mechanical zero. (As stated above I thought that a *sync" is standard and I did not implement any constraints in the module regarding device mechanics.)

But will Ekos be okay with the resulting image being flipped relative to the expectation? Will the alignment routine successfully finish in this case and not go into some infinite loop asking the rotator to move by 180 degrees?
I wrote the refactor of the rotator module before the option "limit angle" was added. So there aren't yet implemented any controls concerning this option Frankly I think it will be not easy to catch all possible entanglements regarding the interferences of this option with the rotator policies. And I confess, that I do not understand in detail how this limit works or should work. So it's best to ask Jasem if he can explain what his intentions are concerning this option.

But will Ekos be okay with the resulting image being flipped relative to the expectation? Will the alignment routine successfully finish in this case and not go into some infinite loop asking the rotator to move by 180 degrees?
As you can conclude from my statement above, I'm not able to answer this question. I fear there could emerge big problems with this "limit angle".

Generally I still think the best way to rectify mechanical problems is mechanics. There are certainly ways to put the cables in such a manner, they do not wrap up. (See my second answer).

Addendum: If you are a proud owner of a 3d-printer here are some cable organizer ideas!