Backlash.
If enabled
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

Regards
Robert

Hi Robert, thanks for clearing that up for me.

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.

Hi Alan
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.

Regards
Robert

I value your experience feedback and take on board what you say. I think I will leave as is at the moment.

Which means I believe all the core and important options are now in. Is there anything else I may have overlooked?

Anyway off to the pub in an hour (8am!!) for the Rugby (I actually live in the the town it comes from, Rugby) , so that works out well. Here's to a good game (England vs New Zealand).

Hi Alan
I think you have done more than your fair share so far!

Best wishes for a good game, lets hope the ref lets the game flow.
I'll cheer for my team, and you for yours. Here's to a cracker of a game.

Regards
Robert

Hi Alan,

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.

Thanks for bringing me some light.

Pierre-Yves

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.
PY

I'll see what I can do, but you must remember Ekos and Indi are all about remote observing and automation.

When I built my myFocuserPro2 I added all the bells and whistles. The only feature left now is the temp sensor.

Disconnected the, display,in and out leds and In and out buttons! It is my intention to build another bare bone one that will fit in a very small footprint.

I've managed to get debugging going with a joystick connected, and see that it is time based, it always seems to be 1s, and don't know where that is set? The other variable is the speed.

I could override this function, but with what? I think absolute position increments might work, but would be tiny, and only allowed one increment per second. The increments would be tiny because I think a maximum step size of 4 steps would be used, regardless of step mode. This is because I beleive ther are supposed to be about 10-12 steps at the focal point,(?) and so would give two or three presses at focus. My focuser at full step has 4900 steps full travel so

4900/4=1225s / 60 = 20 minutes, full travel!

Or perhaps speed 0 = 4 steps, speed 1= 20th full travel and speed 2=10th full travel? (if we went this way then we may as well have 1 step at speed 0, which might be a pain for the 1/16th 1/32nd step settings, but hey ho).

Any thoughts, anybody?


I'm going to code steps of 1,10 and 100 and see how it feels.

Having coded that, and then playing with the speed, it dawned on me that I could have just used the set relative step! I did also note that I could cause small fractions of steps, by feathering the joystick button, so I don't understand how that is working?