×

INDI Library v2.0.7 is Released (01 Apr 2024)

Bi-monthly release with minor bug fixes and improvements

myFocuserPro or myFocuserPro2 and INDI

  • Posts: 29
  • Thank you received: 6
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
4 years 5 months ago #45398
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
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.
4 years 5 months ago #45400
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
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.
Last edit: 4 years 5 months ago by Alan Townshend.
4 years 5 months ago #45451
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
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?
4 years 5 months ago #45452
The topic has been locked.
  • Posts: 29
  • Thank you received: 6
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
4 years 5 months ago #45458
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
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.
The following user(s) said Thank You: Jasem Mutlaq
4 years 5 months ago #45463
The topic has been locked.
You can find the implementation for Joystick button handling here: github.com/indilib/indi/blob/732c725eb17...indifocuser.cpp#L242

and the button defined here: github.com/indilib/indi/blob/732c725eb17.../indifocuser.cpp#L64

So in theory you add more buttons and you can change the behavior here. If the relative steps were set to say, a 100, then in theory pressing the button would move them by this much. Feel free to play around with the code in order to get the most desirable behavior keeping in mind that it should work for all kind of focusers (DC and steppers).
4 years 5 months ago #45473
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
Thanks for the heads up as to where in the code to look, and it looks to me like the code wold already do what we probably want. Unfortunately because this focuser has variable speed AND relative position, then the times move is used in preference the relative move.
From my point of view I would have thought relative move should have been first choice as it maintains accuracy of actual position.

My FocuserPro2 supports three speeds, so I assumed this means it is variable speed, but it is a stepper motor and not DC. Was this the intended purpose of variable speed or have I misunderstood? I don't see why a stepper motor would ever want to use a timed move as opposed to an abs/rel move.

I appreciate this is a global function, and so should not assume that everyone else would agree with my opinion, so how do we move forward on this?
4 years 5 months ago #45490
The topic has been locked.
I actually had the exact same though. Relative should be preferred over variable. I would make this change now, but please take a look at it in more depth so that it can be suited for more functionality later on.
4 years 5 months ago #45499
The topic has been locked.
  • Posts: 35
  • Thank you received: 3
You can do a relative move + or - using :64xxx#where xxx is the steps to move, for example :64-200# would move -200 steps from where the focus position is currently.
Does that help?
4 years 5 months ago #45508
The topic has been locked.
  • Posts: 77
  • Thank you received: 14
No not really, that is not the issue. I was just pointing out that if a focuser is defined to support variable speed(as this focuser is), then joystick button defaults to a "timed move" rather than the set "relative steps". I think it would be better the other way around.
4 years 5 months ago #45509
The topic has been locked.
This is now fixed in INDI::Focuser. Relative/Absolute is checked first before checking for timed move.
The following user(s) said Thank You: Alan Townshend
4 years 5 months ago #45528
The topic has been locked.
Time to create page: 0.734 seconds