Date   

Re: Mach2 making strange sounds when moving to home position

Harold
 

I’m using your 24 V power supply, I redid  the test using 600, 1000 and 1800. It is no longer making the noise. If it happens again I’ll contact you.


Re: Mach2 making strange sounds when moving to home position

Harold
 

Roland, I’m using 24v


Erratic behavior, possibly contact related

M. Collins
 

  I'm part of a group at Lowell Observatory tasked with acquiring a new 1 meter-class telescope and instrumentation to replace one of our older research telescopes which is no longer viable to maintain. One of the associated activities is an assessment of sites available for the new telescope. For that, we have some observers using 14" SCTs with a mask that allows light to pass directly through a ca. 80 mm aperture on one side of the secondary, with a second aperture opposite that has an optical wedge in place to divert the light passing through slightly. At the focal plane, a double image is produced. Each image is affected by seeing effects in the atmosphere, resulting in small differential movements of the images with respect to each other. By measuring the amplitude of these movements as a function of time, a quantitative measure of seeing quality can be obtained. For our tests, two telescopes are operated simultaneously at candidate sites, each recording sequences of images of second magnitude and brighter stars. The data sets collected are later processed using analysis software and the results compared to determine which site provides better seeing on average.

  One of the mounts was the original Celestron fork driven using a synchronous motor and variable rate drive controller. It's not too bad so far as it goes, however there is sufficient periodic error to make sub-frame imaging difficult. Also, the mount does not lend itself to remote operation. I have a 1200GTO mount which has been in storage for a couple of years awaiting a new home, so I volunteered it for the duration of the seeing tests. It was a simple matter to fabricate an adapter plate to go between the mount and the C14 tripod, and we were ready to go on sky last Monday. The first night out, we polar aligned and had just started capturing data sets (1000 frames at 20 ms cadence, repeated at 10 minute intervals) with Deneb as a target when clouds rolled in. The mount has a CP3 controller I recently purchased on the used equipment market. Since that controller can operate at up to 16 V, a 15 V supply with the appropriate locking connector was secured to the tripod. Everything was in good working order up the point that I departed the site. The observer stayed on and was able to capture a few more sets later that night before the clouds eventually prevailed.

  The following night was clear, and it was during initial start-up activities in twilight that things started going wrong. The report I received afterward was that the mount ran away in declination while seeking to the first target, slewing far beyond and not responding to the stop button on the hand controller. The observer powered off, manually moved to Park 1, and powered on again. Before it was possible to perform a sync, it ran away again, so the observer shut down for the night.

  I visited the site the following day, bringing with me the original CP2 controller as well as the 12 V power supply which I had used when the mount was in my observatory a few years ago. Without changing any components but after confirming that all of the connections were secure, I found that the mount was again running away, sometimes in right ascension as well as declination. Replacing the power supply had no effect, so I also substituted the CP2. Again, the problem resurfaced within a few seconds of the first attempt to move in either axis. I also noted that the motors would stop and start erratically during slews, sometimes in very rapid succession, regardless of the power supply or controller being used.

  The only remaining electronic element was the hand controller. I removed the cover and first measured the voltage of the lithium cell. No problem there, as it was about 3.1 V. I next confirmed continuity of the four wires which are used in the coiled cable, aggressively flexing the cable at each end in case an internal conductor is intermittent at certain orientations. Still no sign of a failure. The last step was simply cycling (disconnecting then reconnecting) each of the cable connectors which mate with the main board in the controller. Since these connectors used tinned contacts, it's possible for marginally- to non-conducting oxide layers to form over time. Cycling the connectors will generally abrade the oxide sufficiently to expose new metal-to-metal contact, renewing the connection (for a while).

  After reassembling the hand controller and going through the power up sequence again, the mount returned to its usual, flawless self. Seeing no issues after ten minutes or so, I reinstalled the CP3 and 15 V power supply. I drove it around the daytime sky for at least an hour, initially with the hand controller, then using Stellarium across a serial link, and never saw the slightest indication of an error. It's been in use without issue from twilight until after midnight each night since.

  I don't know details about the communications across the serial link between the hand controller and the CPx, so it's not possible to propose a failure mechanism related to faulty or intermittent contact that can explain the behavior we saw. That said, cycling the connectors in the hand controller was the only action taken which appears to have corrected the problem. To my knowledge, that controller was purchased along with the mount, probably sometime around 1990, so an age related contact issue is not beyond the realm of plausibility. Going forward, it will be my practice to slide each of the connectors off and back onto the pins inside the controller once or twice any time I open it up to replace the coin cell.

  Passing the information along in case it might be useful to someone else. If what I did solved what appeared to be a serious problem, it's a very easy fix.


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Eric Weiner
 

Roland,

Good topic. Does the ortho model also remain in the CP5 if you send the Mach2 to Home? Is there a way to clear it in cases where I want to use different scopes on the mount but aren’t concerned about orthogonality on one of them?

Thanks,

Eric


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland Christen
 

We are working on making all keypad modeling available for the CP4.

Roland



-----Original Message-----
From: Konstantin von Poschinger <KPoschinger@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 5:33 pm
Subject: Re: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Hi Roland,

will the ortho setting also work with the new keypad software and a older not Mach2 Mount with a GTOCP4 box?

Grüsse

Konstantin v. Poschinger


Hammerichstr. 5
22605 Hamburg
040/8805747
0171/1983476

Am 16.09.2021 um 00:27 schrieb Roland Christen via groups.io <chris1011@...>:



Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)
No, the Ortho is always on regardless of whether you use or turn off any of the other keypad models. Once you enter ortho data it stays there until you overwrite it by doing a new ortho routine.

Roland


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 5:04 pm
Subject: Re: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland and Ray,

   Thanks so much for the very detailed answers, I have a much clearer picture of how it all works together now. Your answers address all of my confusion. I think I also understand the pitfall situations you can get into.

   I do have one more question prompted by your comment below.

On Wed, Sep 15, 2021 at 11:29 AM, Roland Christen wrote:
The keypad model resides in the CP controller and is used to compensate for non-orthogonality at all times, whether an external model is used or not. Once created, it does not turn off.
   I now understand that the Keypad Ortho Model resides (more or less permanently) in the CP5 controller. Once created, it resides in the CP5 until such time as it is overwritten by doing a new Keypad Ortho Model. My new questions then, are as follows:

  1. Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)

  2. If the Ortho Model can effectively be turned off (as in question 1), is the same Keypad Ortho Model restored when you enable PntOn (even though I never intend to create a Keypad Pointing Model -- I only plan to use the Keypad Ortho Model). Or, once Keypad Modeling is turned off, I would need to create a new Keypad Ortho Model?


John

--
Roland Christen
Astro-Physics

--
Roland Christen
Astro-Physics


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Konstantin von Poschinger
 

Hi Roland,

will the ortho setting also work with the new keypad software and a older not Mach2 Mount with a GTOCP4 box?

Grüsse

Konstantin v. Poschinger


Hammerichstr. 5
22605 Hamburg
040/8805747
0171/1983476

Am 16.09.2021 um 00:27 schrieb Roland Christen via groups.io <chris1011@...>:



Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)
No, the Ortho is always on regardless of whether you use or turn off any of the other keypad models. Once you enter ortho data it stays there until you overwrite it by doing a new ortho routine.

Roland


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 5:04 pm
Subject: Re: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland and Ray,

   Thanks so much for the very detailed answers, I have a much clearer picture of how it all works together now. Your answers address all of my confusion. I think I also understand the pitfall situations you can get into.

   I do have one more question prompted by your comment below.

On Wed, Sep 15, 2021 at 11:29 AM, Roland Christen wrote:
The keypad model resides in the CP controller and is used to compensate for non-orthogonality at all times, whether an external model is used or not. Once created, it does not turn off.
   I now understand that the Keypad Ortho Model resides (more or less permanently) in the CP5 controller. Once created, it resides in the CP5 until such time as it is overwritten by doing a new Keypad Ortho Model. My new questions then, are as follows:

  1. Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)

  2. If the Ortho Model can effectively be turned off (as in question 1), is the same Keypad Ortho Model restored when you enable PntOn (even though I never intend to create a Keypad Pointing Model -- I only plan to use the Keypad Ortho Model). Or, once Keypad Modeling is turned off, I would need to create a new Keypad Ortho Model?


John

--
Roland Christen
Astro-Physics


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland Christen
 


Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)
No, the Ortho is always on regardless of whether you use or turn off any of the other keypad models. Once you enter ortho data it stays there until you overwrite it by doing a new ortho routine.

Roland


-----Original Message-----
From: John Upton <upton@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 5:04 pm
Subject: Re: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland and Ray,

   Thanks so much for the very detailed answers, I have a much clearer picture of how it all works together now. Your answers address all of my confusion. I think I also understand the pitfall situations you can get into.

   I do have one more question prompted by your comment below.

On Wed, Sep 15, 2021 at 11:29 AM, Roland Christen wrote:
The keypad model resides in the CP controller and is used to compensate for non-orthogonality at all times, whether an external model is used or not. Once created, it does not turn off.
   I now understand that the Keypad Ortho Model resides (more or less permanently) in the CP5 controller. Once created, it resides in the CP5 until such time as it is overwritten by doing a new Keypad Ortho Model. My new questions then, are as follows:

  1. Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)

  2. If the Ortho Model can effectively be turned off (as in question 1), is the same Keypad Ortho Model restored when you enable PntOn (even though I never intend to create a Keypad Pointing Model -- I only plan to use the Keypad Ortho Model). Or, once Keypad Modeling is turned off, I would need to create a new Keypad Ortho Model?


John

--
Roland Christen
Astro-Physics


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

John Upton
 

Roland and Ray,

   Thanks so much for the very detailed answers, I have a much clearer picture of how it all works together now. Your answers address all of my confusion. I think I also understand the pitfall situations you can get into.

   I do have one more question prompted by your comment below.

On Wed, Sep 15, 2021 at 11:29 AM, Roland Christen wrote:
The keypad model resides in the CP controller and is used to compensate for non-orthogonality at all times, whether an external model is used or not. Once created, it does not turn off.
   I now understand that the Keypad Ortho Model resides (more or less permanently) in the CP5 controller. Once created, it resides in the CP5 until such time as it is overwritten by doing a new Keypad Ortho Model. My new questions then, are as follows:

  1. Does the Keypad Ortho Model get turned off in the CP5 when you explicitly turn off all Modeling in the Keypad menu? (Main_Menu | 8-Model Status | ModOff)

  2. If the Ortho Model can effectively be turned off (as in question 1), is the same Keypad Ortho Model restored when you enable PntOn (even though I never intend to create a Keypad Pointing Model -- I only plan to use the Keypad Ortho Model). Or, once Keypad Modeling is turned off, I would need to create a new Keypad Ortho Model?


John


Re: Mach2 making strange sounds when moving to home position

Roland Christen
 

In case you didn't see my previous e-mail: What is your power source?

The button rates (xand 1200x) are not the same as the slew rate. The slew rate during a move to Home or to any sky position is normally 1800x when you use a 24 volt supply. Your supply might have insufficient power for that speed. Try setting the slew rate to 1000x and see if the noise goes away.

Roland Christen
Astro-Physics Inc.

-----Original Message-----
From: Harold <hfm5022@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 3:51 pm
Subject: [ap-gto] Mach2 making strange sounds when moving to home position

My Mach2 to it’s making some strange sounds (vibration) when moving to the Home position. It happens in the dec axis moving counter clockwise (north) for the last 15-20 degrees. It will happen with different slew rates I’ve tried both 1200 and 600. It does not happen when I move  the dec axis using the Apcc direction arrows. Only when Apcc is sending the mount to home position. 

--
Roland Christen
Astro-Physics


Re: Mach2 making strange sounds when moving to home position

Roland Christen
 

Are you using 12 volt supply or 24?

Rolando

-----Original Message-----
From: Harold <hfm5022@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 3:51 pm
Subject: [ap-gto] Mach2 making strange sounds when moving to home position

My Mach2 to it’s making some strange sounds (vibration) when moving to the Home position. It happens in the dec axis moving counter clockwise (north) for the last 15-20 degrees. It will happen with different slew rates I’ve tried both 1200 and 600. It does not happen when I move  the dec axis using the Apcc direction arrows. Only when Apcc is sending the mount to home position. 

--
Roland Christen
Astro-Physics


Mach2 making strange sounds when moving to home position

Harold
 

My Mach2 to it’s making some strange sounds (vibration) when moving to the Home position. It happens in the dec axis moving counter clockwise (north) for the last 15-20 degrees. It will happen with different slew rates I’ve tried both 1200 and 600. It does not happen when I move  the dec axis using the Apcc direction arrows. Only when Apcc is sending the mount to home position. 


Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

billk@...
 
Edited

Thanks Ray, 

I ran both as admin and switched to 32 bit and that did the trick. Really appreciate the assist.
--
Bill Kowalczyk

billk@...


Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

Bill Long
 

I was just coming to suggest the single run as admin thing. That is probably the issue. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <iogroups@...>
Sent: Wednesday, September 15, 2021 10:42 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)
 
>        Failed to connect to Camera: COIeException: Invalid class string (800401F3) SCODE: 800401f3.

That means the SkyX ActiveX camera control has not been registered by the system.

If you are not running the latest build (13150 or greater) of SkyX, you should update.

 If that doesn't help, you might try running SkyX Pro and APPM once "as administrator." This might allow SkyX to register its ActiveX camera control.

Also, make sure you are running a 32-bit version of SkyX.

If these fail to help you might want to post a support question to the Software Bisque forum, and they might be able to help you register their ActiveX camera control.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of billk@...
> Sent: Wednesday, September 15, 2021 9:33 AM
> To: main@ap-gto.groups.io
> Subject: [ap-gto] APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in
> APPM)
>
> [Edited Message Follows]
>
> I was wondering if anyone has encountered an error message when attempting to connect APPM to SkyX Pro
> Camera for plate solving (per the APCC manual)? I am getting the following message and I cannot seem to
> find another person that has had the same issue:
>
>
>        Failed to connect to Camera: COIeException: Invalid class string (800401F3) SCODE: 800401f3.
>
> I have been using an SBIG STT 8300 with The Sky for plate solving and it has not had any issues. I also made
> my guide camera primary to see if that made a difference and it did not. It seems to be some kind of issue
> between APPM and SkyX
>
> Thanks -
>
> Bill K.
>







Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

Ray Gralak
 

Failed to connect to Camera: COIeException: Invalid class string (800401F3) SCODE: 800401f3.
That means the SkyX ActiveX camera control has not been registered by the system.

If you are not running the latest build (13150 or greater) of SkyX, you should update.

If that doesn't help, you might try running SkyX Pro and APPM once "as administrator." This might allow SkyX to register its ActiveX camera control.

Also, make sure you are running a 32-bit version of SkyX.

If these fail to help you might want to post a support question to the Software Bisque forum, and they might be able to help you register their ActiveX camera control.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of billk@...
Sent: Wednesday, September 15, 2021 9:33 AM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in
APPM)

[Edited Message Follows]

I was wondering if anyone has encountered an error message when attempting to connect APPM to SkyX Pro
Camera for plate solving (per the APCC manual)? I am getting the following message and I cannot seem to
find another person that has had the same issue:


Failed to connect to Camera: COIeException: Invalid class string (800401F3) SCODE: 800401f3.

I have been using an SBIG STT 8300 with The Sky for plate solving and it has not had any issues. I also made
my guide camera primary to see if that made a difference and it did not. It seems to be some kind of issue
between APPM and SkyX

Thanks -

Bill K.


Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

Bill Long
 

Yes, even local connections to SkyX use the TCP Server component. If that is checked, and the camera is connected in SkyX, APPM should be able to connect if SkyX Camera is selected. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of billk@... <billk@...>
Sent: Wednesday, September 15, 2021 10:30 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)
 

[Edited Message Follows]

Hi Bill,

Yes that is checked and it is listening for connections. Is that necessary with everything local? Some more info is that I have SkyX selected on both the run tab and the plate solving tab and have SkyX running. I'm going to set everything up on a separate machine the same way to see if I get the same error.

--
Bill Kowalczyk

billk@...


Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

billk@...
 
Edited

Hi Bill,

Yes that is checked and it is listening for connections. Is that necessary with everything local? Some more info is that I have SkyX selected on both the run tab and the plate solving tab and have SkyX running. I'm going to set everything up on a separate machine the same way to see if I get the same error.

--
Bill Kowalczyk

billk@...


Re: APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)

Bill Long
 

The first question to ask is if the TCP Server checkbox is set in SkyX to allow remote connections. 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of billk@... <billk@...>
Sent: Wednesday, September 15, 2021 9:32 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] APPM Camera: SkyX Pro Camera Connect Error Message (plate solver link to The SkyX in APPM)
 
I was wondering if anyone has encountered an error message when attempting to connect APPM to SkyX Pro Camera for plate solving (per the APCC manual)? I am getting the following message and I cannot seem to find another person that has had the same issue:
Failed to connect to Camera: COIeException: Invalid class string (800401F3) SCODE: 800401f3.
I have been using an SBIG STT 8300 with The Sky for plate solving and it has not had any issues. I also mading my guide camera primary to see if that made a difference and it did not. It seems to be some kind of issue between APPM and SkyX

Thanks - 

Bill K.


Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

Roland Christen
 


  • Does the APCC model erase the results of the Keypad Ortho Model or simply override it?

  • If the APCC pointing corrections are turned off, does the most recent Keypad Ortho Model once again take effect or does a new one need to be built?
  • APCC does not erase the keypad ortho model. The keypad model resides in the CP controller and is used to compensate for non-orthogonality at all times, whether an external model is used or not. Once created, it does not turn off. External models will actually use it without knowing that it's there. It is as if the scope is now perfectly orthogonal, so any external model would not have any ortho component in their data.

    Rolando


    -----Original Message-----
    From: John Upton <upton@...>
    To: main@ap-gto.groups.io
    Sent: Tue, Sep 14, 2021 9:56 pm
    Subject: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

    Hi all,

       I am looking for some clarifications regarding the interactions / interoperability of the Ortho Model performed by the Keypad versus the pointing model created by APCC? The questions I want to understand are:

    1. I assume the APCC model takes precedence when a Keypad Ortho Model has been built. Is that correct?

    2. Does the APCC model erase the results of the Keypad Ortho Model or simply override it?

    3. If the APCC pointing corrections are turned off, does the most recent Keypad Ortho Model once again take effect or does a new one need to be built?
       For some observing and simple single object imaging sessions, I think I would like to just have the orthogonality error corrected without creating / running a normal pointing model. It would simplify / speed up plate solving on both sides of the meridian. Ideally, for a quick portable imaging session, I would prefer not to have to rerun the Keypad Ortho Model at the beginning of each session when I don't want to run APPM. I will be guiding for these sessions and since they involve only a single target, plate solving will suffice for the evening's only target.


    John

    --
    Roland Christen
    Astro-Physics


    Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

    Roland Christen
     


    You should not simultaneously use an APCC model with the keypad model, as they do not know about each other!
    You can use them but only if you first create the keypad ortho model and load it into the CP4/5. Once that is done, it will simply make pointing for external models easier.

    What you should not do is to create a keypad ortho model after making an APCC model, since that will negate the one in APCC.

    Roland


    -----Original Message-----
    From: Ray Gralak <iogroups@...>
    To: main@ap-gto.groups.io
    Sent: Tue, Sep 14, 2021 10:52 pm
    Subject: Re: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

    Hi John,

    >    I am looking for some clarifications regarding the interactions / interoperability of the Ortho Model
    > performed by the Keypad versus the pointing model created by APCC? The questions I want to understand
    > are:

    You should not simultaneously use an APCC model with the keypad model, as they do not know about each other!

    -Ray

    > -----Original Message-----
    > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of John Upton
    > Sent: Tuesday, September 14, 2021 7:56 PM
    > To: main@ap-gto.groups.io
    > Subject: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC
    > #Keypad
    >
    > Hi all,
    >
    >    I am looking for some clarifications regarding the interactions / interoperability of the Ortho Model
    > performed by the Keypad versus the pointing model created by APCC? The questions I want to understand
    > are:
    >
    >
    >
    > 1.    I assume the APCC model takes precedence when a Keypad Ortho Model has been built. Is that
    > correct?
    >
    >
    > 2.    Does the APCC model erase the results of the Keypad Ortho Model or simply override it?
    >
    >
    > 3.    If the APCC pointing corrections are turned off, does the most recent Keypad Ortho Model once again
    > take effect or does a new one need to be built?
    >
    >    For some observing and simple single object imaging sessions, I think I would like to just have the
    > orthogonality error corrected without creating / running a normal pointing model. It would simplify / speed up
    > plate solving on both sides of the meridian. Ideally, for a quick portable imaging session, I would prefer not to
    > have to rerun the Keypad Ortho Model at the beginning of each session when I don't want to run APPM. I will
    > be guiding for these sessions and since they involve only a single target, plate solving will suffice for the
    > evening's only target.
    >
    >
    > John
    >







    --
    Roland Christen
    Astro-Physics


    Re: Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

    Roland Christen
     

    The CP4/5 controllers are totally independent of anything that APCC does. APCC models are not loaded into the CP controllers.

    The way it works is like this:

    1) if you do NOT create an Ortho model with the keypad, then APCC models will naturally create their own and compensate automatically for any non-orthogonality.

    2) if you first create an Ortho model with the keypad, that model will be loaded into the mount's CP servo controller and will therefore be active at all times. If you then create a pointing model with APCC, it will simply respond to the way the mount now points more accurately and will naturally not have an ortho model built into its own model.

    An ortho model that is created using the keypad will reside in the mount's controller at all times and be active from then on, regardless of power cycles. If you change the scope to something different that has a different orthogonality error, then you simply run the ortho routine for that setup.

    If you first model a new setup with APCC and then create a new ortho model with the keypad, then you will have two orthos that will negate each other.

    Roland


    -----Original Message-----
    From: John Upton <upton@...>
    To: main@ap-gto.groups.io
    Sent: Tue, Sep 14, 2021 9:56 pm
    Subject: [ap-gto] Interactions Between Keypad and APCC Orthogonality Models? #Mach2GTO #APCC #Keypad

    Hi all,

       I am looking for some clarifications regarding the interactions / interoperability of the Ortho Model performed by the Keypad versus the pointing model created by APCC? The questions I want to understand are:

    1. I assume the APCC model takes precedence when a Keypad Ortho Model has been built. Is that correct?

    2. Does the APCC model erase the results of the Keypad Ortho Model or simply override it?

    3. If the APCC pointing corrections are turned off, does the most recent Keypad Ortho Model once again take effect or does a new one need to be built?
       For some observing and simple single object imaging sessions, I think I would like to just have the orthogonality error corrected without creating / running a normal pointing model. It would simplify / speed up plate solving on both sides of the meridian. Ideally, for a quick portable imaging session, I would prefer not to have to rerun the Keypad Ortho Model at the beginning of each session when I don't want to run APPM. I will be guiding for these sessions and since they involve only a single target, plate solving will suffice for the evening's only target.


    John

    --
    Roland Christen
    Astro-Physics

    5861 - 5880 of 86884