Date   

Re: APCC Pro 1.9.0.7

Ray Gralak
 

Also, APPM Plate Solve & Sync is working again. 🙂
Thank you Bill, for confirming!

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Bill Long
Sent: Wednesday, September 15, 2021 8:32 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Pro 1.9.0.7

Also, APPM Plate Solve & Sync is working again. 🙂

________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak
<iogroups@...>
Sent: Wednesday, September 15, 2021 5:59 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APCC Pro 1.9.0.7

Hi Craig

I can confirm that the fixes to the DEC sign problem are now fixed in APCC Pro 1.9.0.7.
Thanks Heaps!
Thank you for finding and reporting this issue and confirming the fix!

Best regards,

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
Sent: Wednesday, September 15, 2021 2:19 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC Pro 1.9.0.7

Hi Ray,
I can confirm that the fixes to the DEC sign problem are now fixed in APCC Pro 1.9.0.7.
Thanks Heaps!
Craig







Re: APCC Pro 1.9.0.7

Bill Long
 

Also, APPM Plate Solve & Sync is working again. 🙂 


From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Ray Gralak <iogroups@...>
Sent: Wednesday, September 15, 2021 5:59 AM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: Re: [ap-gto] APCC Pro 1.9.0.7
 
Hi Craig

> I can confirm that the fixes to the DEC sign problem are now fixed in APCC Pro 1.9.0.7.
> Thanks Heaps!

Thank you for finding and reporting this issue and confirming the fix!

Best regards,

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Craig Young
> Sent: Wednesday, September 15, 2021 2:19 AM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APCC Pro 1.9.0.7
>
> Hi Ray,
> I can confirm that the fixes to the DEC sign problem are now fixed in APCC Pro 1.9.0.7.
> Thanks Heaps!
> Craig
>







Re: APPM - error

Ray Gralak
 

Hey Ron,

That doesn't look like an APPM message (it would say "APPM" in the title of the window). Are you sure it's not from the plate solver? Let me guess... ASTAP??

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Ron Kramer
Sent: Wednesday, September 15, 2021 7:03 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APPM - error

I'm trying to finally use APPM. (with nina). I updated my license. (106.00 is there sales tax on a license?)
anyway.

I start the Point model and after the first exposure. I get this error. Invalid floating point operation from
APPM ?






Re: APPM - error

Ron Kramer
 

Im' running  v1.9.0.7   9.14.21


APPM - error

Ron Kramer
 

I'm trying to finally use APPM.  (with nina).  I updated my license.  (106.00 is there sales tax on a license?) anyway.

I start the Point model and after the first exposure. I get this error.   Invalid floating point operation from APPM ? 

 


Re: Mach2 making strange sounds when moving to home position

Roland Christen
 

The problem may be unbalance in Dec. If not that, then we may have you slightly back off the Dec motor belt tension. That will fix it for sure, but is a bit more involved for you to do. Shoot me an e-mail if you need to.

Roland



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

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.

--
Roland Christen
Astro-Physics


Re: Erratic behavior, possibly contact related

Roland Christen
 

Your problem has nothing to do with the hand controller. It is just a planetarium program that only sends RA/Dec co-ordinates to the mount when you enter it. Otherwise it is silent and does not communicate with the mount for any reason.

The symptoms that you are experiencing suggest that the Dec motor encoder is not sending signals to the CP3 (or CP2) due to a faulty connection on the Dec portion of the Y cable. You may have to take the cover off the end of the cable connector and see if the wires are ok on the pins.

Here is one test you can do to see if it's the Dec connection: Unplug the Dec cable, plug the RA cable into the RA motor and turn on the mount. Does the RA track? Can you move the RA with the keypad E-W buttons at 12x, 64x, 600x? If so, then the RA portion is ok.

Now take the RA cable off the RA motor and plug it into the Dec motor. turn on the mount. If the Dec works the same as RA then the Dec motor and encoder are working, and the fault would be in the cable. If the Dec runs away, then there is something wrong with the Dec motor encoder.

Rolando

-----Original Message-----
From: M. Collins <aegle_observatory@...>
To: main@ap-gto.groups.io
Sent: Wed, Sep 15, 2021 6:26 pm
Subject: [ap-gto] Erratic behavior, possibly contact related

  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.

--
Roland Christen
Astro-Physics


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.
>






5781 - 5800 of 86811