I don't have one. But the CEM40 uses the same command set as the CEM60, so it should IMO work with the ieqpro driver...
Read More...
ChrisRowland wrote: A number of focuser drivers already have backlash implemented. it isn't difficult.
But backlash compensation is a different thing. If you use a wrong setting for BL comp, you get crap result. Both if it's too low and if it's too high.
With end-movement-inwards, you only lose some time if the value is too large.
Implementing it in the base class could be quite a lot more work because it would still need to refer to the actual driver to handle detecting when the initial slew has stopped, start the final slew and wait for it to stop. All of that is currently done in the driver at present.
I thought the base class sends a command, and then waits for the driver to report 'done'. So just send two consecutive commands if you want to move X steps out. First X+overscan, then -overscan (inwards).
There's also a lot of variability in how backlash is done. I've described one that is handled in the Indi driver but it could also be in the low level driver hardware.
IMO this would be an alternative to BL compensation, i.e., when using it, BL comp should be disabled.
Read More...
Just the quick side note that PHD2 also computes the RMS including the dither settle. So it rather seems 'common practice' 
Read More...
But couldn't (shouldn't?) that capability go to the general INDI focuser class, so that any driver can benefit?
Read More...
So is the pier side info actually used in the MF code? Did I get it right that you assume different mounts give different answers to the :GEA command? Might be one reason why it's an undocumented command.... For the CEM60 it does work absolutely reliable so far....
Read More...
IIRC I had placed a wishlist request for this feature some time ago. As in a general option for all focusers to always end moving inwards, ideally with a configurable overshoot amount. I think it would be a very useful thing to have!
So I would definitely welcome it if you go ahead and implement it 
Read More...
Hmm, doesn't sound like a software problem to me. Meridian flip only issues a slew command, and the slew is handled by the mount, with the set slew speed. So I'd suspect some mechanical issue - entangled cables, thickened grease due to temperature or alike causing steppers to lose steps. Strange indeed.
That said, the last nights MF worked just as flawless as the first one for me. Really very reassuring 
Read More...
Checking the source file (sxao.cpp) and its changelog lists Peter Polakovic <peter.polakovic AT cloudmakers DOT eu> as original author....
Read More...
No, no question, or complaint. Just the totally happy note that I just went through the first fully automatic meridian flip within a recording sequence. And no issues at all. It flipped (2 degrees/8 minutes past meridian), re-centered the target, PHD2 selected a new guide star and started tracking, and data acquisition continued.
Read More...
Somewhat semi-OT, but other manufacturers have the same problem. E.g., ZWO says to support Linux, but their FW upgrade programs are Windows-only, so I'm stuck with a badly-working EAF 
(and I don't even have a windows license to set up a VW or something)
Read More...