For an equatorial mount the existing axis limits are not sufficient to prevent all problems. In particular, if RA is against a limit and that limit is more than 90 degrees from the startup position the OTA could collide with the tripod or nix for certain Dec axis positions. Protecting against this would require axis limits that are a more complex function of both RA and Dec.
Two specific examples:
On a recent ISS pass track tried to move the mount in a way that appeared to be headed for a tripod collision and I had to stop the program to prevent it, so this is not just a theoretical problem. (#194 is related for this specific example, but better axis limits could be complimentary.)
On 5 May 2024, the mount moved to a position against one of the RA limits and continued moving the Dec axis such that the main OTA camera nearly interfered with USB cables emerging from the front panel of nix.
One option to consider is to prevent the mount from ever pointing the OTA below the horizon. This would avoid some complicated procedure to figure out the exact region of RA and Dec values would cause the OTA to collide with the tripod. However, this would require some careful consideration since there may be otherwise valid movements that technically cause the OTA to point below horizon, like when RA is crossing the counterweight down position and Dec is off to one side. Implementing such a rule might cause the controller to either get stuck or cause certain movements from one part of the sky to another to take a suboptimal (slower) path.
For an equatorial mount the existing axis limits are not sufficient to prevent all problems. In particular, if RA is against a limit and that limit is more than 90 degrees from the startup position the OTA could collide with the tripod or nix for certain Dec axis positions. Protecting against this would require axis limits that are a more complex function of both RA and Dec.
Two specific examples:
tracktried to move the mount in a way that appeared to be headed for a tripod collision and I had to stop the program to prevent it, so this is not just a theoretical problem. (#194 is related for this specific example, but better axis limits could be complimentary.)One option to consider is to prevent the mount from ever pointing the OTA below the horizon. This would avoid some complicated procedure to figure out the exact region of RA and Dec values would cause the OTA to collide with the tripod. However, this would require some careful consideration since there may be otherwise valid movements that technically cause the OTA to point below horizon, like when RA is crossing the counterweight down position and Dec is off to one side. Implementing such a rule might cause the controller to either get stuck or cause certain movements from one part of the sky to another to take a suboptimal (slower) path.