A couple of times now I've seen very strange behaviour when attempting to slew to something West of the median - the mount has flashed "meridian limit" and has then parked itself (I've got "park on limit" selected in the options).
I don't have the "apply limits to gotos" option ticked, and even if I did, I would expect a normal (non forced flip) goto would put the scope "on top" unless that goto was to a point between the meridian and the custom limit - I've seen this happen with points _well_ West of the meridian.
I've seen the same behaviour when initiating the slew from both CdC and SGP.
I can't say for certain that the scope is slewing "counterweights down" when it did this, because I wasn't physically at the mount (next time if it happens again I'll go and try again whilst watching what it does), but I am fairly sure it was counterweights down just based on watching the az and alt during the slew on the eqmod display, as it went West from the parked position (normal park position pointing at the NCP).
The way I understand it, the custom meridian limit I've set (about 1.5 hours West of the meridian) should mean the scope will keep _tracking_ through the meridian that far before encountering a limit. At that point, if SGP didn't initiate a flip or no goto to another object (or the same one) was instructed, the scope should stop tracking.
But I don't believe a GoTo should ever fail - my understanding is that any time a GoTo is sent to eqmod, it should decide which way to configure the scope (counterweights East or West of the mount) and execute that goto in the "correct" orientation, regardless of any limit - so even if I have a custom West limit set, a slew to an object one arc second West of the meridian should put the scope on the east side of the mount and execute correctly.
Finally, I have auto meridian flips disabled in eqmod - my understanding is those have nothing to do with gotos and only apply to flipping automatically whilst tracking into the limit - I understand a goto from one side of the limit to the other side should always cause a flip, regardless of that setting.
Have I got that correct?
What could be going on here?
Edited by RaulTheRat, 24 January 2019 - 05:44 AM.