Topics

Odd behavior of temperature-compensated focuser


Dave Schwartz
 

I'm using the master from a day or two ago and the hardware is the S6 with an SPI BME280 and a DS1820 for TELESCOPE_TEMPERATURE (in addition to the 3 others I have for dew heaters, all are getting properly auto-assigned).

Since the only interface I could find to control control the TC focuser settings was through the OnFocus ASCOM driver (or direct command entry), I've modified the SHC code to implement TC. focuser enable/disable and entry of a TC. coefficient between -9999 and +9999 (the range acceptable to the :FC command). They seem to work well so I'll try to send a pull request for those modifications tomorrow.

There are a few strange behaviors that the controller is doing however. Either they are real issues or I don't understand what its supposed to be doing.

On startup, I have the focuser set to half travel at the home position. For now, I have the TC coefficient set to about 950 um/C (a really large number so I can get some visible movement with just the temperature change of holding the sensor in my hand). When I enable TC with the sensor temperature stable, the focuser immediately takes off and focuses in to about 1/4 travel. This is unexpected. I would have expected that when TC is enabled, the target position would have been the current position at the current sensor temperature and any future movement would only have been due to temperature changes from that point in time.

Once it has done that initial large movement, it moves pretty much as expected. If I hold the sensor, pretty soon it starts moving in a little at a time as the sensor warms and then gradually moves back out once I let it go and it cools. However, it seems to have remembered the position where it was before I turned TC on because when I turn it off it moves quickly back there in a big movement.

The other strange thing is that when TC is on and I manually do a 'focus in', the focuser immediately takes off and there's nothing I can do to stop it until it hits the '0' position. I know its the software moving it to a target position of 0 because it stops when it gets there (i.e. its not that it locked up moving in because it stopped in a controlled way and did not grind away at the physical limit which was my initial fear).


Howard Dutton
 

On Tue, Sep 15, 2020 at 07:55 PM, Dave Schwartz wrote:
Since the only interface I could find to control control the TC focuser settings was through the OnFocus ASCOM driver (or direct command entry), I've modified the SHC code to implement TC. focuser enable/disable and entry of a TC. coefficient between -9999 and +9999 (the range acceptable to the :FC command). They seem to work well so I'll try to send a pull request for those modifications tomorrow.
This is changing to a range of +/- 1000.

There are a few strange behaviors that the controller is doing however. Either they are real issues or I don't understand what its supposed to be doing.

On startup, I have the focuser set to half travel at the home position. For now, I have the TC coefficient set to about 950 um/C (a really large number so I can get some visible movement with just the temperature change of holding the sensor in my hand). When I enable TC with the sensor temperature stable, the focuser immediately takes off and focuses in to about 1/4 travel. This is unexpected. I would have expected that when TC is enabled, the target position would have been the current position at the current sensor temperature and any future movement would only have been due to temperature changes from that point in time.
It is designed this way.  Either the focus will (probably) move when enabled/disabled or I would have to change the requested focus position.  The TCF focus moves on its own anyway.

Once it has done that initial large movement, it moves pretty much as expected. If I hold the sensor, pretty soon it starts moving in a little at a time as the sensor warms and then gradually moves back out once I let it go and it cools. However, it seems to have remembered the position where it was before I turned TC on because when I turn it off it moves quickly back there in a big movement.
Good.

The other strange thing is that when TC is on and I manually do a 'focus in', the focuser immediately takes off and there's nothing I can do to stop it until it hits the '0' position. I know its the software moving it to a target position of 0 because it stops when it gets there (i.e. its not that it locked up moving in because it stopped in a controlled way and did not grind away at the physical limit which was my initial fear).
I've attempted to fix this bug, let me know if the master branch is working now.


Dave Schwartz
 

On 2020-09-16 8:55 a.m., Howard Dutton wrote:
On Tue, Sep 15, 2020 at 07:55 PM, Dave Schwartz wrote:

Since the only interface I could find to control control the TC
focuser settings was through the OnFocus ASCOM driver (or direct
command entry), I've modified the SHC code to implement TC.
focuser enable/disable and entry of a TC. coefficient between
-9999 and +9999 (the range acceptable to the :FC command). They
seem to work well so I'll try to send a pull request for those
modifications tomorrow.

This is changing to a range of +/- 1000.
I've changed my changes to allow -999 to 999 (since you only accept the value if fabs()<1000.0, this is the range). Will send pull request shortly, then up to you to decide whether to accept, reject or tweak further. Note that I did not implement focuser backlash control because while the option is on the OnFocus ASCOM screen there doesn't seem to be anything in Command.ino to handle it.

There are a few strange behaviors that the controller is doing
however. Either they are real issues or I don't understand what
its supposed to be doing.

On startup, I have the focuser set to half travel at the home
position. For now, I have the TC coefficient set to about 950 um/C
(a really large number so I can get some visible movement with
just the temperature change of holding the sensor in my hand).
When I enable TC with the sensor temperature stable, the focuser
immediately takes off and focuses in to about 1/4 travel. This is
unexpected. I would have expected that when TC is enabled, the
target position would have been the current position at the
current sensor temperature and any future movement would only have
been due to temperature changes from that point in time.

It is designed this way.  Either the focus will (probably) move when enabled/disabled or I would have to change the requested focus position.  The TCF focus moves on its own anyway.
I disagree. If I've gone to all the work of achieving perfect focus without TC on, I would not be prepared for the simple act of enabling TC to muck it up massively and have to do it again.

Here's a test I just did:

1. Set focuser to home position at 37500 (my focuser has a 7.5cm
range), TC coef set to 950
2. Enable TC
3. Focuser moves by itself to 24906, now badly out of focus
4. Manually commanded moves and automatic TC movements around that area
(24900) work as expected
5. Disable TC
6. Focuser moved by itself back to 36576
7. Return home goes back to 37500

Is the massive moves when TC is enabled and disabled that I don't think are right. Enabling TC should stay where it is and future automatic moves should only be made based on changes in the temperature from what it was when TC was enabled. My other TC focus controllers (a Moonlite and a PerfectStar) do not make this initial move. In fact, here is a quote from the PerfectStar manual on the subject:

"Note that TC movements are calculated based on the “reference point” established when you
click the “enable” check box. That is, the current position and temperature are saved at that
time and used for all TC calculations rather than simply calculating the change from the most
recent event."


Once it has done that initial large movement, it moves pretty much
as expected. If I hold the sensor, pretty soon it starts moving in
a little at a time as the sensor warms and then gradually moves
back out once I let it go and it cools. However, it seems to have
remembered the position where it was before I turned TC on because
when I turn it off it moves quickly back there in a big movement.

Good.
Still works well (after it has moved to that massively out of focus position).

The other strange thing is that when TC is on and I manually do a
'focus in', the focuser immediately takes off and there's nothing
I can do to stop it until it hits the '0' position. I know its the
software moving it to a target position of 0 because it stops when
it gets there (i.e. its not that it locked up moving in because it
stopped in a controlled way and did not grind away at the physical
limit which was my initial fear).

I've attempted to fix this bug, let me know if the master branch is working now.
That is corrected... using the feature buttons to focus now works the same whether TC is on or off.


Howard Dutton
 

On Wed, Sep 16, 2020 at 08:17 AM, Dave Schwartz wrote:
I disagree. If I've gone to all the work of achieving perfect focus without TC on, I would not be prepared for the simple act of enabling TC to muck it up massively and have to do it again.
I'd say turn TCF on and leave it that way.  But if you want to be able to both turn on and turn off TCF without the focuser moving, the indicated position has to change.

I suppose you would like the no movement or change in indicated position at all when turning on TCF; and add the extra steps +/- into the current position when turning it OFF?


Howard Dutton
 

On Wed, Sep 16, 2020 at 08:17 AM, Dave Schwartz wrote:
Note that I did not implement focuser backlash control because while the option is on the OnFocus ASCOM screen there doesn't seem to be anything in Command.ino to handle it.
Backlash control exists internal to the ASCOM driver only.  I want it in OnStep, but that will have to wait.


Dave Schwartz
 

You should have the pull request now.

There is also a debate about whether TC-driven changes to the focuser position should actually be reflected in the position that is given out.

Here's a section from the PerfectStar manual on that:

"TC also involves a heated philosophical debate, if you'll pardon the pun. The issue is whether corrections to compensate for temperature changes should be reflected in the reported position. The argument against reporting is that the “actual” position (the distance from the telescope objective to the image sensor or eyepiece) does NOT change because TC is holding it constant by increasing the draw tube extension as the OTA dimension shrinks, for example. In fact, under this philosophy the position value DOES change with temperature if TC is NOT enabled. This might make a lot of sense if the reported position were actually the focal length of the telescope (perhaps in millimeters). Since the usual case is either reporting the extension of the draw tube in millimeters or in the somewhat arbitrary unit of “motor steps”, I think that the opposing philosophy is preferable: PerfectStar reports the number of steps out from a user-defined zero point, including any adjustments made for temperature compensation."

So PerfectStar includes TC-driven position changes in the reported position. However, Moonlite takes the opposite approach - the reported position does not change but the internal position (visible on the display of the newer controllers) does.

PerfectStar also has a hysteresis parameter which makes a lot of sense. Here's his wording on that:

"The hysteresis value defines how large a change in temperature is allowed before a correction is applied to the focus position. Setting it to “0” means that a new position is calculated every time that the temperature is measured (approximately every 5 seconds). However, if the resulting position change is less than 1 step no action is taken.

Normally, the hysteresis is set to something larger than “0” because it is not necessary to make such small changes and moving the focuser unnecessarily is a risk. Good quality focusers will not shift the image when focus is changed even a large amount, but there is no point in risking it when the adjustment will not improve anything.

To determine the optimal value for hysteresis, use this formula:

TC hyst = ((CFZ / SS) / 4) * (1/TC coef)

where CFZ is the “critical focus zone” for your telescope, SS is the linear step size for your focuser and motor (the distance the focuser actually moves for a single step of the motor), and “TC coef” is the temperature coefficient determined in the previous section. CFZ and SS must be in the same units (typically microns) and TC coef and hysteresis are both in degrees C. The idea here is that no correction should be made until the resulting movement is at least a quarter of the critical focus zone. For example, if CFZ = 100 microns, SS = 5 microns per step, and TC coef = 10 steps per degree, the suggested TC hyst value would be:

TC hyst = ((100 / 5) / 4) * (1/10) = 0.5 degrees "

Sitting here with the TC focuser running in the background, I can hear it making occasional adjustments, probably as the sensor waffles between tenths of a degree.

Any chance of implementing a similar TC hysteresis parameter in OnStep?


Dave Schwartz
 

On 2020-09-16 12:06 p.m., Howard Dutton wrote:
On Wed, Sep 16, 2020 at 08:17 AM, Dave Schwartz wrote:

I disagree. If I've gone to all the work of achieving perfect
focus without TC on, I would not be prepared for the simple act of
enabling TC to muck it up massively and have to do it again.

I'd say turn TCF on and leave it that way.  But if you want to be able to both turn on and turn off TCF without the focuser moving, the indicated position has to change.
That would be one way. Don't do any focus before turning it on, just put up with the massive movement and then focus with it on (possible now that the bug that caused the movement to one end or the other is fixed). However, I still don't get it... the temperature didn't change between the instant when it was off until it was on so why such a massive movement?

I suppose you would like the no movement or change in indicated position at all when turning on TCF; and add the extra steps +/- into the current position when turning it OFF?
When it is turned off, I wouldn't expect any change from the position it is currently at (a temperature-compensated distance from where it was when you turned it on) either.


Howard Dutton
 

On Wed, Sep 16, 2020 at 09:32 AM, Dave Schwartz wrote:
However, I still don't get it... the temperature didn't change between the instant when it was off until it was on so why such a massive movement?
In reality the movement wouldn't be "massive" since yours is an artificial test with settings no one is really going to use.

But this is due to the temperature compensation being relative to a fixed 10° C.  To get rid of that I'd have to change the focuser position when enabling (and disabling) to allow for the TC change.  Or make the compensation relative to whatever the telescope temperature is when TCF is enabled (and change the focuser position when disabling if we don't want it to move.)


Dave Schwartz
 

Obviously, I vote for that. It just makes so much more sense to me.

On 2020-09-16 1:08 p.m., Howard Dutton wrote:
Or make the compensation relative to whatever the telescope temperature is when TCF is enabled (and change the focuser position when disabling if we don't want it to move.)


Howard Dutton
 

The master branch has an updated (stepper based) focuser support.

This implements ...

A zero motion concept for TCF enable/disable, as discussed below.
A TCF deadband aka "hysteresis" GET :Fd# (steps) or :FD# (microns) SET :Fd20# (steps) or :FD20# (microns)
A focuser backlash compensation GET :Fb# (steps) or :FB# (microns) SET :Fb200# (steps) or :FB200# (microns)

No support in applications yet and only basic testing has been done.

Uploading this firmware will wipe NV since the structure changed (consolidated focuser settings into a common area) and to accommodate the new settings which must be stored.


Howard Dutton
 

Also, temperature readings now use a 20x rolling average of 1 second samples to stabilize things a bit.


Howard Dutton
 
Edited

Finally there are now other improvements related to this in the master branch:

  • The focusers/rotator position write frequency (5 minutes after motion stops by default) is now automatically configured to be more frequent (1 minute or even 5 seconds after motion stops) if the NV memory write endurance supports it.
  • The rotator now supports saving its position automatically.  When ALT/AZM derotation is also enabled (due to the constant motion) the only way to save its position is to park or return home which automatically stops the derotator and saves.
  • The rotator now has backlash compensation GET :rB# to see the backlash amount (for example 000*12:56) or SET the backlash with :rB000*00:34# (to specify 34 arc-seconds of BL for example.)
The above is untested at this point!