AXIS Limits
claudioarena opened this issue · 5 comments
Hello,
I've noticed some changes in the AXIS limits compared to OnStep. On the validate.h, I see you combined the AXIS1 limits for ALTAZ and EQ mounts, such that the largest sets of values is allowed to be specified (without checking if we have ALTAZ or EQ).
But for AXIS2, the validation values make it impossible to have sensible defaults on the config.h for an ALTAZ mount.
#if AXIS2_LIMIT_MIN < -360 || AXIS2_LIMIT_MIN > -90
#error "Configuration (Config.h): Setting AXIS2_LIMIT_MIN unknown, use value in the range -90 to -360."
#endif
#if AXIS2_LIMIT_MAX < 90 || AXIS2_LIMIT_MAX > 360
#error "Configuration (Config.h): Setting AXIS2_LIMIT_MAX unknown, use value in the range 90 to 360."
#endif
For ALTAZ I would want a min value of 0 degrees (or maybe somewhere around +10/-10), and a maximum of around 95/98.
Both fails the tests.
I would suggest:
#if AXIS2_LIMIT_MIN < -90 || AXIS2_LIMIT_MIN > -0
#error "Configuration (Config.h): Setting AXIS2_LIMIT_MIN unknown, use value in the range -90 to -360."
#endif
#if AXIS2_LIMIT_MAX < 0 || AXIS2_LIMIT_MAX > 90
#error "Configuration (Config.h): Setting AXIS2_LIMIT_MAX unknown, use value in the range 90 to 360."
#endif
Or maybe we can split the check depending on ALTAZ or EQ selections? I don't know what you would consider to be better.
I think that all the rest is good - it's just a setting validation issue. If I change the limits at run time, it all seems to work well.
Copy 'n paste error. Its supposed to be -90 to 0 MIN and 0 to 90 MAX (as described in the Config.h comments.)
And that's taken care of now, thanks.
Thank you!
One more thing on the expected limits behaviour:
If I initiate a slew to a point under the horizon, the slew does start. Once the telescope crosses the limit, the slew is aborted and the limit violation is noted.
After that, no further slew is accepted, unless we manually move the telescope to inside the limits.
Is that expected behaviour? Shouldn't the slew not be aborted if it would bring the telescope outside of the limits?
AltAzm mode had an bug there, wasn't validating the goto completely. Fixed now. Otherwise yes you should guide (move commands) back into limits and enable tracking again to go back to work.
Shouldn't the slew not be aborted if it would bring the telescope outside of the limits?
I think you misphrased this and are asking why the slew to a target back within limits should be aborted. In this case the geometry is simple and it could be done, but in other cases the geometry is not simple and so I choose to not support that kind of thing.
Thank you for fixing this, as usual, very quickly!
I suppose not many people use the ALTAZ mode and bugs aren't found as easily.
For the "slew back to within limit", that makes sense. Regardless, now that goto is validated, it shouldn't be possible to end up outside the limits. The only way that can happen is either with a guide, or with the telescope slowly tracking across a limit.
All good then!