I have just spent the whole evening getting backlash support in, at least an hour wasted when my focuser stopped responding! Obviously assumed I had cocked up somewhere in code, so setting break points and debug messages.... eventually realised I had disturbed the stepper motor connector plug on the pcb when removing a jumper to reflash with backlash eneabled! Could really have done without that.
I have just made a pull request, new version 6, backlash, go home and interrupt move all now added.
I was only able to test backlash as far as setting the values and reading them back after power cycles. All read as expected. I assumed that whatever my abs or relative target position was, that the back lash would be added to the actual final position, but this does not appear to be the case. I need to think a bit more about how this works.
When a move to a new position occurs and is in the opposite direction to the previous move
lets say current position is 4000 and move is to 5000 and the previous move was IN, then backlash will be applied if enabled
Backlash is applied (the number of steps to move) BEFORE the move is done. This does NOT change the focuser position as it it taking up the backlash in the gears getting ready to move - the draw tube would not have moved - so neither has the actual position - backlash is taking up the slack
Once backlash is done then the move is performed - in this instance from 4000 to 5000.
Adding backlash to the final position would be a mistake - Assuming 4000 to 5000 with backlash of 200, that would make the position 5200 - but technically the focuser is at 5000 because for the 200 backlash steps the drawtube did not actually move, hence myfp2 does not do it that way
Ever since I have committed my changes I have been struggling with why independent in and out steps, I made the following comment in the git pull request
"I am not happy with NOT using the built in base backlash support, a single value and a single enable.
The focuser has independent steps and enables for both in and out, so I coded to support the permutations, but the more I think about it the more I convince myself that one value applied for both in and out or neither is less likely to cause problems.
The way I see it is if you have different in and out values then the absolute position will creep towards one end or the other (by the difference in the backlash steps) if you keep switching from in and out by varying amounts.
I can see that for very specific cases that there may be a small difference, but again on average for the full length of the rack they must be the same, otherwise this would cause the gears to bind!
I'm thinking in circles about this one, but the fact INDI only supports a single value makes me feel I should also do the same and implement using the INDI supported control."
I think I should just implement with the original INDI control that enables and sets a single value. If I did then then anbal would set enable for both in and out and the same step value for both in and out, but I would only read the IN backlash enabled and the IN Backlash Steps from the focuser. This would mean if you wanted to get a bit of code space back you too could just use the IN values. I'm guessing that maybe at some point someone specifically had an issue with needing to set different values?
If I use the INDI support, I guess it is then available for other devices and clienst sto use automatically (I had noted backlash was greyed out in EKOS, and this is probably why?)
Do you have any strong feeling one way or the other. If I do use the built in control my change will not affect your code at all, I will just set the steps and enables as a pair.
As the developer of the driver you can implement it whatever way you think is best. That is ok.
Backlash code in myfocuserpro2 has evolved over the years from lots of user feedback and lots of tests and trials. Not everyone uses rack and pinion or crayford etc. It became very evident that the ability to support different values in and out and control them (enable/disable) became a big bonus as it is not the same on all systems and not within a hair breath of each other, and depending on the step size value there can become large differences.
There should be no appreciable bias if the backlash was set correctly using the method outlined in the manual. If other methods were used I would say you have a good point. As for the real stepper position becoming invalidated over time that is a whole new subject, and I would be happy to share my thoughts and experiences on that, but I think the amount that backlash causes to that invalidation is rather small in the larger scheme of things. In the best of worlds, there are home limit switches and the focuser is sent to home before use, which helps to reduce the errors in position.
First, many thanks for the great job you are doing by developing this driver.
I am presently doing tests of a myFocuserPro2 connected to a RPI3B+/stellarmate 1.4.4 as server, the client being Kstars/Ekos on a laptop running Linux Mint (~ Ubuntu). The results are very good. I just would like to report a strange behaviour when playing with the joystick.
As I already use a joystick to manually move my HEQ5Pro mount, I thought to dedicate 3 of the free remaining buttons to also control the focuser. The buttons (in, out and abort) react reliably but the amount of steps when I push them, in or out, is "huge" and not constant, variyng roughly between 60 and 80 (~ 2 times my CFZ !). As it now stands, the joystick feature appears to be not really usable.
If I change from full step to 1/4 step mode, the number of step is multiplied by 4, which makes me to suspect the command sent is a time pulse and not a number of steps. Am I right ?
I didn't find any place in the INDI driver menus or Ekos/focus where to manage this parameter. Maybe the joystick support is a part of the driver development which is not yet finalised.
Th ejoystick support is implemented external to this driver, and probably does as you suggest, time based. You may want to raise this question in the general forum. I might take a look at the joystick code later, see if I can get a definitive answer.
There is a MoveFocuser in the driver (I did not touch this function, assumed standard), but maybe able to do something in here. I think the options will be limited, based on number of steps/s or something similar, or perhaps divide whatever it is now by the inverse step mode (1, 2, 4, 8, 16....)
It is not something I have played with yet, but if I get time I will have a look this week.
Thanks Alan for your reply.
I do not realize what that represents in terms of coding but the ideal would be to have something like in ekos/focuser, that is buttons with the possibility of choosing the number of steps.
This feature is not essential but could be convenient when observing at the eyepiece.