I had a problem where this started happening after a recent update and caused my filter wheel to crash into the pier. Jasem was able to identify a bug and did an update in git which fixed the problem but I am not sure if it has propagated yet, it was supposed to be in 3.6.2. Like you it was on align after successful flip. Discussion here:

www.indilib.org/forum/ekos/12663-camera-...n-meridian-flip.html

I've never has any issues with collisions with my pier, It's just I cant figure out how to use a rotator with automated meridian flips.

Because of my geometry with filter wheel I do not want it to rotate. It gets sorted out by the stacking routine so I see no reason to do so.

So Thomas, do you have to manually rotate it back after every flip?

No, I setup my frame in the early evening and then can keep that rotation over many nights of viewing. I have a permanent pier so I don’t need to adjust rotation once I have setup the way I want. I generally stick to one target at a time. I suppose that if I wanted to run multiple targets I would use prior images from the same side of the meridian so when I aligned the rotation was set appropriately. I have to be careful because I cannot have 360 free rotation due to collisions.

So you always image on the same side of the meridian? You never cross it?

I cross all the time, I just don’t change the rotation. This means the image flips but my filter wheel stays the same with respect to pier.

You see, that's the problem I am trying to describe. On my system, after a flip, the rotator automatically rotates 180 degrees. I can't stop it. The button that used to prevent that is gone. This means I have to recalibrate my guider every time I cross the meridian.

It's not suppose to do that. The only place where this could happen is Align module but the only way I can think this may happen if it happens to run load & slew port meridian flip.

I'm currently working on a refactor of the rotator module. It's not as easy as I thought in the beginning to deal with all the concerned parameters an the inner logic of them. But I made some progress and the tests in the simulated environment are successful so far. Even some tests in our observatory went quite well. Unfortunately the weather doesn't allow more test runs since two weeks.

With the insights I got, I see two possibilities which lead to an activation of the rotator:

1. A [Load&Slew] in the align tab does indeed move the rotator (as Jasem said). This is acrivated only by hand or once at the beginning of a sequence (FITS file entry)
2. A checked "Save PA to Job" in the rotator control window. This activates the rotator ahead of each capture job.

As the first eventuality activates the rotator only once at the start of a sequence I suppose that Peter has checked "Save PA to Job" in the control window. This way it is possible that a job entry moves the rotator after a flip because the position angle is reported as rotated by 180°.

With the refactor I want to overcome all the inconsistencies in the rotator module that exists now. It still needs heavy testing, as I don't want to introduce new problems in this field. For those who are interested in here is the draft.

hi guys,

after reading the whole thread, it is not still clear to me the current behaviour.
I'm running kstars 3.6.3. I'm planning to buy a rotator (falcon) but I don't want any automatic rotation after a meridian flip (so no need to take new flats). I usually perform a load and slew to center the object with a previous imaging session. If I'm using the job scheduler, I also usually use the "fits file" checkbox to perform the align with an image.
So, with this information, would ekos perform a rotation after a meridian flip? If so, is there any way to prevent it?

regards

Your rotator is in front of your OAG, filter wheel and camera. No need to redo flats after rotating. The whole optional train rotates, do flats are the same.