|
Re: Seeking CP3 Control Box with V2 Chip
Simpli no!
toggle quoted messageShow quoted text
Grüsse Konstantin v. Poschinger Hammerichstr. 5 22605 Hamburg 040/8805747 0171/1983476
Am 08.10.2021 um 08:07 schrieb Bill Long <bill@...>:
|
|
|
|
Re: Seeking CP3 Control Box with V2 Chip
Bill Long
But if the mount isn't moving at all when it's connected, wouldn't it query to figure out the current position?
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Christopher Erickson <christopher.k.erickson@...>
Sent: Thursday, October 7, 2021 11:02 PM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Seeking CP3 Control Box with V2 Chip No.
CPx controllers always know the worm gear positions of both axes by saving them to NV memory just before losing power when power is disconnected. A freshly-connected CPx controller has no idea where the worms are positioned when first connected.
"Always take the high road. There's less traffic."
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii
On Thu, Oct 7, 2021 at 7:59 PM Bill Long <bill@...> wrote:
|
|
|
|
Re: Seeking CP3 Control Box with V2 Chip
No. CPx controllers always know the worm gear positions of both axes by saving them to NV memory just before losing power when power is disconnected. A freshly-connected CPx controller has no idea where the worms are positioned when first connected. "Always take the high road. There's less traffic." Observatory Engineer Summit Kinetics Waikoloa, Hawaii
On Thu, Oct 7, 2021 at 7:59 PM Bill Long <bill@...> wrote:
|
|
|
|
Re: Seeking CP3 Control Box with V2 Chip
Bill Long
Wouldn't the new box know that once it's powered on and connected to the motors?
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Christopher Erickson <christopher.k.erickson@...>
Sent: Thursday, October 7, 2021 7:44 PM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Seeking CP3 Control Box with V2 Chip I don't agree. Changing CPx controllers requires that a new PEM recording takes place. There is no way for a new CPx controller to know where the old CPx controller left the worm gear positions at.
On Thu, Oct 7, 2021, 3:50 PM Chris White <chris.white@...> wrote:
For those interested, I spoke with Dave today and as long as the mount doesn't move it is OK to download your PEC curve, change CP's and then upload that curve to the new unit.
|
|
|
|
Re: APCC: RA limit reached while in Park 3?
#APCC
Glenn
Howard, thank you for speaking to me on the phone today.
For the benefit of others, I will repeat what you told me to do to attempt to solve the problem.
I then reconfigured the driver for use with APCC Pro and tried to connect to the mount. I got this error, which is what has appeared since the beginning.  I don't even have to connect to the driver to get this error. It appears as soon as I connect to the mount. Does anyone know what might be causing this? Thank you, Glenn
|
|
|
|
Re: Seeking CP3 Control Box with V2 Chip
I don't agree. Changing CPx controllers requires that a new PEM recording takes place. There is no way for a new CPx controller to know where the old CPx controller left the worm gear positions at.
On Thu, Oct 7, 2021, 3:50 PM Chris White <chris.white@...> wrote: For those interested, I spoke with Dave today and as long as the mount doesn't move it is OK to download your PEC curve, change CP's and then upload that curve to the new unit.
|
|
|
|
Re: #APCC #Mach2 - 3D viewer weird scope position while it is parked (or even while slewing sometimes) #apcc
#APCC
Sébastien Doré
Hi, just to let people know that Roland and Team (yes, with a capital T, they deserve it !) are kindly working with me in the background on this, which is why the thread has gone silent.
Quadruple 'A' service from AP, as usual. Clear skies, Sébastien
|
|
|
|
Re: Seeking CP3 Control Box with V2 Chip
Chris White
For those interested, I spoke with Dave today and as long as the mount doesn't move it is OK to download your PEC curve, change CP's and then upload that curve to the new unit.
|
|
|
|
Re: Interesting Park using NINA
michael mccann
Hey Wade
toggle quoted messageShow quoted text
I’m not in Rusty’s. But I see him a couple times a week. So I will. Are you back near Ellensburg, do I have that right? I know I was supposed to come by sometime this summer, but the summer went by too fast. I’ll look into that. I didn’t know that was an option.
On Oct 7, 2021, at 15:30, W Hilmo <y.groups@hilmo.net> wrote:
|
|
|
|
Re: AP1100 mount encoder and servos errors
Hi Max,
Please zip and email me a log file that shows this.
|
|
|
|
Re: AP1100 mount encoder and servos errors
Roland Christen
Make sure all your cables are plugged in and the encoder lights are green or blue. Check the encoder cable inside the Dec axis to make sure it is seated.
Roland
-----Original Message-----
From: Max Mirot via groups.io <titansmoons@...> To: main@ap-gto.groups.io Sent: Thu, Oct 7, 2021 2:57 pm Subject: [ap-gto] AP1100 mount encoder and servos errors I am see/clearing frequent errors on the AP1100.
I rebalance last night. It did not help. Load is AP Honders and a camera. Log attached Suggestions? Thanks Max Mirot -- Roland Christen Astro-Physics
|
|
|
|
Re: Possible bug in APCC with park?
Tom Blahovici
Well I disagree with always using apcc to do a park. In Voyager if you are done for the night it should park where you have set the park.
If you are automating everything, the final step will be to park. So bottom line is I think Voyager is not always doing a park 3. Tom
|
|
|
|
Re: Possible bug in APCC with park?
Tom Blahovici
Actually, I think that this is something to do with Voyager. Perhaps a new release.
When I am done at night, i select point at zenith in Voyager. It is not park. Then I stop tracking in Voyager. Last night, I finished the flats then I selected track in Voyager and attempted the usual park. In the past it would always go to park 3. To Last night it went to the zenith again. However apcc then did the proper park to park 3. What was different from the night before was I did not select track before I parked. I need to investigate why Voyager no longer parks at park 3. Tom
|
|
|
|
Re: Possible bug in APCC with park?
Roland Christen
You need a remote controlled umbrella. British style, big and boisterous.
Rolando
-----Original Message-----
From: ap@... <ap@...> To: main@ap-gto.groups.io <main@ap-gto.groups.io> Sent: Thu, Oct 7, 2021 3:33 pm Subject: Re: [ap-gto] Possible bug in APCC with park? Howard Hedlund wrote:
I’ll add one flavor onto this.
I have the APCC park default set to 3, which is where I load and unload the OTA. In park 3 though, the telescope points (somewhat) up.
I have the Ascom V2 driver set to park 2. It has a separate default. The reason for this is that if rain is detected, the safety monitor tells NINA to tell ASCOM to do a park. Park 2 points the telescope horizontally, where less rain
will hit the objective while I run outside to haul things inside, also I think most of the other devices are less vulnerable level. Note this is a “safety” inside NINA from an ASCOM safety monitor, not the same as APCC’s safety which is related to a disconnect.
So I agree with what you said sort of – I always manually park from APCC. But I have the other set up for a different purpose. It is nice that there are two defaults (actually three counting safety park in APCC).
FWIW.
Linwood
-- Roland Christen Astro-Physics
|
|
|
|
Re: Interesting Park using NINA
W Hilmo
Are you at Rusty’s by chance?
toggle quoted messageShow quoted text
If so, say hi to Dennis and Dianne for me. Regarding the time zone issue, if your computer is 100% dedicated to the observatory, you might consider setting it up on UTC, with no DST changes.
On Oct 7, 2021, at 1:51 PM, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> wrote:
|
|
|
|
Re: Interesting Park using NINA
michael mccann
Come to think of it, and I forgotten until you mentioned it, NINA asks whether to sync ‘NINA to mount’ or ‘mount to NINA’ . And I know I chose ‘NINA to mount’. I guess it should be the other way around. If it’s not to cloudy tonight I’ll change that.
toggle quoted messageShow quoted text
Cheers
On Oct 7, 2021, at 15:08, Dale Ghent <daleg@elemental.org> wrote:
|
|
|
|
Re: Interesting Park using NINA
Dale Ghent
I honestly can't explain why there's a difference between an external app such as NINA telling the driver to park, and the driver's own park button giving different results. I would think that both interfaces run the same logic underneath. Perhaps Ray can shed some light on this mechanism.
toggle quoted messageShow quoted text
But given a correct PC and mount time and a reasonable lat/long, parking should always be successful and fine assuming your mount is properly aligned, something that can be done with a single plate solve. Time zones aren't going to have a bearing on the mount's internal clock. Like your PC, the system clock actually runs in UTC time, with whatever timezone you have configured applied to it for purposes of display. What I bet *might* be happening in your case is that you have the keypad connected to your mount and it's not set for an EXT auto connect. So when your mount is powering on, the time that's configured in the keypad is immediately getting applied to the CP when the keypad initializes it. This could possibly explain some mount/PC time mismatch or wonkiness. With the Sync Time options I pointed out before, you can set the keypad to EXT in its autoconnect setting which will allow the ASCOM driver to initialize the mount when it connects.
On Oct 7, 2021, at 16:50, michael mccann via groups.io <mmccawsprojects=icloud.com@groups.io> wrote:
|
|
|
|
Re: Interesting Park using NINA
michael mccann
You know that might be. I’m living in New Mexico, but so close to Arizona my computer always tell me my time is an hour earlier. I’m out in the countryside where I get my time from cell/data and not a regular network. I thought I had corrected this problem on my computer because I set the display time for mountain time zone, but when you look at all the settings it shows that it thinks it’s in Pacific time zone. I tried several times to change it. Software comes back says that I don’t have permission to, and yet I’m the administrator.
So finalizing the park is best from AP ASCOM.
|
|
|
|
Re: Possible bug in APCC with park?
ap@CaptivePhotons.com
Howard Hedlund wrote:
I’ll add one flavor onto this.
I have the APCC park default set to 3, which is where I load and unload the OTA. In park 3 though, the telescope points (somewhat) up.
I have the Ascom V2 driver set to park 2. It has a separate default. The reason for this is that if rain is detected, the safety monitor tells NINA to tell ASCOM to do a park. Park 2 points the telescope horizontally, where less rain will hit the objective while I run outside to haul things inside, also I think most of the other devices are less vulnerable level. Note this is a “safety” inside NINA from an ASCOM safety monitor, not the same as APCC’s safety which is related to a disconnect.
So I agree with what you said sort of – I always manually park from APCC. But I have the other set up for a different purpose. It is nice that there are two defaults (actually three counting safety park in APCC).
FWIW.
Linwood
|
|
|
|
Re: Possible bug in APCC with park?
Hi Tom,
Just a few brief thoughts:
|
|
|