Autofocus reverse direction

Sequence Generator Request Archive
1

I am trying to get autofocus working with a robofocus on sct - and I have backlash compensation built in to the robofocus behavior. I am trying to get the sgp autofocus routine to start from a low focus position to a high one - so that it moves in the pushing (ccw) direction of the sct. But I cannot figure out how to make sgp start at the low end of focus values and move up.

I just want sgp to start from the initial position near focus and move to a lower value - and then go through the focus curve from low to high. Is this possible? It keeps moving initially to a high value at the start of the curve - but that will end up invoking backlash compensation on every focus change as it goes through the curve.

I see something that lets me reverse the focus direction - but it doesn’t do what I need. It insists on moving to a high focus value rather than a low one when I start the autofocus procedure.

Also - I have a recent version of the robofocus controller and I get no feedback from it at all as the focus position is changed. Is this normal? I would like to have a live view of the current focus position updated every second or so as it changes - but I am only getting updates very occasionally.

Frank

1 Like
3

SGPro does not currently support this. We can move it to feature requests and consider it in the future.

Regards,
Ken

4

Hi-

OK - good to know I wasn’t missing a setting somewhere. I’m afraid I really do need it to go from low to high in SGP because robofocus has a well-defined “IN” direction and its backlash compensation is linked to it. I can reverse what “IN” means in robofocus - but then the backlash compensation would be in the wrong direction.

I may be able to reverse what IN means for robofocus and turn off its backlash compensation - and then have SGP apply its own backlash compensation in the proper direction. So it may be possible to find a workaround - but it would be cleaner to have the option of autofocus curves going from low to high or high to low - since backlash compensation could be either way - and that dictates the direction of the routine.

Separately I think I have different update behavior with robofocus vs. a rigel systems focuser. I’m pretty sure I was getting a live view of the focus position with rigel - but with robo the value in sgp only changes when there are extremes of motion. I think robofocus needs to be polled for its position value as it is moving - and updates every 1s or so would be very helpful.

Frank

5

This does not seem to be normal behavior. We update the focuser position once per second.

6

Hi Frank,

I am not sure if this will help you but you can change focuser direction as shown below:

Also you can change backlash compensation direction as shown below:

Currently I let SGP do the backlash compensation and works very well with my Optec Focus Boss II focuser hub.

Peter

7

Thanks Peter - I think that will work and I may go that way - but it means going against the intended behavior of robofocus - and disabling its built in backlash compensation - which means it won’t work automatically with other apps. So it may work as a workaround, but I think the direction of the autofocus sequence should be settable since there is nothing special about going down in values vs. going up.

Frank

8

OK - I created a concise log that shows what’s happening for me. I believe I used to get a “live” view of the focus position but it went away in one of the past betas. I was also changing focusers so I wasn’t sure if it was sgp or the focuser.

In the following log I requested a move of 1000 “IN” and it took 27 seconds to complete - and there was no update of the focus position the entire time. I did it again and it took 20 seconds - again with no update. The displayed value only changes when the move completes. I think the focus status says something like “Focuser” rather than idle - and a progress bar suddenly goes from blank to all green - but aside from that there is no indication anything is happening. In those two moves there is no backlash compensation involved.sg_logfile_20150411101405.txt (17.8 KB)

After those two “IN” moves I then asked it to move 150 “OUT” - and that invokes robofocus backlash compensation that takes nearly two minutes - which is normal. But during that time there is only one change of position shown - when it goes all the way out to the extreme backlash position - and then heads back in to the final destination - in this case 32149. At least I think it shows the value at the extreme position - it should have gone from 32299 to 30149 and then in to 32149 - or something like that.

The complete log is attached, but here is the focus section.

Frank

[4/11/2015 10:14:32 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL message received…
[4/11/2015 10:14:32 AM] [DEBUG] [Focuser Thread] Focuser moving to 31299
[4/11/2015 10:14:32 AM] [DEBUG] [Focuser Thread] Focuser move call complete
[4/11/2015 10:14:52 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL complete…
[4/11/2015 10:14:59 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL message received…
[4/11/2015 10:14:59 AM] [DEBUG] [Focuser Thread] Focuser moving to 32299
[4/11/2015 10:14:59 AM] [DEBUG] [Focuser Thread] Focuser move call complete
[4/11/2015 10:15:19 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL complete…
[4/11/2015 10:15:40 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL message received…
[4/11/2015 10:15:40 AM] [DEBUG] [Focuser Thread] Focuser moving to 32149
[4/11/2015 10:15:40 AM] [DEBUG] [Focuser Thread] Focuser move call complete
[4/11/2015 10:17:41 AM] [DEBUG] [Focuser Thread] SGM_FOCUSER_MOVE_REL complete…

9

Looks like your focuser is no longer (or new focuser?) reporting incremental position during move? Some focusers do this as a protective measure. I have validated that SGPro works as expected with MicroTouch, Focus Boss (Handy Stepper) and the ASCOM simulator. I do not have a robofocus to test with.

10

I think robofocus needs to be polled by the app and there is no way to make it report positions automatically during a move.

Are you saying you are asking for the position during the move and the value returned is not being updated? That would be a problem with the driver/focuser.

But if you are saying the driver isn’t voluntarily reporting its position during a move - that is normal.

Is there anyone else out there with a robofocus system - and does it show a “live” position value during moves in sgp?

Thanks,

Frank

11

Hi Frank,

I can confirm what Ken said that I can see the update of current focuser position while the focuser is moving. The update is kind of slow (slow sample rate) and depending on the size of the movement. For example, if I commanded to move 1000 steps, I see typical of three updates of current focuser’s position while the motor is moving. I can also see it display past the desired position if backlash compensation is enabled and then returned to the desired position. I am using same Starlight Instruments/Optec Focus Boss II Handy Stepper motor as one of Ken’s motorized focuser.

I know it does not answer your question because I do not have RoboFocus setup.

Peter

12

I’m pretty sure this is what I am saying, but we query the focuser so often that we can’t log it. Again, we query it once per second while moving or not… (in case it was moved external to SGPro).

@Peter When SGPro was younger, our polling rate was much higher. Some focusers could handle it, some would choke on the traffic. As a compromise, we just throttled the chatter for all focsuers.

13

Thanks for the info everyone. Looks like a problem or change in the new robofocus controller. I’ll follow up with them. I sure hope it can be fixed. It’s fine that the queries aren’t logged - I just wanted to make sure it really was being polled.

Thanks,
Frank

14

Hi Frank,

I have a Robofocus on my FSQ 106ED. I have never had any problems focusing via SGP.

Looking at your log - I may not be reading it correctly…but did you command 1000 IN going from31299 to32299? That would suggest that Zero position is the fully extended (out) position.

I have the zero at the full IN position - thus SGP is making the focus graph in the right direction…always going in…numbers going down.

Sorry if I have misunderstood what was going on with your system…but hope that helps.

15

Hi-

No I think the focuser is fine and happy and its range is something like 64000. Everything works as expected - the different thing for me is that it is a brand new robofocus controller to replace my old one that had failed. So it may well have different firmware or something to make it respond differently to polling.

The issue with the IN direction I think depends on exactly how it is driving the focuser. In the robofocus controller you need to have IN pushing in against gravity so that backlash will work correctly. But with robofocus you can have “IN” mean increasing numbers or decreasing - either way. In my case, IN means increasing - and that causes a problem with SGP due to backlash.

Frank

16

I cannot remember how exactly I set up RoboFocus when I got it…but when the focuser is fully IN…can you not make that the ZERO position. I am pretty sure that is all I did. (Obviously this means OUT = rising numbers and pushing IN (against gravity) = decreasing numbers.)
You said: " In my case, IN means increasing - and that causes a problem with SGP due to backlash"
I am pretty sure you can change yours over to read the other way - thus eliminating the problem you have with SGP. Like I said - I have absolutely no problem with SGP and Robofocus. It pushes in against gravity and the numbers decrease…it is just a matter of where you set the ZERO.

Perhaps someone else can let us know how they are set up.

As for the polling…I have never really looked at it as I don’t have problems getting to focus with SGP…it just works.

17

Just another thought…it may be worth just checking that the focuser is attached in a similar fashion…and we are comparing like with like.

This is my set up… (DELETED)

SORRY - have to edit this post…looking at your initial post again I now realise that you are working with an SCT…

18

Hi-

Yes - and with an sct you can attach the motor upside down or upside-up - and that will result in opposite senses of “IN” vs. “OUT” as the motor turns clockwise or counter-clockwise. So robofocus allows you to change “IN” to mean increasing numbers or decreasing numbers - but IN also means the direction with no backlash - and that is the direction you need to go during a focus sequence.

With sgp you can also change the meaning of IN vs. OUT in terms of the direction. But no matter how you set it in SGP, it will always take the focus sequence from a high number to a low one.

For me I need a lot of time to unwind backlash - so if I let it do the sequence from high to low it would take perhaps an hour. But there may be other people with a small amount of backlash who are taking the sequence backwards and don’t even realize they are invoking backlash compensation on every move - and the sequence could be going faster. So it’s something people should be aware of in general - if they have any backlash compensation in the focuser itself.

Frank

19

I would like to bump this topic because the feature request is somewhat confused by the polling issue with my focuser - which is a problem with the focuser itself.

My feature request is that you be allowed to take the focus curve in either increasing or decreasing order of focus position. As it is, I am completely unable to use the sgp autofocus routine because it insists on going “backwards” through the sequence - and there is no way for me in hardware or in software to change this. If I had the motor mounted upside down it would happen to work - but as it is, it is a 50-50 chance of being usable - or being unusable - due to the need for backlash compensation.

Frank

1 Like
20

I think a natural convention is simply to define “in” as the way in which you want to finish focusing, and “out” is the bad way that will require backlash compensation. So the default behavior should be for the focus sequence to start “out” and move “in” - and if that is increasing or decreasing it should just do the right thing.

For sct focusing this is definitely the language used, and no matter what the system, “in” usually means pushing up against gravity - which I think would be the preferred way to focus in all focus systems I know of.

Frank

21

Hi-

This is to respond to a question in the “polar alignment” feature request thread. I was asked:

“Why not use a external focuser like you would on a RC? Seems to be the tried and true method for it. I understand you want the focuser to work remotely… seems like you’d get a better product that way. The only limitation is cost.”

There are many answers to this - but a simple one is that my system works extremely well as is, and it would all work fine except for the focus routine insisting on moving from right to left through the focus curve. I should not need to add on an additional focuser - especially since one is already built into the sct.

In fact - high end rc’s do not have an external focuser. They have the imaging train attached to the back rigidly - and the secondary does the focusing. With an sct I can have the same thing - except the primary moves. I find the focusing in an sct to be extremely repeatable as long as backlash is removed. There is no downside to using the sct focuser - with the right technique and software - and there are many upsides.

Having a motor and motorized focusing has nothing at all to do with being “remote” - it has to do with achieving fine focus with an autofocus routine - and that is central to automated imaging - and even manual imaging of a single object - and touted by SGP.

Finally - when using OAG, there is limited backfocus with many telescopes, including sct’s, so the addition of a focuser is not only unnecessary, it may be impossible because it takes up too much backfocus. But more importantly - it serves no benefit at all except to add flexure to the otherwise fixed imaging train. In my case I have a rotator also involved - which takes up additional backfocus.

Even if you did use an external focuser - if you want to remove backlash, it would not work if the numbering happened to go the wrong way.

But more to the point of the request - I would claim that SGP has many features specifically to address the issue of backlash and correct behavior of in vs. out. Look at this from the flyover help text for backlash compensation in sgp:

“Compensation will be invoked when the move is opposite the compensation direction.”

So - backlash compensation is important enough to be supported in SGP, and it is critical to have it set the right way for a given setup, and options are provided to reverse the sense of it for a user’s setup - but when it comes to autofocusing it ignores everything and goes from high to low. If backlash compensation is important, and may be either way for a given setup - this is simply a bug, or at the least an overlooked problem that could and/or does impact many users.

Frank