1. main@onstep.groups.io
Topics

What does "CLEAR MODEL" mean?

Martin Bonfiore
 

I find myself back to trying to understand homing versus parking.  I realize there are several threads on this forum that clarify these functions...and I have read them several times.  I suspect I have a mental block.... I would appreciate if you would indulge a few specific questions that are related to my attempt at understanding.  For reference, I am running Android app 2.57, Onstep 5.1o and SHC 1.9h.  Note: my system has functioning hardware home sensors.

Let's say that I do a three star alignment using the SHC.  If I select the "SHOW MODEL" from the SHC menu, I get some non-zero entries for the model parameters.  This seems to make senses.

Now, let's say I use the SHC to command a GOTO HOME command.  The menu prompts me with a warning that if I say YES, it will clear the model.  Let's say I say YES.  From the warning, it would seem the model will be "cleared"....yet when I then select "SHOW MODEL" on the SHC, the pre-homing parameter values have persisted i.e. they don't at all appear to have been cleared i.e. set to zero.

 So....has the model persisted through a GOTO HOME operation in spite of the warning?  Or am I confused about what constitutes "the MODEL"?   On the other hand, If I use the SHC to command a "CLEAR MODEL" and then I do a SHOW MODEL, the parameters have been set to zero...as I would expect...cleared.  Are there two different sets of books for the model?  

Best I can tell, I get the same behavior from the Android app.

TIA.
andrea tasselli
 

As far as I can tell (not using the SHC, just the App) the model is retained in memory unless you do a sync after having returned home. If I don't sync, then sending a GOTO command in a new session will result in the object being positioned within the sensor frame. Also, I don't get any warning. I'm running 3.16.
Khalid Baheyeldin
 

On Mon, Apr 5, 2021 at 04:44 PM, Martin Bonfiore wrote:
I find myself back to trying to understand homing versus parking.  I realize there are several threads on this forum that clarify these functions...and I have read them several times.  I suspect I have a mental block.... I would appreciate if you would indulge a few specific questions that are related to my attempt at understanding.  For reference, I am running Android app 2.57, Onstep 5.1o and SHC 1.9h.  Note: my system has functioning hardware home sensors.
Before starting to respond to your questions, let me put an overview of what alignment and model is in OnStep.

Basically, the model is a set of various corrections between assumed and actual things, based on corrections from the 3 (or more) star align.

These corrections are for Azimuth and Elevation vs. the hemisphere's celestial pole, orthogonality of optical tube (cone error), and so on.

What is corrected for is a set of parameters that are in this source file.

If you are autoguiding, then a rough polar align may be sufficient in lieu of a proper n-star align.
If you align, then the corrections are computed, but are not saved to the EEPROM.
To save your alignment, you do a Set Park.
Then the next time you power up, you don't have to do the n-star align again.
That is only applicable if your mount is on a fixed pier, and not packed up or moved between sessions.

Let's say that I do a three star alignment using the SHC.  If I select the "SHOW MODEL" from the SHC menu, I get some non-zero entries for the model parameters.  This seems to make senses.
Those numbers are what is in that source file.

Now, let's say I use the SHC to command a GOTO HOME command.  The menu prompts me with a warning that if I say YES, it will clear the model.  Let's say I say YES.  From the warning, it would seem the model will be "cleared"....yet when I then select "SHOW MODEL" on the SHC, the pre-homing parameter values have persisted i.e. they don't at all appear to have been cleared i.e. set to zero.

 So....has the model persisted through a GOTO HOME operation in spite of the warning?  Or am I confused about what constitutes "the MODEL"?   On the other hand, If I use the SHC to command a "CLEAR MODEL" and then I do a SHOW MODEL, the parameters have been set to zero...as I would expect...cleared.  Are there two different sets of books for the model?  

Best I can tell, I get the same behavior from the Android app.
I don't use the SHC, so I will comment on the Android App.
The Return Home button under the Initialize button causes the model to be cleared.
It puts the mount in a state as if it was powered on the first time, and needs to be aligned (unless you are autoguiding, ...etc.)
That is why the Set Park, Park and Unpark are provided: for mounts in observatories which have been drift aligned or something, and the corrections saved.

The home sensor is something else, as I understand it.
Dave Schwartz
 

The alignment model is also saved on the completion of the park operation so if you haven't set a park position it will be defaulted to the home position but the model will still saved when you do a "park" without having to explicitly set a park position.

The alignment model is only restored on an "unpark" command. Its not explicitly cleared and saved to NV memory when you do a return to home but that would be the effect because without having parked you can no longer unpark so an alignment model that may have been saved to NV memory previously can never be reloaded over top of the default 'all-zeros' model.

There is a small side effect of not clearing the model in RAM or in NV memory on a return to home...if you simply restart the session without powering off, the model from the last align will still be in RAM and used for new gotos (because that's what gotos do). Essentially you're fooling the system by not powering down after a return to home as would be usually expected.
Dave Schwartz
 

P.S. The warning is something done by the remote application just to make sure you really wanted to lose the model (because you're going to power down). OnStep itself doesn't care because when the 'return to home' command comes in it is executed immediately - it is assumed that all commands issued really were intended to be issued. That's why you don't see a warning when talking directly to OnStep (any version).
Dave Schwartz
 

P.P.S. There isn't really a single 'clear alignment model' LX200 protocol command to be processed by OnStep. Instead, what the SHC does when you select 'Clear Model' from the 'Align' menu (and I presume the app is similar although I can't see the source code) is to use custom commands to individually zero out each of the 7 in-RAM alignment model variables. Those are the same 7 variables it fetches for the 'Show Model' function so that's why you see them as cleared if you do a 'Show Model' in the same session after having used the 'clear model' function but not after having done a 'return to home' function that warned you about the loss of the model (but you didn't follow with a power-down). It still doesn't clear the values from the NV memory but, again, there's no way to retrieve them except via 'unpark' and you can't do that unless you 'park' when the cleared model would be saved (unless you did an alignment to rebuild it).

If this "didn't power down after return to home and thus I can still see and use the old model" bothers you, it would be the work of but a few moments to add clearing those 7 variables to the processing of the 'return to home' function.
Martin Bonfiore
 

Thanks all for the detailed responses.  Definitely helps my understanding.  Per Dave's PPS comment:  no, the "didn't power down after return to home and thus I can see and use old model" does *not* bother me, so, please,  I would ask that it not be changed.  Let me get to the nub of the issue and the underlying motivation for the questions (bearing with me, since it has been touched on before).

I had this idea that "wouldn't it be great if" I could do a really good alignment and then be able to remove my scope from it's pier and later at another time, remount the scope, power it back up and my alignment was all set (the alignment having persisted).   *Conceptually* it sounds doable:  use the park/unpark commands and have some mechanical alignment points that would allow me to reattach the scope in the *precise* position that it had when alignment took place and of course, don't move either of the unpowered stepper motors have power down and prior to remounting.  OK...we have the park/unpark commands, I maybe can design some mechanical fudicial/reference points to accurately remount the scope, but what seems totally impractical is not have the unpowered steppers move or slip.  How to solve?  Well...if I could reestablish a reference of the scope axes to the mount mechanics *and not lose the model*, then I should have all the ingredients for my "concept".   Khalid (as I recall) convinced me that the concept was not practical (even if I could not lose the model)...that unmounting and re-mounting the scope would never get me back close enough...so, in my words, bite the bullet and realign each time.  

Since then I realized that I really needed some way of keeping the scope setup outside and ready to use...basically a pier and some kind of protection for the scope and mount.   This got me back thinking about the park/unpark and how it was designed to provide what I wanted.  
All good...right?  Well, I keep getting hung up on (even with a good pier mount) that the whole benefit of park/unpark is predicated on the assumption that the axes don't move when the steppers are powered off.  If they move, than the parked reference frame (I am assuming no encoders are involved) is now hopelessly lost and when you unpark, you are in the wrong place.  

This is where the HOME with home switches comes into the thinking.  In my case, I have very high quality (micron repeatability) opto-interrupters for the home sensors.  Conceptually, the home switches provide what is needed to not have to rely on the unpowered steppers from moving during the park time.  They provide a the needed mechanical relationship between the steppers/axes and the mount.  
This is the impetus that has caused me to try to understand HOME and the model and its relationship to park/unpark.  My hopes was that there is a way through some sequence of user commands to align the scope,on a pier,  park it , power off, power back on, *reestablish* mechanical "home", unpark the scope.  Given my new found knowledge about HOME and persistence of the model info, I will experiment and see if I can do this with the existing software.
The basis for my interest in this approach seems to boil down to one question:  assuming you have a pier based system, is the park/unpark operation more reliable if 1) you rely on axes not to move with the steppers unpowered or 2) if you reestablish the mechanical relationship with fiducials (in this case, the home switches) when you unpark?    For what it is worth, every commerical stepper based system I have worked on or designed (not telescope stuff) uses home switches to reestablish reference frame when powered back up because of concern that the unpowered steppers/mechanics may have moved.
Khalid Baheyeldin
 

On Tue, Apr 6, 2021 at 09:11 AM, Martin Bonfiore wrote:
I had this idea that "wouldn't it be great if" I could do a really good alignment and then be able to remove my scope from it's pier and later at another time, remount the scope, power it back up and my alignment was all set (the alignment having persisted).   *Conceptually* it sounds doable:  use the park/unpark commands and have some mechanical alignment points that would allow me to reattach the scope in the *precise* position that it had when alignment took place and of course, don't move either of the unpowered stepper motors have power down and prior to remounting. 
Conceptually sounds doable, yes ... but ...

If it is a fixed pier, then why not just spend the time doing a proper drift align, and that way the errors in azimuth and elevation would be near zero, and there is no need for a 3 star align to correct for these two?

Note that a 6 or 9 star align will correct for other things, like cone error. But if you remove the OTA, and reattach it, that correction can vary from one session to the next.

So given the above, there is no reason to do an n-star align, remove the tube and put it back.

And if you will be autoguiding, none of the above matters anyway. I don't do a 3 star align anymore. All I do is a rough polar align using the polar scope, and then plate solve and sync the first star, and off I go using autoguiding to mitigate all the imperfections (in polar alignment, cone error, periodic error, ...etc.).

If you will not be autoguiding, then it is worth thinking about all this, though why not do a drift align and be done with it (so no corrections for azimuth and elevation needed)?
Keith Trivett
 

I use the park feature in my observatory,  I have my park position marked on my mount like the home markers. If I ever release my clutches or move the steppers I just re align the marks then simply unpark and go. I change my scopes as well, my C8 is the main scope used to align then I can go down to my 66mm refractor and every goto is still good.


On Tue, 6 Apr 2021, 14:11 Martin Bonfiore, <marsbonfire0@...> wrote:

Thanks all for the detailed responses.  Definitely helps my understanding.  Per Dave's PPS comment:  no, the "didn't power down after return to home and thus I can see and use old model" does *not* bother me, so, please,  I would ask that it not be changed.  Let me get to the nub of the issue and the underlying motivation for the questions (bearing with me, since it has been touched on before).

I had this idea that "wouldn't it be great if" I could do a really good alignment and then be able to remove my scope from it's pier and later at another time, remount the scope, power it back up and my alignment was all set (the alignment having persisted).   *Conceptually* it sounds doable:  use the park/unpark commands and have some mechanical alignment points that would allow me to reattach the scope in the *precise* position that it had when alignment took place and of course, don't move either of the unpowered stepper motors have power down and prior to remounting.  OK...we have the park/unpark commands, I maybe can design some mechanical fudicial/reference points to accurately remount the scope, but what seems totally impractical is not have the unpowered steppers move or slip.  How to solve?  Well...if I could reestablish a reference of the scope axes to the mount mechanics *and not lose the model*, then I should have all the ingredients for my "concept".   Khalid (as I recall) convinced me that the concept was not practical (even if I could not lose the model)...that unmounting and re-mounting the scope would never get me back close enough...so, in my words, bite the bullet and realign each time.  

Since then I realized that I really needed some way of keeping the scope setup outside and ready to use...basically a pier and some kind of protection for the scope and mount.   This got me back thinking about the park/unpark and how it was designed to provide what I wanted.  
All good...right?  Well, I keep getting hung up on (even with a good pier mount) that the whole benefit of park/unpark is predicated on the assumption that the axes don't move when the steppers are powered off.  If they move, than the parked reference frame (I am assuming no encoders are involved) is now hopelessly lost and when you unpark, you are in the wrong place.  

This is where the HOME with home switches comes into the thinking.  In my case, I have very high quality (micron repeatability) opto-interrupters for the home sensors.  Conceptually, the home switches provide what is needed to not have to rely on the unpowered steppers from moving during the park time.  They provide a the needed mechanical relationship between the steppers/axes and the mount.  
This is the impetus that has caused me to try to understand HOME and the model and its relationship to park/unpark.  My hopes was that there is a way through some sequence of user commands to align the scope,on a pier,  park it , power off, power back on, *reestablish* mechanical "home", unpark the scope.  Given my new found knowledge about HOME and persistence of the model info, I will experiment and see if I can do this with the existing software.
The basis for my interest in this approach seems to boil down to one question:  assuming you have a pier based system, is the park/unpark operation more reliable if 1) you rely on axes not to move with the steppers unpowered or 2) if you reestablish the mechanical relationship with fiducials (in this case, the home switches) when you unpark?    For what it is worth, every commerical stepper based system I have worked on or designed (not telescope stuff) uses home switches to reestablish reference frame when powered back up because of concern that the unpowered steppers/mechanics may have moved.
Dave Schwartz
 

There are more corrections in the model than just the mount altitude and azimuth error. Given that the base of the mount can be precisely re-registered mechanically to the pier, I think what Martin is suggesting is having an on-demand entry to the home-sensor-seeking routine that results in the axes being in the park position. At the end of that, OnStep would set itself as if it had just powered on in the park position and thus the saved model would be valid and reloading it would be the correct thing to do on "unpark". Note that the load on the mount would also have to be exactly the same because, unless its a very expensive mount, the load can also affect the model.

That should be possible given that the code to do home-sensor-seeking is there. It might just require a bit of rework to expose it as a function of its own (if not already) and to provide a custom LX200 command to wrap it and set the correct states in anticipation of the 'unpark' at the end.

On 2021-04-06 10:10 a.m., Khalid Baheyeldin wrote:
On Tue, Apr 6, 2021 at 09:11 AM, Martin Bonfiore wrote:

I had this idea that "wouldn't it be great if" I could do a really
good alignment and then be able to remove my scope from it's pier
and later at another time, remount the scope, power it back up and
my alignment was all set (the alignment having persisted). 
 *Conceptually* it sounds doable:  use the park/unpark commands
and have some mechanical alignment points that would allow me to
reattach the scope in the *precise* position that it had when
alignment took place and of course, don't move either of the
unpowered stepper motors have power down and prior to remounting.
Conceptually sounds doable, yes ... but ...

If it is a fixed pier, then why not just spend the time doing a proper drift align, and that way the errors in azimuth and elevation would be near zero, and there is no need for a 3 star align to correct for these two?

Note that a 6 or 9 star align will correct for other things, like cone error. But if you remove the OTA, and reattach it, that correction can vary from one session to the next.

So given the above, there is no reason to do an n-star align, remove the tube and put it back.

And if you will be autoguiding, none of the above matters anyway. I don't do a 3 star align anymore. All I do is a rough polar align using the polar scope, and then plate solve and sync the first star, and off I go using autoguiding to mitigate all the imperfections (in polar alignment, cone error, periodic error, ...etc.).

If you will not be autoguiding, then it is worth thinking about all this, though why not do a drift align and be done with it (so no corrections for azimuth and elevation needed)?
Dave Schwartz
 

I guess "good" is relative. Lining up registration marks by eye is probably close enough (as in a game of horse shoes or hand grenades) for visual work but maybe not so much for a remote imaging or automated sky survey setup. I do this quite frequently if I have to release the clutches (or bump the telescope while moving around my rather small observatory). Just putting it back on its marks is "good enough" to unpark given that I've started (and love) plate solving after gotos.

On 2021-04-06 10:18 a.m., Keith Trivett wrote:
I use the park feature in my observatory,  I have my park position marked on my mount like the home markers. If I ever release my clutches or move the steppers I just re align the marks then simply unpark and go. I change my scopes as well, my C8 is the main scope used to align then I can go down to my 66mm refractor and every goto is still good.

On Tue, 6 Apr 2021, 14:11 Martin Bonfiore, <marsbonfire0@gmail.com <mailto:marsbonfire0@gmail.com>> wrote:

Thanks all for the detailed responses.  Definitely helps my
understanding.  Per Dave's PPS comment:  no, the "didn't power
down after return to home and thus I can see and use old model"
does *not* bother me, so, please,  I would ask that it not be
changed.  Let me get to the nub of the issue and the underlying
motivation for the questions (bearing with me, since it has been
touched on before).

I had this idea that "wouldn't it be great if" I could do a really
good alignment and then be able to remove my scope from it's pier
and later at another time, remount the scope, power it back up and
my alignment was all set (the alignment having persisted). 
 *Conceptually* it sounds doable:  use the park/unpark commands
and have some mechanical alignment points that would allow me to
reattach the scope in the *precise* position that it had when
alignment took place and of course, don't move either of the
unpowered stepper motors have power down and prior to remounting. 
OK...we have the park/unpark commands, I maybe can design some
mechanical fudicial/reference points to accurately remount the
scope, but what seems totally impractical is not have the
unpowered steppers move or slip.  How to solve?  Well...if I could
reestablish a reference of the scope axes to the mount mechanics
*and not lose the model*, then I should have all the ingredients
for my "concept".   Khalid (as I recall) convinced me that the
concept was not practical (even if I could not lose the
model)...that unmounting and re-mounting the scope would never get
me back close enough...so, in my words, bite the bullet and
realign each time.

Since then I realized that I really needed some way of keeping the
scope setup outside and ready to use...basically a pier and some
kind of protection for the scope and mount.  This got me back
thinking about the park/unpark and how it was designed to provide
what I wanted.
All good...right?  Well, I keep getting hung up on (even with a
good pier mount) that the whole benefit of park/unpark is
predicated on the assumption that the axes don't move when the
steppers are powered off.  If they move, than the parked reference
frame (I am assuming no encoders are involved) is now hopelessly
lost and when you unpark, you are in the wrong place.

This is where the HOME with home switches comes into the
thinking.  In my case, I have very high quality (micron
repeatability) opto-interrupters for the home sensors.
Conceptually, the home switches provide what is needed to not have
to rely on the unpowered steppers from moving during the park
time.  They provide a the needed mechanical relationship between
the steppers/axes and the mount.
This is the impetus that has caused me to try to understand HOME
and the model and its relationship to park/unpark.  My hopes was
that there is a way through some sequence of user commands to
align the scope,on a pier,  park it , power off, power back on,
*reestablish* mechanical "home", unpark the scope.  Given my new
found knowledge about HOME and persistence of the model info, I
will experiment and see if I can do this with the existing software.
The basis for my interest in this approach seems to boil down to
one question:  assuming you have a pier based system, is the
park/unpark operation more reliable if 1) you rely on axes not to
move with the steppers unpowered or 2) if you reestablish the
mechanical relationship with fiducials (in this case, the home
switches) when you unpark?    For what it is worth, every
commerical stepper based system I have worked on or designed (not
telescope stuff) uses home switches to reestablish reference frame
when powered back up because of concern that the unpowered
steppers/mechanics may have moved.
Khalid Baheyeldin
 

A bit clearer now, but still not entirely sufficient.

For example think about cone error, and the two bolts/screws (main one, and smaller one) of a regular Vixen saddle.
Depending on how much the smaller bolt is tightened, the OTA will be a bit east or bit west.
The home switch will correct for other things, but not this cone error.
So we add another sensor for that? Then what?

For my taste, and I understand that many don't agree, this is overly complex: more sensors, more cables, more things to go wrong.
There is a point reached when adding technology: before that, it is low hanging fruit, adding a little will get you a lot of good return. Beyond that point, it is diminishing return, and the investment in added complexity grows exponentially with less and less return.
Again, this is just my opinion, not just in OnStep, but in my day work too, and technology in general.
Martin Bonfiore
 

Khalid, 

I think I appreciate what you are saying with the Vixen bolt example... that not all drifts, movements, errors are correctable and/or the level of complexity required to do so makes for brittle, bad designs and more trouble that they are worth.

On that note, let me say, that if I had not made it clear in my post, I have abandoned the idea of being able to mount/unmount the scope and retrieve alignment.  You have convinced me that mechanically, it is hard to imagine a mechanical reference system that is so robust and repeatable that  the mounting/unmounting process not resulting in shifts in the mount and its position that are therefore not knowable and therefore not correctable with the home sensor.  Stipulated: That is a bridge too far.

So, the discussion for me is strictly about a pier mounted scope that remains mounted on a rigid pier during park/unpark cycles.  No take it off, put it back on.

If I understand what Keith Trivett describes in his post in this thread, he is doing what I am proposing but using actual physical marks, his eyes and his hands to reestablish position when unparking if he knows or suspects that he has moved (rotated) the axes (slipped clutches, rotated steppers). 

I am asking whether the same could be (and if you like, should be) done using the software, steppers and home switch.

 My guess is that the biggest movements while a scope is parked... when well mounted on a rigid pier... would be due to the unpowered stepper motors creeping due to the scope being bumped or touched and/or the slip clutches slipping due to bumping or the scope being touched or just gravity driven winding of the unpowered steppers.  Basically and simply, unintended rotation when unpowered, of one or both axes...scope  bumped by accident kind of thing.

My contention is that these sources of unwanted movement in a parked scope would be knowable and therefore correctable with home switches  and *maybe* worth (worth being in the eyes of the beholder...) using the home switches to correct.  So yes, the approach I am proposing is based on an assumption (which I think is reasonable) that the dominant sources of movement in a parked scope are reflected in the position of the axes relative to that of the home sensors. 

I am not looking to convince you that this idea is worth the effort to implement and use, but rather, I looking for a way, ideally without the need for special software the idea...to see if it is useful.  I started playing with some ideas today...alas, no love as of yet in getting it to work.

Thanks again for your comments and insights.
Dave Schwartz
 

In any worm gear set without an intolerable amount of slop to begin with it will be impossible to push on the scope and rotate the armature of an unpowered stepper motor. This is a property of worm gear systems and why they use them in limited-slip differentials. When mine (EQ-6) moves, it is always the clutch slipping in the way it is designed to do, even when the locks are tightened way more than they should be.

On 2021-04-06 3:46 p.m., Martin Bonfiore wrote:

 My guess is that the biggest movements while a scope is parked... when well mounted on a rigid pier... would be due to the unpowered stepper motors creeping due to the scope being bumped or touched and/or the slip clutches slipping due to bumping or the scope being touched or just gravity driven winding of the unpowered steppers.  Basically and simply, unintended rotation when unpowered, of one or both axes...scope  bumped by accident kind of thing.
andrea tasselli
 

Indeed. Worm and worm-wheel couplings with standard flank angle of 20 degrees are known to be "irreversible" and that can be used to great effect in, for example, mechanical control systems in the aerospace industry. You wouldn't want the aerodynamical load acting on a flap cause the gearing moving it to reverse, wouldn't you? They can be designed to be reversible though alto' I cannot guess why should they in this specific situation. 
Martin Bonfiore
 

Dave,

Good point.  It reduces my case to movement due to the clutches and certainly for worm gear systems, reduces much of the utility of what I am proposing.
1 - 16 of 16