Just to say I double checked that crazy thing. If I set a target east of the meridian, the mount goes west pointing east and starts tracking but does not flip (even after >0.10 HA). But if I set a target at say 1m after the meridian as a go-to, the mount goes east and points west in the correct way. So EKOS & the mount are figuring out correctly the goto, but for some reason if that object was being tracked across the meridian it would not flip. (All models had been cleared & purged before, and a power-cycle done too).

Cheers.

At least I use it just like this, I have around 10 points synced from around the sky saved and load that as basis for per session syncs. It's especially useful when plate solving can't be used due to too bright sky. That and auto homing with EQ8 have saved my remote imaging sessions quite a few times.

This is the normal operation. The mount driver won't never initiate a meridian flip by itself. When the user or a client wants to perform a flip, he initiates a goto (usually the celestial coordinate of the target he is tracking).
The point is that the goto target should be **mechanically** after the meridian for the mount driver do the flip. The mount meridian is not the celestial meridian when the mount is misaligned. And your equipment is attached to the mount.

Ok. I'm puzzled why that happens even after I've now cleared & purged everything. If a target is set just after meridian (say 1m), I guess its the mount driver that's processing that goto and orienting the mount a certain way? So if the mount driver knows this target is after the meridian & figures out which way it should move, why does the same driver not have the same alignment when trying to process a meridian flip?

(Unless its EKOS telling the mount driver to orient a certain way for the 1m object...but if its that and the EKOS driver prevails, why does the mount driver not listen to it in a meridian flip).

Most important Q I guess is how do I fix this?! Clearly purging the model hasn't worked, so do I need to set up a model and then cross my fingers? (In which case I can't dummy that indoors?)

Thank you

@jpaana Thanks for answering, I have not thought to that case. I don't know the precision you get when using a high quality mount in a fixed observatory and how alignment may still be relevant in such a case.

@vineyard The mount driver does not have a 'meridian flip' command. It only offers track, slew and goto (and sync, guide). When tracking or slewing, it runs as long as it is told to run, even if it crosses the meridian (it may stop if you have set/enable limits).
You may make three turns in RA if you like. Concerning gotos, it always performs a goto with counterweight down at the given target (unless it is told to do counterweight up, there is a property switch you may set before issuing your goto).
That way, client/user may image passing the meridian without performing a flip if its setup allows it. Or it may start a session east of meridian without performing a flip if it starts counterweight up.
You have nothing to fix in your case. If you repeat your last test (start tracking east of meridian counterweight down, no alignment), just wait the target pass the meridian, then manually issue a goto in kstars to the same target, the mount should flip.
As I previously said, the problem seems to be that the client (Ekos) is using celestial coordinate to issue the goto performing the flip. It should use the true telescope coordinate, or wait for the side of pier property to toggle (the driver uses true telescope coordinate to compute this value, unless someone changed that).

Thanks @geehalel - yes I tried what you suggested (manually issuing a goto for the same coordinates after the meridian had been passed) and the mount flipped. You're right that definitely seems a glitch on the mismatch between EKOS coordinates and mount driver coordinates (even when purged).

Do you think it is possible to fix this within EKOS? (For example through a routine that automatically issues a goto command - rather than a flip command - once the user-selected HA has passed beyond the celestial meridian. Sorry if that's naive, I'm not a programmer!). B/c otherwise this means that the user has to be physically around to manually issue a go-to command (which for example could be at 0200, 0300, 0400!) which would defeat the purpose of an automated imaging session software?

Thank you again for taking the time to help & explain.

To be honest you are not the first to report this problem and I already tried to explain why meridian flip may not occur (regarding indi-eqmod at least, I don't know for other drivers which are using alignment).
Eventually there may be some misunderstandings between developers. Here is my understanding:
Meridian flip is used in order to keep down the counterweights of the mount, avoiding your equipment to hurt the pier. If your mount is perfectly aligned, the mount meridian coincides with the celestial meridian, and a meridian flip should occur when the mount crosses this unique meridian. Now suppose you turn the pier of your mount 45 degrees to the west. The mount is misaligned with deltaRA = 3.00 hours and the alignment system will correct that for you and track your target as desired. At that point, if the driver performs a flip when the target crosses the celestial meridian, this will result in a counterweight up position, as the target is still 3.00 hours before the mount meridian. And that's not what you want in order to preserve your equipment. That's why indi-eqmod may not perform a meridian flip if the corresponding goto is still before the mount meridian.
To sum up a meridian flip is related to the mount coordinate system and should occur at the mount meridian, never at the celestial meridian. And that may be before the celestial meridian when the pier is shifted to the east.

Thanks @geehalel. Ok I see now the logic for the reliance on the mount meridian. I'm still a bit puzzled as to how the mount meridian could be so far off (20m) if I'm doing polar alignment through the polar scope in the mount axis, b/c if the mount was that far turned, presumably Polaris wouldn't even be visible for the polar alignment (I align visually first, and then use the EKOS PA tool for the fine adjustments). So if Polaris is at all visible in the polarscope then there must be an upper limit on how far the misalignment could be?

But nevertheless it is what it is - now that the models are purged, I will try to be even more careful in the polar alignment to try and get the mount meridian close to the celestial meridian. Fingers crossed that then the flip will happen before it would otherwise damage the scope.

Thanks again for your patience!

Don't forget that when you polar align, you're pointing near the celestial pole by definition, and there, RA visually corresponds to a rotation of your scope around its optical axis. You could be 12h00 shifted in RA at the pole, Polaris will still be in your FOV, simply it will be on the wrong side of the celestial pole. Polaris being only 45 arc minutes from the pole, you should be very precise when you make your alignment (depends on the magnification of your polar scope). Your 20 minutes error is only a 5 degrees error **in rotation** of Polaris around the pole. Maybe half the diameter of Polaris itself as you see it through the polar scope (just an estimate). And if you simply spent 5 minutes between the time you set the RA angle of Polaris in your polarscope and the time you finish your alignment, you're 5 minutes away.
Not sure where your 20 minutes error comes from, as you did not find the AlignData file, that may be a plate solve/sync near the pole. Here too depending on the resolution of your imager and the quad star the astrometry solver finds in your image, you may get high error in RA when you sync near the celestial pole.
Anyway the problem with the meridian flip not occurring is a software issue, it seems that INDI/Ekos/client devs have to discuss this point and decide the correct way to go for mount drivers which can sync.
In your situation you may simply set a flip HA 1.00 hour past the meridian, just check your setup allows for that (it depends on the declination of your target though, your latitude, your pier...). That way you may live with a 20 minutes alignment error, the meridian flip will occur 1h00 past the celestial meridian.

Forgot to mention the accuracy of the home position: the home position is what determines the mount coordinate system for the driver. You may have a perfect polar alignment, if the home position is not accurate, you will lose accuracy as long as you point away from the pole, and then gets misalignment when you sync on your target star. The mount pier should be leveled so the RA and DEC axis are leveled too, then you may level horizontally each axis and turn them 90 degrees to get the home position.

Thanks @geehalel. Crikey re the potential for so many errors to creep in - certainly seems like a software solution would be great to mitigate for some of this. (I try to be quite careful about setting up, levelling etc, but clearly not enough). Will see what happens when we next get clear skies and I set up again & re-calibrate.

I'm hoping to set a permanent pier up so once that happens, then fingers crossed the alignment & mount meridian will be locked in (as long as the setup is done sufficiently accurately I guess - it would be a disaster if flips still didn't happen even after a fixed pier).

I see from another thread by @jabian that more meridian flip problems seem to be appearing so hopefully all the devs can agree something quickly (the strengths & weaknesses of open-source software approaches ).

Cheers again.

Created an issue in the Indi github. you're welcome to come and comment.
Thanks anyway to take time to experiment and have allowed to clarify this issue.

I got my meridian flip yesterday.
It took all the day and many tries, and to consider a lot of parameters I though were involved (most of them with incomplete understanding from my part or not clearly defined)

A major unfriendliness I found was to have to mentally translate hours (in decimal format) to minutes and angles to compare values in different places each with different format. This does not help. Please keep HA on the flip control and mount limits in the hh:mm format, or just use minutes (instead of hours) which is the magnitude of the values I suppose are used to estimate/set flip point and HA limits.

Time and location are critical because they define the position of the meridian and the actual angle of the telescope when pointing to a star. I always has been puzzled by the parameters of my AVX asking for local time, time zone, if time is standard or DST... and wonder if the time calculated from what I entered is in sync with that used in the computer and KStars. I am not and expert but it would not be enough just to enter UTC time and location to calculate everything needed?

At the end I managed to set everything in order the flip to work. It did it reproducibly 3 or 4 times (using a profile with simulators, a GPS auxiliary driver and the AVX mount driver.

My impression is that there is room to make this process much more user-friendly