did something change in the focuser code in 2.6.0.21 or any of the few versions before that?
i have been down for a month with a dead camera. i got it back last night and decided to upgrade SGP. for whatever reason, i need to run with ‘reverse focuser direction’ checked (crazy setup with moonlite controller driving a feathertouch motor.)
i tried to 0 the focuser, so i racked it all the way in and set the position to 0 in the moonlite ascom driver settings. however, after doing this, SGP showed 60000 as the focuser position, which is the max i had configured into the ascom driver. in the end i moved the focuser all the way out, then set the position to 0 and then move it back into focus.
“out” moves the focuser out and “in” moves it in, so the reverse setting is correct. however, is it right for SGP to set its idea of the position to “max” when it’s set to 0 in the driver?
i noticed later in the evening after a reboot that SGP had for some reason set the focuser position to the max of 60,000 again and i had to go into the driver and set the position to 30,000, which SGP interpreted as 60000-30000=30000. i guess when i had the focuser racked all the way in i could have set it to 60,000 and it would have showed up as 0 in SGP.
Not sure what version you were coming from, but there is this (though this is all the way back to 2.6.0.1):
Refactoring “Reverse Focuser” logic. Everything now resides in two places: the “Move” and the “GetCurrentPosition”. Focuser position should almost never be called outside of these two places. This refactor effectively masks the real focuser position when Reversed. For instance if the focuser has 10,000 steps and is currently at position 2000 then when reversed SGP will report 8000 steps. Backlash compensation is in terms of “SGP Reported” steps not the actual steps of the focuser. So “IN” will always trigger backlash when the focuser moves from Low to High in SGP Reported Steps not Focuser Reported Steps. The main benefit of this is to have Auto Focus and backlash both work transparently when reversed. More info here: Rigel sys focuser can't reverse direction to help sgp autofocus - #10 by Jared - Auto Focus - Main Sequence Software
oh probably like 2.6.0.18 or something like that. so you’re saying that the “inversion” of the focuser position is the correct behavior? i had never noticed it before.
i’ll try to get a log because something is funny - i have never had problems with this before, but somehow for some reason SGP’s focuser count got set to the max at least once when the focuser was at the focus position, and then it complained that it could not move the focuser.
The initial implementation of “reverse” was poorly conceived at best, and broken at worst. Previously “reverse” only reversed the actual direction that the buttons on the UI moved your focuser. Everything else was just like a normal focuser. So if this was working for you before…I’m kind of surprised as to why (and you might also need to reverse it).
The new implementation actually reverses everything. This was done for many reasons but primarily to reverse the direction that autofocus happens when “reversed” is used.
I’d be interested to see the log if you can find it. My guess is that it just couldn’t move in one direction…?
yes, it could not move in one direction, because the limit of 60,000 had been reached and SGP tried to move beyond 60,000. this should not have happened, since the focuser was near the middle of its throw and somehow it got set to the max value.
my PC lives on my OTA now and everything is covered up since its raining. once it stops i’ll power up and look for the logfiles.
i’ve always had “reverse focuser” checked with this focusing setup. it’s also possible i’ve never used any version prior to 2.6.0.x with this setup, but i don’t know for sure. i guess what took me by surprise was 1) realizing ‘everything’ was backwards when trying to set the extent of the focuser - somehow i had never noticed this, and 2) the fact that SGP apparently decided that the max throw had been reached even when the focuser was mid-throw.
so this did happen again, where SGP picked up a focuser position from the driver that was at the maximum value even though the focuser was mid-throw. this looks more like it must be a driver problem, though i’ve never seen this problem before. if you recall for some reason this moonlite controller refuses to connect on the first try; it’s possible there’s something wrong with it i guess. the first focuser position reported in the SGP log is already wrong so it does not seem to be an SGP problem…
We get the maximum value directly from the ASCOM driver. Maybe this needs to be set in your ASCOM driver? I know that the Moonlite driver will allow you to set the max.
oh i’ve set it several times, that’s why i recognize the number as the max value. perhaps there is a signed integer issue or something like that here? i set the max to 60,000 in a fit of pique, i’m sure the actual throw is nowhere near that number.
Hm, odd. I don’t think there is anything preventing us from going well beyond 60k steps (more likely around 1 billion). I’ll try some fairly large step counts and see if I can reproduce.
If you happen to have a log that my be helpful as well.
oh i didn’t mean in SGP but in the driver itself. maybe it is reporting the initial position to SGP incorrectly due to the big max number… i will get the log tomorrow as long as it’s not raining.
i guess what precipitated that big max # is that i had racked the focuser all the way in, and then set the position to 0 in the driver. i then disconnected and reconnected the focuser and found that SGP had picked up the max value rather than 0, hence my post. at that time the max value was set low enough that i could not reach focus. eventually i realized that SGP was reversing everything, so with the focuser again all the way racked in, i set the max to 60k, and then moved the focuser to the approximate in-focus position. in retrospect i guess i should have racked the focuser all the way out and then told the driver the position was 0. that way i could determine what the ‘true’ maximum is by racking the focus all the way in.
Racking all the way in and then setting 0 in the driver is the right thing to do. At that point SGP would have been reporting your max (say 60,000 in this instance). You then should have been able to move your focuser IN but not OUT.
If you need 100% of your focus travel then you’ll need an accurate max value stored in your focuser. In that case you’d need to rack it all the way out and take note of those steps, then store those as the max in your driver.
yes that is all correct… i do not need full travel, so it’s fine. the problem i am describing is that intermittently, while the focuser is in the focus position, the position gets set to max and the focuser can no longer move in. later today i should be able to find some logs. i did look at them though and right after startup the initial focuser values are at max or near max when the night before they were mid-30k.