1. main@ap-gto.groups.io
  2. Messages
   Date   
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@astronomyhouston.org
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
    Re: Dovelm162 springs too short or assembled wrong?

    Marj Christen
     

    Hello Tom,

     

    We are looking into this. Thank you for bringing it to our attention.

     

    Clear Skies,

    Marj Christen

    Astro-Physics

    11250 Forest Hills Road

    Machesney Park, IL 61115

    Phone: 815-282-1513

    www.astro-physics.com

     

    From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Tom Blahovici
    Sent: Wednesday, September 15, 2021 10:16 AM
    To: main@ap-gto.groups.io
    Subject: Re: [ap-gto] Dovelm162 springs too short or assembled wrong?

     

    That's interesting but the saddle is not new. Since I have to seen any other complaints in the past it must be something different now. What's AP going to do about this?
    Tom

    Re: Dovelm162 springs too short or assembled wrong?

    Tom Blahovici
     

    That's interesting but the saddle is not new. Since I have to seen any other complaints in the past it must be something different now. What's AP going to do about this?
    Tom
    Re: Dovelm162 springs too short or assembled wrong?

    M Hambrick
     

    The springs look like they are 0.36" OD X 0.27" ID X 1/2" long closed and ground end compression springs as shown below. The compressed length for the 1/2" long springs is 0.21". McMaster sells a similar spring that is 5/8" long, but the compressed length is 0.39". This may not allow the dovetail clamp to fully close. If I can find one at the local hardware store I will try it out and report back.

    One caveat is that these springs are zinc plated carbon steel. It would be better to have stainless steel springs. Another caveat is that the longer spring has a thicker wire diameter and requires more force to compress it.

    Mike
    Re: Dovelm162 springs too short or assembled wrong?

    Tom Blahovici
     

    In my case they just drop down right into the path of the dovetail.
    I just tried stretching the springs a bit and that has held. I don't know if that will be ok after weeks with the scope in place.
    The springs need to be longer! Other solutions like washers prevent the clamps from clamping well enough.

    Tom
    5221 - 5240 of 86240