1. Ap-Gto | Main
  2. Topics

Park vs Home

Jeff Kaufman
 

Quick question...

For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?
I can of course Park to various positions under the Park tab.
I can set some arbitrary Home position (after telling APCC that my calibration is complete, or something to that effect) under the AE tab and have the mount go Home when I push that button.  I can select the Home position to be a certain Park position also it seems under the Home settings. 

Is there something else that is in effect between the two modes?  

Also, in relation to another thread, do you have to have enabled Home first under the AE tab for the RA limits to work?  (i.e., there is a dialog box that appears indicating that before using Home that you must have your calibration complete...or something to that effect.)

Thanks!
Linwood Ferguson
 

On Fri, Mar 17, 2023 at 08:55 AM, Jeff Kaufman wrote:
For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?

Park positions (well, other than a user-set one) are well defined.  Home is where you set it.  The actual difference is more subtle and can be very confusing on the 1100AE. 

Home is determined from the absolute encoders (as are RA/DEC limits set on that tab). 

Park is determined by where the mount thinks it is by tracking motion relative to its last unpark (presumably from a known position).

The simplest way to see the difference is to purposely screw it up.  Let's say home is set exactly to Park 2 and that both return there properly (i.e. find-home and park-2 go to the same spot).  All good, things are in sync, the world is happy.

Now while in park 2, go outside, loosen the clutches (not the gear switches), and manually move the OTA to the park 3 position and tighten.  Now do an unpark not from last-parked, but from park-3.  The mount's awareness of where it is starts from park there, that really is park 3, and if you slew it goes to the right place. If you look in APCC the RA/DEC/Alt/Az are all correct. BUT... if you find-home it will go to some completely wrong place, because you have broken the sync between the mount's tracking of motion and the encoder position.  You now need to set a new home position to get the encoder defined position known.

If you never loosen the clutches, once home is properly defined, if you get the mount's position confused (e.g. you manually unpark from the wrong place), the encoders make it simple to fix.  You just find home (it uses the encoders so goes precisely there), and then do an unpark from that position.  This means by the way it is handy to have "home" set to a park position rather than some random spot. 

I use my clutches nightly to manually move to zenith for shooting flats, then put it back. Sometimes a move it for other purposes, checking clearance for example. This causes some minor drift relative to the encoders (i.e. I might not put the position back exactly and precisely and perfectly in the same spot). This has zero effect on encoder benefit during tracking, backlash correction, etc. But it does mean if I were to find-home it might not go exactly to the right place.  Worse, encoder enforced limits (so on the Encoder tab not the meridian tab) might be enforced at the wrong spot.  So I need to periodically reset home (or, as I do, just turn off RA encoder limits and use meridian limits which are based on unpark position and tracking motion, not on encoder position).

Keep in mind that by design the 1100 has to work WITHOUT encoders as well as with, that is one reason there are seemingly two parallel but sort of independent techniques used to track position. This is all invisible once set in sync and clutches locked. But its helpful to understand if you ever get them out of synch (then just reset home to a known park position).  

Does that help or make it worse? 

Incidentally this is why I've suggested to a couple of new owners just ignore encoder limits and home and such at first, learn how all the park positions work, why you unpark from last-parked, etc.  The encoders still work their magic for tracking.  Then once all that is settled well into your mind, set up home and if you choose encoder limits.

By the way the Mach-2 the encoders are in a different place relative to the motion, and using clutch allowed movement does not get encoder vs mount position out of sync.

Linwood
Dale Ghent
 

Park and Home might appear to be the same concept, or at least very similar ones, but they have some important differences.

The concept of Parking is to put the mount in a defined orientation that no other command - turn tracking on, a slew button press on the keypad, a slew command from software on a connected PC, even a pulse guide command from a guiding app - cannot move it from. The mount will refuse all requests for movement until an Unpark is commanded. Think of it as a like a safety on a gun. Safe and Unsafe. Parked and Unparked.

The Home position is a little different, and its meaning can also matter in different ways between mount system to system and vendor to vendor. The Home position defines an orientation that puts the mount axes into a known orientation. Unlike Parking, it doesn't de-energize the motors and there isn't an "unhome" command to move it from that position. A mount at the Home position can still be told to execute any movement command and it will depart from the Home position as a result.

In Astro-Physics encoder mount terms, homing the mount puts tells the mount to move the axes back to a defined orientation based on the index of the active encoders. If you unclutch your mount, move both axes to a random new position, and tighten the clutch, a subsequent command to Home the mount will make the mount move back to its Home position as it was set. It knows how to get there because of the index addresses on the active encoders. Obviously, this means that a mount with no encoders or passive ones (indexed, but not addressed) will not know how to get back home.

As I mentioned that the use and concept of Home can differ from one vendor's mount system to another. For example, some mounts require that they be powered on in their Home position. Astro-Physics mounts do not have this requirement.

/dale

On Mar 17, 2023, at 08:55, Jeff Kaufman <N983VB@...> wrote:

Quick question...

For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?
I can of course Park to various positions under the Park tab.
I can set some arbitrary Home position (after telling APCC that my calibration is complete, or something to that effect) under the AE tab and have the mount go Home when I push that button. I can select the Home position to be a certain Park position also it seems under the Home settings.

Is there something else that is in effect between the two modes?

Also, in relation to another thread, do you have to have enabled Home first under the AE tab for the RA limits to work? (i.e., there is a dialog box that appears indicating that before using Home that you must have your calibration complete...or something to that effect.)

Thanks!

Roland Christen
 

Park turns of power to the motors so it stops tracking. Home keeps the mount tracking.

Roland

-----Original Message-----
From: Jeff Kaufman <N983VB@...>
To: main@ap-gto.groups.io
Sent: Fri, Mar 17, 2023 2:55 am
Subject: [ap-gto] Park vs Home

Quick question...

For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?
I can of course Park to various positions under the Park tab.
I can set some arbitrary Home position (after telling APCC that my calibration is complete, or something to that effect) under the AE tab and have the mount go Home when I push that button.  I can select the Home position to be a certain Park position also it seems under the Home settings. 

Is there something else that is in effect between the two modes?  

Also, in relation to another thread, do you have to have enabled Home first under the AE tab for the RA limits to work?  (i.e., there is a dialog box that appears indicating that before using Home that you must have your calibration complete...or something to that effect.)

Thanks!

--
Roland Christen
Astro-Physics
Jeff Kaufman
 

Thank you everyone for explaining. This is very helpful!


On Mar 17, 2023, at 7:31 PM, Roland Christen via groups.io <chris1011@...> wrote:


Park turns of power to the motors so it stops tracking. Home keeps the mount tracking.

Roland

-----Original Message-----
From: Jeff Kaufman <N983VB@...>
To: main@ap-gto.groups.io
Sent: Fri, Mar 17, 2023 2:55 am
Subject: [ap-gto] Park vs Home

Quick question...

For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?
I can of course Park to various positions under the Park tab.
I can set some arbitrary Home position (after telling APCC that my calibration is complete, or something to that effect) under the AE tab and have the mount go Home when I push that button.  I can select the Home position to be a certain Park position also it seems under the Home settings. 

Is there something else that is in effect between the two modes?  

Also, in relation to another thread, do you have to have enabled Home first under the AE tab for the RA limits to work?  (i.e., there is a dialog box that appears indicating that before using Home that you must have your calibration complete...or something to that effect.)

Thanks!

--
Roland Christen
Astro-Physics

ROBERT WYNNE
 

Is home the exact '0' location for the encoders to determine home position? While you can park a scope away from home position the encoders will always be determining the mount's position from "home" regardless of where the mount is parked and while slewing calculating its moves from home rather than the last parked position? -Best, Robert 

On 03/17/2023 4:31 PM Roland Christen via groups.io <chris1011@...> wrote:


Park turns of power to the motors so it stops tracking. Home keeps the mount tracking.

Roland

-----Original Message-----
From: Jeff Kaufman <N983VB@...>
To: main@ap-gto.groups.io
Sent: Fri, Mar 17, 2023 2:55 am
Subject: [ap-gto] Park vs Home
Quick question...

For a mount like the 1100 with encoders, what is the difference between issuing a Park command vs Home?
I can of course Park to various positions under the Park tab.
I can set some arbitrary Home position (after telling APCC that my calibration is complete, or something to that effect) under the AE tab and have the mount go Home when I push that button.  I can select the Home position to be a certain Park position also it seems under the Home settings. 

Is there something else that is in effect between the two modes?  

Also, in relation to another thread, do you have to have enabled Home first under the AE tab for the RA limits to work?  (i.e., there is a dialog box that appears indicating that before using Home that you must have your calibration complete...or something to that effect.)

Thanks!

--
Roland Christen
Astro-Physics

Arun
 

I had a question related to homing my Mach 2.

I am a portable imager, meaning I disassemble and reassemble my mount/tripod.

I find that, on occasion, the encoders seem to forget where they are and, when I ask to park, go to the opposite position (i.e, they think they should be 180 degrees from where they are). On one occasion, this resulted in a pier collision. There was no  damage because the mount stops immediately. In such occasions, doing a "Find Home" command in APCC corrects the problem, so it is now my standard practice to "Find Home" when I power up the mount. But is this normal? I thought the encoders always keep track of where they are, so at most, I need to find home once when I power up the mount for the first time.

Connection details: connected via ethernet cable to the computer's ethernet port - no ethernet to USB, just direct ethernet, using APCC and powered using the supplied 24V regulated power supply.
Mike Hanson
 

Hi Arun,

A 180-degree error in RA calibration is caused by performing a sync while in a counterweight-up position.  An error in time/date/longitude can make a counterweight down position look like a counterweight up position to the mount near the meridian.  Make sure the ASCOM driver is told to "Convert SYNCs to RECALs".  If you use the APCC "GoTo/ReCal" tab, use the Recal instead of Sync unless you are certain of what you are doing.  If you Park using APCC or V5 keypad, rather than another application, the park position of a Mach 2 will be based on the encoder position, not coordinates.  So, Parking from APCC should work correctly on a Mach 2 even if the mount is lost.

There's nothing wrong with including "Find Home" in your workflow.  However, that won't prevent you from getting lost, it will only recover from lost. 

Regards,
Mike Hanson
Terri Zittritsch
 

On Fri, Mar 17, 2023 at 09:42 AM, Dale Ghent wrote:
Park and Home might appear to be the same concept, or at least very similar ones, but they have some important differences.

The concept of Parking is to put the mount in a defined orientation that no other command - turn tracking on, a slew button press on the keypad, a slew command from software on a connected PC, even a pulse guide command from a guiding app - cannot move it from. The mount will refuse all requests for movement until an Unpark is commanded. Think of it as a like a safety on a gun. Safe and Unsafe. Parked and Unparked.
This isn't entirely true on the A-P mount unless there is an unpark somewhere in some operations that I'm not aware of.  I have this experience frequently but maybe it's an error that needs fixing.

My mount will be parked, Park 3 is typical but not sure it matters.  

I will forget to unpark it and on my first slew using CDC and I will get an error.  The error says "From AstrophysicsV2.Telescope  The telescope driver report an error:  illegal operation while parked.  If you cannot fix this erorr, please contact the telescope driver author for assistance."      But immediately after the error, I will be able to slew because the mount is now unparked.     This is without doing any unpark command.    I have noticed this behavior since I have owned the Mach2, but haven't tried it with the 1100 yet (still waiting on ATS pier).

This might be something that needs fixing if it really should never be able to move unless an unpark command is done.    Unless of course, the CDC software tells the mount to unpark in the process of trying to get it to slew.      A software question.    I have not found any setting in the CDC software that shows an unpark command.

Terri
Linwood Ferguson
 

On Fri, Mar 17, 2023 at 09:42 AM, Dale Ghent wrote:
The concept of Parking is to put the mount in a defined orientation that no other command - turn tracking on, a slew button press on the keypad, a slew command from software on a connected PC, even a pulse guide command from a guiding app - cannot move it from. The mount will refuse all requests for movement until an Unpark is commanded. Think of it as a like a safety on a gun. Safe and Unsafe. Parked and Unparked.
I've been confused on this subject since a prior discussion (here) where Roland said: 

On Mon, Nov 28, 2022 at 12:03 PM, Roland Christen wrote:
Any time a move command is issued, this requires the mount to unpark.
Parking the mount disables power to the motors while keeping the electronics active so that they can respond to external commands. Whenever an external program issues any kind of move command, the motors must be re-energized. This will also start tracking unless you have set the tracking rate to STOP. In that case the RA motor will not track at the sidereal rate, but will keep the RA axis stationary.
It's been on my list to experiment.  My initial understanding matched Dale's, but I was surprised that day by it unparking (it has not since by the way), and Roland's answer. It makes it sound like the application (or maybe driver?) is responsible for polling to see if it is parked, and declining other commands? 

Linwood
Ray Gralak
 

This might be something that needs fixing if it really should never be able to move unless an unpark command is
done.
The error indicates the application (CDC) tried to perform an action while parked. That doesn't mean CDC didn't check for that error and unpark after that.

Also, if CDC could be sending certain raw commands through the ASCOM driver which may cause the mount to unpark.

-Ray
Roland Christen
 

Parks and home always should go where they are supposed to go. 
If the mount get an errant sync, it may look like it is lost, but it's really only doing what you told it. For example, you might have synced on Rigel when the scope was actually pointing at a completely different star. So the mount was basically lied to, and all subsequent slews will be off by that amount, and could well send the scope under the mount. Going to Home recalibrates the mount back to a known encoder position and will unscramble the errant recal. Going to a park will send the mount to the proper park positions also, but will not erase the errant recal.

Rolando


-----Original Message-----
From: Arun <arun.k.hegde@...>
To: main@ap-gto.groups.io
Sent: Mon, Mar 20, 2023 4:48 am
Subject: Re: [ap-gto] Park vs Home

I had a question related to homing my Mach 2.

I am a portable imager, meaning I disassemble and reassemble my mount/tripod.

I find that, on occasion, the encoders seem to forget where they are and, when I ask to park, go to the opposite position (i.e, they think they should be 180 degrees from where they are). On one occasion, this resulted in a pier collision. There was no  damage because the mount stops immediately. In such occasions, doing a "Find Home" command in APCC corrects the problem, so it is now my standard practice to "Find Home" when I power up the mount. But is this normal? I thought the encoders always keep track of where they are, so at most, I need to find home once when I power up the mount for the first time.

Connection details: connected via ethernet cable to the computer's ethernet port - no ethernet to USB, just direct ethernet, using APCC and powered using the supplied 24V regulated power supply.

--
Roland Christen
Astro-Physics
Roland Christen
 

CDC is telling the mount to unpark when it sends the slew command.

Roland


-----Original Message-----
From: Terri Zittritsch <theresamarie11@...>
To: main@ap-gto.groups.io
Sent: Tue, Mar 21, 2023 3:22 am
Subject: Re: [ap-gto] Park vs Home

On Fri, Mar 17, 2023 at 09:42 AM, Dale Ghent wrote:
Park and Home might appear to be the same concept, or at least very similar ones, but they have some important differences.

The concept of Parking is to put the mount in a defined orientation that no other command - turn tracking on, a slew button press on the keypad, a slew command from software on a connected PC, even a pulse guide command from a guiding app - cannot move it from. The mount will refuse all requests for movement until an Unpark is commanded. Think of it as a like a safety on a gun. Safe and Unsafe. Parked and Unparked.
This isn't entirely true on the A-P mount unless there is an unpark somewhere in some operations that I'm not aware of.  I have this experience frequently but maybe it's an error that needs fixing.

My mount will be parked, Park 3 is typical but not sure it matters.  

I will forget to unpark it and on my first slew using CDC and I will get an error.  The error says "From AstrophysicsV2.Telescope  The telescope driver report an error:  illegal operation while parked.  If you cannot fix this erorr, please contact the telescope driver author for assistance."      But immediately after the error, I will be able to slew because the mount is now unparked.     This is without doing any unpark command.    I have noticed this behavior since I have owned the Mach2, but haven't tried it with the 1100 yet (still waiting on ATS pier).

This might be something that needs fixing if it really should never be able to move unless an unpark command is done.    Unless of course, the CDC software tells the mount to unpark in the process of trying to get it to slew.      A software question.    I have not found any setting in the CDC software that shows an unpark command.

Terri

--
Roland Christen
Astro-Physics
ROBERT WYNNE
 

This is my understanding as well. Though the term /park/ may not be used in other applications the machine language is pretty much the same. I once had a situation where the programer had programmed the macine's software based on the inner diameter of a tube and so had programmed .060" as the inner diameter of the tube from which to start cutting. However, the cut should have actually been based on the tube's outer diameter.

Most importantly the laser rehomed the chuck every 120 degrees. this caused no end of variable variability on the final produce with most components barely passing within spec. It took me more time to persuade the team and R&D VP of the error than it took to run several parts to prove the error. When all was said and done the component was +/- .000050" from nominal and everyone suddenly was a happy camper.

My bonus that year didn't suffer either as the company had spent over 1 1/2 years attempting to solve the defective program by removing as much weight from the chucking mechanism all to no avail. -Best, Robert

On 03/21/2023 9:42 PM Roland Christen via groups.io <chris1011@...> wrote:


Parks and home always should go where they are supposed to go. 
If the mount get an errant sync, it may look like it is lost, but it's really only doing what you told it. For example, you might have synced on Rigel when the scope was actually pointing at a completely different star. So the mount was basically lied to, and all subsequent slews will be off by that amount, and could well send the scope under the mount. Going to Home recalibrates the mount back to a known encoder position and will unscramble the errant recal. Going to a park will send the mount to the proper park positions also, but will not erase the errant recal.

Rolando


-----Original Message-----
From: Arun <arun.k.hegde@...>
To: main@ap-gto.groups.io
Sent: Mon, Mar 20, 2023 4:48 am
Subject: Re: [ap-gto] Park vs Home
I had a question related to homing my Mach 2.

I am a portable imager, meaning I disassemble and reassemble my mount/tripod.

I find that, on occasion, the encoders seem to forget where they are and, when I ask to park, go to the opposite position (i.e, they think they should be 180 degrees from where they are). On one occasion, this resulted in a pier collision. There was no  damage because the mount stops immediately. In such occasions, doing a "Find Home" command in APCC corrects the problem, so it is now my standard practice to "Find Home" when I power up the mount. But is this normal? I thought the encoders always keep track of where they are, so at most, I need to find home once when I power up the mount for the first time.

Connection details: connected via ethernet cable to the computer's ethernet port - no ethernet to USB, just direct ethernet, using APCC and powered using the supplied 24V regulated power supply.

--
Roland Christen
Astro-Physics

1 - 14 of 14