HI Alan
re - and made a minor change to allow change of position during a move.
In ASCOM the protocol is check isMoving property before a move. As the focuser would be moving such a call would be denied.

In the myfp2 firmware, this is replicated and new moves while the focuser is already moving are not allowed.

Regards
Robert

Hi Robert, I actually had the change move during a move implemented, tested and working last night. I check IsMoving and if so send an abort, then the new position. Works very smoothly.

Alan
Awesome, well done and congrats. That is the perfect way to do it.

regards
Robert

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.

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.