Re: Possible bug in APCC with park?
Tom Blahovici
Hi
I noticed that the driver had park set to current position and not park 3. That will probably fix things but I have not tried yet. The setting was set in the past. Not sure why it changed. Tom
|
|
Re: Possible bug in APCC with park?
Chris White
Tom,
Are you using something in dragscript to define park 3? Or are you just asking voyager to park the mount? I use voyager and when my flats are done I have a command to just park the mount, and it parks to the default position in APCC. I use park 5. I also have park 5 as the default park position in the driver, although I'm not sure if that matters.
|
|
Re: Seeking CP3 Control Box with V2 Chip
Chris White
Well, I got my answer from Dave at Astro-Physics...
I may have misunderstood, so hopefully someone from AP can chime in to clarify. Apologies if I misrepresented.
|
|
Re: Seeking CP3 Control Box with V2 Chip
Bill Long
Well this makes a lot of sense. Thanks Chris.
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:34 PM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Seeking CP3 Control Box with V2 Chip Nope. CPx controllers (that aren't connected to Abs axis encoders) have no way to know when they are moved between mounts and they always assume the worm gear and wheel positions they currently have stored from their last power-up session are
valid when powering back up. And they also assume that any RA worm gear PEM data they currently have recorded is accurate and in-sync with the RA worm gear they are currently controlling. So when they are put on a new-or-different mount, or the same mount
that has had it's worm gears moved by some other means than under their direct control, they will have no idea that has happened. That results in bad or out-of-sync PEM data (same bad tracking results) and additionally the CPx controller will be "lost" until
it's first sky Sync/Calibration. And out-of-sync PEM data can and probably will make tracking worse than if the PEM data was turned off and not influencing tracking.
FWIW, AP mounts with Abs encoders do not have this problem with PEM data or worm gear & wheel positions.
"Always take the high road. There's less traffic."
Observatory Engineer
Summit Kinetics
Waikoloa, Hawaii
On Thu, Oct 7, 2021 at 8:07 PM Bill Long <bill@...> wrote:
|
|
Re: Seeking CP3 Control Box with V2 Chip
Bill Long
Why not?
From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of Konstantin von Poschinger <KPoschinger@...>
Sent: Thursday, October 7, 2021 11:27 PM To: main@ap-gto.groups.io <main@ap-gto.groups.io> Subject: Re: [ap-gto] Seeking CP3 Control Box with V2 Chip Simpli no!
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
Nope. CPx controllers (that aren't connected to Abs axis encoders) have no way to know when they are moved between mounts and they always assume the worm gear and wheel positions they currently have stored from their last power-up session are valid when powering back up. And they also assume that any RA worm gear PEM data they currently have recorded is accurate and in-sync with the RA worm gear they are currently controlling. So when they are put on a new-or-different mount, or the same mount that has had it's worm gears moved by some other means than under their direct control, they will have no idea that has happened. That results in bad or out-of-sync PEM data (same bad tracking results) and additionally the CPx controller will be "lost" until it's first sky Sync/Calibration. And out-of-sync PEM data can and probably will make tracking worse than if the PEM data was turned off and not influencing tracking. FWIW, AP mounts with Abs encoders do not have this problem with PEM data or worm gear & wheel positions. "Always take the high road. There's less traffic." Observatory Engineer Summit Kinetics Waikoloa, Hawaii
On Thu, Oct 7, 2021 at 8:07 PM Bill Long <bill@...> wrote:
|
|
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@...> 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
|
|