This same sequence ran fine the previous two sessions, but before last night’s session I adjusted the position of the rotator very slightly, and that seems to have been enough to throw it off. I don’t know why, though, since the first two targets ran without trouble last night. Thanks for any help.
To avoid a repeat last night, I changed the target angle from 360 to 359.5. That did the trick, and the sequence ran without trouble. I’m not sure why that worked, though. Maybe the system got into some kind of loop trying to decide between 360 and zero?
The bug is in the driver, the ASCOM specification says “The position is expressed as an angle from 0 up to but not including 360 degrees”. It should not report 360, it should fold this down to zero.
Perhaps, but not necessarily. The rotator position could be something like 359.996, a valid value (<360) yet show up in the SGP log file as 360.00 when rounded to 2 decimal places by the SGP logging code.
Good point, especially if the position check in SGP is done after it’s rounding. What’s really needed is the log file from the driver to see exactly what value the driver is reporting.
I would do the folding in SGP anyway, to protect the user against this sort of issue.
For my own use I’ve written an Angle class which handles this and also comes up with consistent results for arithmetic involving the 0 to 360 wrap, logic and so on. A bit of work but it only had to be done once.