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?

Hi Alan,
I appreciate your efforts to improve the joystick operation.
My feeling is that it should be nice if effectively you could use the set relative step. In that way each user could set a number of steps according to the gear reduction of his focuser system.
But maybe there is some drawbacks to implement this solution...
BR, Pierre-Yves

Yes there does appear to be some draw backs, it does not seem that the relative steps step value is available in the derived class for the focuser. Even if it was it would need to be set each startup. I'm back to implementing a 1, 10, 100 movement based on speed, which does not take much effort to implement, and retains the setting between power cycles. Would this be better than the current solution, though I suspect the current solution is not behaving as expected.

I am thinking I will just leave as is for now, until someone explains how the in out joystick is intended to work.