Date   

Concrete pier

Howard Ritter
 

I want to put my upcoming AP 1600GTO on a concrete pier. My plan is to dig a 24” circular pit a foot deep, auger a 12” hole 3-4’ deep in the middle of this, put a 7-8’ Sonotube down to the bottom, pound some rebars into the ground at the bottom to fix them in place, fill the pit with concrete as a stabilizing collar, and then fill the Sonotube with concrete for a pier about 42” high.

So, a small pit, a hole, an 8'Sonotube and 30’ of rebar, a few cubic ft. of concrete. Do it myself? Sounds like a fair amount of work, plus renting an auger and an electric mixer. Contract it out? How expensive can that be? Sounds like a better deal to me!

Well. The estimate from the neighborhood landscape contractor – if I dig the 2’ x 1’ pit - was $4450! He didn’t itemize the estimate, but I just cannot conceive of how such a figure was attained. I looked at it twice, and it’s not $445.00 with a zero missing.

This is now a DIY project after all. Advice?

—howard


Re: APCC/Driver exception

david w pearson
 

Thanks Ray for the confirmation!
Appreciate it as always!!!
dave

On Friday, November 5, 2021, 08:16:10 AM PDT, Ray Gralak <iogroups@...> wrote:


Hi David,

The logic can be summarized as follows:

In ASCOM, to perform an RA/Dec slew, the mount must be unparked and tracking.

-Ray

> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
> Sent: Thursday, November 4, 2021 9:44 AM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APCC/Driver exception
>
> Let me confirm what you are saying?
>
> 1) at park = true ,and when Parked at Park positions 1-5.  must unpark, start tracking before slewing can
> occur?
> 2) at park= true can occur if pointing at a star and tracking is turned off ?
> 3) at park= true and not at park positions 1-5, must unpark, and start tracking before slewing?
> 4) while slewing or tracking....at park=false
>
>
> Is this correct?
> thanks for your time
> dave
> On Wednesday, November 3, 2021, 10:48:31 PM PDT, Ray Gralak <iogroups@...> wrote:
>
>
> 335594 2021-11-03 01:59:07.145:            ASCOM: Info      : GET AtPark = True
> 335595 2021-11-03 01:59:07.180:            ASCOM: Info      : GET SideOfPier = East
> 335596 2021-11-03 01:59:07.296:            ASCOM: Info      : GET Connected = True
> 335597 2021-11-03 01:59:07.387:          Driver: Info      : CommandString TX=':GR#'
> 335598 2021-11-03 01:59:07.403:          Driver: Info      : CommandString: APCC response:
> ':APCC,109370,GR#', Response='01:44:32.1#'
> 335599 2021-11-03 01:59:07.558:          Driver: Info      : CommandString TX=':GD#'
> 335600 2021-11-03 01:59:07.575:          Driver: Info      : CommandString: APCC response:
> ':APCC,109371,GD#', Response='+51*29:34#'
> 335601 2021-11-03 01:59:07.885:          Driver: Info      : CommandString TX=':GOS#'
> 335602 2021-11-03 01:59:07.902:          Driver: Info      : CommandString: APCC response:
> ':APCC,109372,GOS#', Response='P99000200P000#'
>
> And again here, the mount status says it is parked according to the response from the GOS command.
>
> -Ray
>
>
> > -----Original Message-----
> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
> > Sent: Wednesday, November 3, 2021 8:24 PM
> > To: main@ap-gto.groups.io
> > Subject: Re: [ap-gto] APCC/Driver exception
> >
> > Sorry Ray we are not communicating......Step by step....
> > i was imaging M76 when weather pause occurred....Mount was parked for about a hour (APCC confirms)
> > When weather cleared....CCDCommander told mount to unpark and go to M76.....which as I interpret from
> > APCC log that it did (and the fact that is where  the mount was pointed  in the morning).
> > Because time had passed,  M76 was not to be shot at this time, but should be imaging Sh2-234.
> > When CCD Commander tried to slew from M76 to SH2-234 that is where the exception occurred.
> >
> > according APCC/driver log.....after weather pause, mount took about 49 seconds to slew to M76 after it had
> > been parked in park position 4  for about than hour.
> >
> > possibilities
> > 1) mount never parked when weather caused imaging to stop and just stopped tracking.  however
> > APCC/driver said it did park
> > 2) after weather cleared and imaging started up  again, mount slewed to M76  ( i may be wrong but scope
> was
> > pointed where M76 was when exception occurred)
> >      a) after going to M76...somehow park was issued and then immediately issued slew to Sh2-234 was
> issued
> > causing the exception.
> >      b)??????????
> >
> >
> > hope that clears it up
> > dave
> >
> >
> >
> >
> > On Wednesday, November 3, 2021, 07:56:13 PM PDT, Ray Gralak <iogroups@...> wrote:
> >
> >
> > Dave,
> >
> > > so why after slewing to M76 was APCC/driver reporting "at park"?  is there a command that
> > > could cause it?
> >
> > Did you look at the log you posted? At the top of the log:
> >
> > CCDCommander
> > 23:32:42  Starting imager exposure (6 of 6).
> > 23:40:33  Very cloudy condition detected!  Pausing Action List.23:40:33  Very cloudy condition detected!
> > Pausing Action List.
> > 23:40:33  Parking mount...
> > 23:41:58  Done parking!
> >
> > -Ray
> >
> > > -----Original Message-----
> > > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via
> groups.io
> > > Sent: Wednesday, November 3, 2021 7:33 PM
> > > To: main@ap-gto.groups.io
> > > Subject: Re: [ap-gto] APCC/Driver exception
> > >
> > > Is it possible that after slewing to M76, a "park" was issued and before ASCOM/driver could respond or
> the
> > > mount move,  there was a slew issued?
> > > dave
> > >
> > > On Wednesday, November 3, 2021, 06:49:17 PM PDT, david w pearson <p.davidw@...> wrote:
> > >
> > >
> > > thanks,,,,but a question because i am still confused......according to APCC log.....the mount had slewed
> to
> > > M76 and "at park" was true...and when told to slew to Sh2-234 got the exception because it was thinking it
> > > was parked.    so why after slewing to M76 was APCC/driver reporting "at park"?  is there a command that
> > > could cause it?
> > > dave
> > >
> > > On Wednesday, November 3, 2021, 06:11:25 PM PDT, Bill Long <bill@...> wrote:
> > >
> > >
> > > The mount is parked and is being asked to slew. That is not a legal operation. Matt should unpark the
> mount
> > if
> > > it is parked and CCD Commander wants to slew the mount.
> > >
> > > 335589 2021-11-03 01:59:07.122:            ASCOM: Info      : GET Connected = True
> > > 335590 2021-11-03 01:59:07.123:            ASCOM: Info      : GET RightAscension = 1.74197222222222
> > > 335591 2021-11-03 01:59:07.123:            ASCOM: Info      : GET Declination = 51.4927777777778
> > > 335592 2021-11-03 01:59:07.123:            ASCOM: Info      : GET Tracking = False
> > > 335593 2021-11-03 01:59:07.124:            ASCOM: Info      : GET Slewing = False, MoveAxis(0)=0,
> > > MoveAxis(1)=0
> > > 335594 2021-11-03 01:59:07.145:            ASCOM: Info      : GET AtPark = True
> > > 335595 2021-11-03 01:59:07.180:            ASCOM: Info      : GET SideOfPier = East
> > > 335596 2021-11-03 01:59:07.296:            ASCOM: Info      : GET Connected = True
> > > 335597 2021-11-03 01:59:07.387:          Driver: Info      : CommandString TX=':GR#'
> > > 335598 2021-11-03 01:59:07.403:          Driver: Info      : CommandString: APCC response:
> > > ':APCC,109370,GR#', Response='01:44:32.1#'
> > > 335599 2021-11-03 01:59:07.558:          Driver: Info      : CommandString TX=':GD#'
> > > 335600 2021-11-03 01:59:07.575:          Driver: Info      : CommandString: APCC response:
> > > ':APCC,109371,GD#', Response='+51*29:34#'
> > > 335601 2021-11-03 01:59:07.885:          Driver: Info      : CommandString TX=':GOS#'
> > > 335602 2021-11-03 01:59:07.902:          Driver: Info      : CommandString: APCC response:
> > > ':APCC,109372,GOS#', Response='P99000200P000#'
> > > 335603 2021-11-03 01:59:07.904:          Driver: Info      : CommandString TX=':GS#'
> > > 335604 2021-11-03 01:59:07.918:          Driver: Info      : CommandString: APCC response:
> > > ':APCC,109373,GS#', Response='03:47:42.8#'
> > > 335605 2021-11-03 01:59:07.971:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335606 2021-11-03 01:59:07.972:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335607 2021-11-03 01:59:07.972:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335608 2021-11-03 01:59:07.972:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335609 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335610 2021-11-03 01:59:07.973:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335611 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335612 2021-11-03 01:59:07.973:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335613 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335614 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > > 335615 2021-11-03 01:59:07.974:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335616 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Declination = 51.4927777777778
> > > 335617 2021-11-03 01:59:07.974:            ASCOM: Info      : GET RightAscension = 1.74225
> > > 335618 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Declination = 51.4927777777778
> > > 335619 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Slewing = False, MoveAxis(0)=0,
> > > MoveAxis(1)=0
> > > 335620 2021-11-03 01:59:08.055:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > > 335621 2021-11-03 01:59:08.055:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > > 335622 2021-11-03 01:59:08.056:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > > 335623 2021-11-03 01:59:08.056:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > > 335624 2021-11-03 01:59:08.062:            ASCOM: Info      : SlewToCoordinatesAsync()
> > RA=5.49582868725247,
> > > Dec=34.4413830565668
> > > 335625 2021-11-03 01:59:08.062:  check_connected: Exception : bMustNotBeParked and g_bParked:
> True,
> > > True : SlewToCoordinatesAsync
> > >
> > >
> > >
> > >
> > > ________________________________
> > >
> > > From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of david w pearson via groups.io
> > > <p.davidw=yahoo.com@groups.io>
> > > Sent: Wednesday, November 3, 2021 4:51 PM
> > > To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> > > Subject: [ap-gto] APCC/Driver exception
> > >
> > > Hi Ray,
> > >
> > > I am getting this error from ASCOM/driver
> > >
> > > "check_connected: Exception : bMustNotBeParked and g_bParked: True, True : SlewToCoordinatesAsyn"
> > >
> > > Do you have any insight on this exception and what may cause it?
> > >
> > > Background.
> > > I use CCDCommander for my auto imaging script.
> > > After parking the mount due to bad weather/Roof Closure, and being in a weather pause for maybe hours,
> i
> > > get this error after coming out of a weather pause and restarting my imaging session.
> > >
> > > CCDCommander log
> > > 01:59:08  JNow Coordinates: RA: 05h 29m 45.0s Dec: +34°26'29"
> > > 01:59:08  Slewing to Sh2-234...
> > > 01:59:08  Error Number: -2147220471
> > > 01:59:08  Illegal operation while parked
> > >
> > > I have enclosed a summary txt file of CCDCommander and APCC(to shorter the search)
> > >
> > > In summary....CCDCommander goes into weather pause, and tells APCC/driver to park and it does.
> > > After the weather pause, CCDCommander tells APCC/driver to go to last image and it appears to do
> > > that.....however, "at park" stays true.
> > >
> > > question here.....when "at park" is true, does this just mean not slewing or tracking?  Slewing and tracking
> > > stays false.
> > >
> > > CCDCommander discovers that the last object is not the planned  object due to the weather delay, and
> tells
> > > APCC/driver to slew to correct object, and the Exception occurs.
> > >
> > > Mount is parked at alt/az of the last object when exception occurred and of course is still there upon
> > > observing the mount next morning.
> > >
> > > I realize my issue is an interface issue between the mount and CCDCommander, but maybe if there some
> > > possible issues
> > > that make this happen i can work around it or get Matt at CCDCommander to fix.
> > >
> > > This has been a CCDCommander issue since i started in 2010 and has been noted by others over the
> years.
> > > I have talked to Matt about it and he has given me workarounds to try, but none have worked.
> > >
> > > So i decided to try to figure it out myself, and pass info over to Matt.
> > >
> > > Any ideas what is causing  the APCC exception?
> > >
> > > I know this is not really your issue.....but a lot of us have been struggling with this for some time......you
> are
> > > probably our last hope.(pun intended!)
> > > Thanks... if you choose to accept this challenge!!  Hopefully easy for you!
> > >
> > > dave
> > >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
>
>
>
>







Re: APCC/Driver exception

Ray Gralak
 

Hi David,

The logic can be summarized as follows:

In ASCOM, to perform an RA/Dec slew, the mount must be unparked and tracking.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
Sent: Thursday, November 4, 2021 9:44 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC/Driver exception

Let me confirm what you are saying?

1) at park = true ,and when Parked at Park positions 1-5. must unpark, start tracking before slewing can
occur?
2) at park= true can occur if pointing at a star and tracking is turned off ?
3) at park= true and not at park positions 1-5, must unpark, and start tracking before slewing?
4) while slewing or tracking....at park=false


Is this correct?
thanks for your time
dave
On Wednesday, November 3, 2021, 10:48:31 PM PDT, Ray Gralak <iogroups@...> wrote:


335594 2021-11-03 01:59:07.145: ASCOM: Info : GET AtPark = True
335595 2021-11-03 01:59:07.180: ASCOM: Info : GET SideOfPier = East
335596 2021-11-03 01:59:07.296: ASCOM: Info : GET Connected = True
335597 2021-11-03 01:59:07.387: Driver: Info : CommandString TX=':GR#'
335598 2021-11-03 01:59:07.403: Driver: Info : CommandString: APCC response:
':APCC,109370,GR#', Response='01:44:32.1#'
335599 2021-11-03 01:59:07.558: Driver: Info : CommandString TX=':GD#'
335600 2021-11-03 01:59:07.575: Driver: Info : CommandString: APCC response:
':APCC,109371,GD#', Response='+51*29:34#'
335601 2021-11-03 01:59:07.885: Driver: Info : CommandString TX=':GOS#'
335602 2021-11-03 01:59:07.902: Driver: Info : CommandString: APCC response:
':APCC,109372,GOS#', Response='P99000200P000#'

And again here, the mount status says it is parked according to the response from the GOS command.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
Sent: Wednesday, November 3, 2021 8:24 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC/Driver exception

Sorry Ray we are not communicating......Step by step....
i was imaging M76 when weather pause occurred....Mount was parked for about a hour (APCC confirms)
When weather cleared....CCDCommander told mount to unpark and go to M76.....which as I interpret from
APCC log that it did (and the fact that is where the mount was pointed in the morning).
Because time had passed, M76 was not to be shot at this time, but should be imaging Sh2-234.
When CCD Commander tried to slew from M76 to SH2-234 that is where the exception occurred.

according APCC/driver log.....after weather pause, mount took about 49 seconds to slew to M76 after it had
been parked in park position 4 for about than hour.

possibilities
1) mount never parked when weather caused imaging to stop and just stopped tracking. however
APCC/driver said it did park
2) after weather cleared and imaging started up again, mount slewed to M76 ( i may be wrong but scope
was
pointed where M76 was when exception occurred)
a) after going to M76...somehow park was issued and then immediately issued slew to Sh2-234 was
issued
causing the exception.
b)??????????


hope that clears it up
dave




On Wednesday, November 3, 2021, 07:56:13 PM PDT, Ray Gralak <iogroups@...> wrote:


Dave,

so why after slewing to M76 was APCC/driver reporting "at park"? is there a command that
could cause it?
Did you look at the log you posted? At the top of the log:

CCDCommander
23:32:42 Starting imager exposure (6 of 6).
23:40:33 Very cloudy condition detected! Pausing Action List.23:40:33 Very cloudy condition detected!
Pausing Action List.
23:40:33 Parking mount...
23:41:58 Done parking!

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via
groups.io
Sent: Wednesday, November 3, 2021 7:33 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC/Driver exception

Is it possible that after slewing to M76, a "park" was issued and before ASCOM/driver could respond or
the
mount move, there was a slew issued?
dave

On Wednesday, November 3, 2021, 06:49:17 PM PDT, david w pearson <p.davidw@...> wrote:


thanks,,,,but a question because i am still confused......according to APCC log.....the mount had slewed
to
M76 and "at park" was true...and when told to slew to Sh2-234 got the exception because it was thinking it
was parked. so why after slewing to M76 was APCC/driver reporting "at park"? is there a command that
could cause it?
dave

On Wednesday, November 3, 2021, 06:11:25 PM PDT, Bill Long <bill@...> wrote:


The mount is parked and is being asked to slew. That is not a legal operation. Matt should unpark the
mount
if
it is parked and CCD Commander wants to slew the mount.

335589 2021-11-03 01:59:07.122: ASCOM: Info : GET Connected = True
335590 2021-11-03 01:59:07.123: ASCOM: Info : GET RightAscension = 1.74197222222222
335591 2021-11-03 01:59:07.123: ASCOM: Info : GET Declination = 51.4927777777778
335592 2021-11-03 01:59:07.123: ASCOM: Info : GET Tracking = False
335593 2021-11-03 01:59:07.124: ASCOM: Info : GET Slewing = False, MoveAxis(0)=0,
MoveAxis(1)=0
335594 2021-11-03 01:59:07.145: ASCOM: Info : GET AtPark = True
335595 2021-11-03 01:59:07.180: ASCOM: Info : GET SideOfPier = East
335596 2021-11-03 01:59:07.296: ASCOM: Info : GET Connected = True
335597 2021-11-03 01:59:07.387: Driver: Info : CommandString TX=':GR#'
335598 2021-11-03 01:59:07.403: Driver: Info : CommandString: APCC response:
':APCC,109370,GR#', Response='01:44:32.1#'
335599 2021-11-03 01:59:07.558: Driver: Info : CommandString TX=':GD#'
335600 2021-11-03 01:59:07.575: Driver: Info : CommandString: APCC response:
':APCC,109371,GD#', Response='+51*29:34#'
335601 2021-11-03 01:59:07.885: Driver: Info : CommandString TX=':GOS#'
335602 2021-11-03 01:59:07.902: Driver: Info : CommandString: APCC response:
':APCC,109372,GOS#', Response='P99000200P000#'
335603 2021-11-03 01:59:07.904: Driver: Info : CommandString TX=':GS#'
335604 2021-11-03 01:59:07.918: Driver: Info : CommandString: APCC response:
':APCC,109373,GS#', Response='03:47:42.8#'
335605 2021-11-03 01:59:07.971: ASCOM: Info : GET RightAscension = 1.74225
335606 2021-11-03 01:59:07.972: ASCOM: Info : GET SiderealTime = 3.79523972222222
335607 2021-11-03 01:59:07.972: ASCOM: Info : GET RightAscension = 1.74225
335608 2021-11-03 01:59:07.972: ASCOM: Info : GET SiderealTime = 3.79523972222222
335609 2021-11-03 01:59:07.973: ASCOM: Info : GET SiderealTime = 3.79523972222222
335610 2021-11-03 01:59:07.973: ASCOM: Info : GET RightAscension = 1.74225
335611 2021-11-03 01:59:07.973: ASCOM: Info : GET SiderealTime = 3.79523972222222
335612 2021-11-03 01:59:07.973: ASCOM: Info : GET RightAscension = 1.74225
335613 2021-11-03 01:59:07.973: ASCOM: Info : GET SiderealTime = 3.79523972222222
335614 2021-11-03 01:59:07.973: ASCOM: Info : GET SiderealTime = 3.79523972222222
335615 2021-11-03 01:59:07.974: ASCOM: Info : GET RightAscension = 1.74225
335616 2021-11-03 01:59:07.974: ASCOM: Info : GET Declination = 51.4927777777778
335617 2021-11-03 01:59:07.974: ASCOM: Info : GET RightAscension = 1.74225
335618 2021-11-03 01:59:07.974: ASCOM: Info : GET Declination = 51.4927777777778
335619 2021-11-03 01:59:07.974: ASCOM: Info : GET Slewing = False, MoveAxis(0)=0,
MoveAxis(1)=0
335620 2021-11-03 01:59:08.055: ASCOM: Info : GET SiderealTime = 3.79526138888889
335621 2021-11-03 01:59:08.055: ASCOM: Info : GET SiderealTime = 3.79526138888889
335622 2021-11-03 01:59:08.056: ASCOM: Info : GET SiderealTime = 3.79526138888889
335623 2021-11-03 01:59:08.056: ASCOM: Info : GET SiderealTime = 3.79526138888889
335624 2021-11-03 01:59:08.062: ASCOM: Info : SlewToCoordinatesAsync()
RA=5.49582868725247,
Dec=34.4413830565668
335625 2021-11-03 01:59:08.062: check_connected: Exception : bMustNotBeParked and g_bParked:
True,
True : SlewToCoordinatesAsync




________________________________

From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of david w pearson via groups.io
<p.davidw@...>
Sent: Wednesday, November 3, 2021 4:51 PM
To: main@ap-gto.groups.io <main@ap-gto.groups.io>
Subject: [ap-gto] APCC/Driver exception

Hi Ray,

I am getting this error from ASCOM/driver

"check_connected: Exception : bMustNotBeParked and g_bParked: True, True : SlewToCoordinatesAsyn"

Do you have any insight on this exception and what may cause it?

Background.
I use CCDCommander for my auto imaging script.
After parking the mount due to bad weather/Roof Closure, and being in a weather pause for maybe hours,
i
get this error after coming out of a weather pause and restarting my imaging session.

CCDCommander log
01:59:08 JNow Coordinates: RA: 05h 29m 45.0s Dec: +34°26'29"
01:59:08 Slewing to Sh2-234...
01:59:08 Error Number: -2147220471
01:59:08 Illegal operation while parked

I have enclosed a summary txt file of CCDCommander and APCC(to shorter the search)

In summary....CCDCommander goes into weather pause, and tells APCC/driver to park and it does.
After the weather pause, CCDCommander tells APCC/driver to go to last image and it appears to do
that.....however, "at park" stays true.

question here.....when "at park" is true, does this just mean not slewing or tracking? Slewing and tracking
stays false.

CCDCommander discovers that the last object is not the planned object due to the weather delay, and
tells
APCC/driver to slew to correct object, and the Exception occurs.

Mount is parked at alt/az of the last object when exception occurred and of course is still there upon
observing the mount next morning.

I realize my issue is an interface issue between the mount and CCDCommander, but maybe if there some
possible issues
that make this happen i can work around it or get Matt at CCDCommander to fix.

This has been a CCDCommander issue since i started in 2010 and has been noted by others over the
years.
I have talked to Matt about it and he has given me workarounds to try, but none have worked.

So i decided to try to figure it out myself, and pass info over to Matt.

Any ideas what is causing the APCC exception?

I know this is not really your issue.....but a lot of us have been struggling with this for some time......you
are
probably our last hope.(pun intended!)
Thanks... if you choose to accept this challenge!! Hopefully easy for you!

dave













Re: APCC/APPM requirements for the Astro-Physics mounts.

Ray Gralak
 

Hi Arvind,

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence
of internet connected devices and especially in our hobby how we're most often already using an internet
connected computer, applying a firmware patch periodically (can even automate this with customer consent)
might solve the problem. In fact, the more often this is done the less wrinkles such a process would have --
and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking
could be then done using any protocol compliant software (say, NINA to send GoTo commands, align
commands, sync commands etc) because the mount itself would know how to handle those situations
internally without requiring a desktop program. But this is just wishful thinking on my side :-)
There's another side to this. One problem with the modeling being built in the controller approach is that it is then limited to the hardware of the mount's control box. To improve performance or memory would likely mean buying a new, relatively expensive control box. And that still won't have near the performance and memory/storage of even a modest modern laptop. For example, another manufacturer's mounts have a limited number of mapping points, while there is no limit in APCC. Also, testing, debugging, and improving modeling algorithms is much easier on a desktop, which allows more frequent advances and without requiring a hardware update.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Arvind
Sent: Thursday, November 4, 2021 9:22 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC/APPM requirements for the Astro-Physics mounts.

Thank you for the clarification, Mike. It's good to know first hand about these improvements and how they
come together!

Linwood, appreciate your new-customer perspective as well; lots of interesting points & experiences have
been shared in your response, so I thank you for taking the time to be thorough.

Overall it's good to know that I am better off using the APCC Pro than not, especially if I'm going to be
buying an encoder version of A-P mounts to be able to fully utilize its capabilities. I'll be using another mount
for my smaller / portable scopes so I'm exploring options for my toa-150b which will most likely be semi-
permanently mounted and maybe travel with me on rare occasions - likely 1100AE or the 1600AE. I will
continue to track the updates around NINA-APCC integration as well -- NINA is what I am currently using for
image acquisition. I hope the 32-bit issues are addressed on the APMM side though (wouldn't have known if
you have not called this one out, so I will try to learn more!). But good to know these are not deadends and
there are known workarounds.

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence
of internet connected devices and especially in our hobby how we're most often already using an internet
connected computer, applying a firmware patch periodically (can even automate this with customer consent)
might solve the problem. In fact, the more often this is done the less wrinkles such a process would have --
and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking
could be then done using any protocol compliant software (say, NINA to send GoTo commands, align
commands, sync commands etc) because the mount itself would know how to handle those situations
internally without requiring a desktop program. But this is just wishful thinking on my side :-)

Thanks, and best regards,
Arvind

On Thu, Nov 4, 2021 at 12:17 PM Mike Hanson <mikeh@...> wrote:


Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being
shipped with the Mach 2. We are working to make this available for the CP4/keypad combo. Here's some
recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs
corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact
with your camera and other software in ways that the keypad cannot. For example, APPM can initiate image
captures and plate solves, which enables automation in the mapping process. This also enables model data
to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.
Either APPM/APCC or the Keypad model can run passively in the background while using other third-party
software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning
curve. It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson








Re: APCC Pro Error FindFreeQacindex: no free entries!

Ray Gralak
 

Thanks. I have an even more minor complaint and am in need of advice. Very often, the Emergency Stop
window persists after slewing is complete, and when it would normally disappear. It just happened to me
tonight. Is there any possible problem with just closing it using the "X" box?
David, sure you can close the window like that.

-Ray


Re: APCC/APPM requirements for the Astro-Physics mounts.

Arvind
 

Thank you for the clarification, Mike. It's good to know first hand about these improvements and how they come together!

Linwood, appreciate your new-customer perspective as well; lots of interesting points & experiences have been shared in your response, so I thank you for taking the time to be thorough. 

Overall it's good to know that I am better off using the APCC Pro than not, especially if I'm going to be buying an encoder version of A-P mounts to be able to fully utilize its capabilities. I'll be using another mount for my smaller / portable scopes so I'm exploring options for my toa-150b which will most likely be semi-permanently mounted and maybe travel with me on rare occasions - likely 1100AE or the 1600AE. I will continue to track the updates around NINA-APCC integration as well -- NINA is what I am currently using for image acquisition. I hope the 32-bit issues are addressed on the APMM side though (wouldn't have known if you have not called this one out, so I will try to learn more!). But good to know these are not deadends and there are known workarounds.

Agreed on the challenges with firmware vs desktop based software delivery but I believe given the prevalence of internet connected devices and especially in our hobby how we're most often already using an internet connected computer, applying a firmware patch periodically (can even automate this with customer consent) might solve the problem. In fact, the more often this is done the less wrinkles such a process would have -- and the firmware process itself could just be limited to Windows. Actually using the model-building & tracking could be then done using any protocol compliant software (say, NINA to send GoTo commands, align commands, sync commands etc) because the mount itself would know how to handle those situations internally without requiring a desktop program. But this is just wishful thinking on my side :-)

Thanks, and best regards,
Arvind

On Thu, Nov 4, 2021 at 12:17 PM Mike Hanson <mikeh@...> wrote:
Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being shipped with the Mach 2.  We are working to make this available for the CP4/keypad combo.  Here's some recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact with your camera and other software in ways that the keypad cannot.  For example, APPM can initiate image captures and plate solves, which enables automation in the mapping process.  This also enables model data to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.  Either APPM/APCC or the Keypad model can run passively in the background while using other third-party software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning curve.  It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson


Re: APCC Pro Error FindFreeQacindex: no free entries!

David Johnson
 

Thanks.  I have an even more minor complaint and am in need of advice.  Very often, the Emergency Stop window persists after slewing is complete, and when it would normally disappear.   It just happened to me tonight.   Is there any possible problem with just closing it using the "X" box?


Re: Oh my god..it doesn't get better than this.

Nick Iversen
 

I've seen a lot of charts like that one that are misleading due to either (1) wrong y axis scale chosen or (2) wrong focal length entered for the guide scope. The critical number is the RMS which in your case appears to be 0.29 which is quite good (as long as you have entered the correct focal length).


Re: APCC/APPM requirements for the Astro-Physics mounts.

Mike Hanson
 

Hi Arvind,

There is, in fact, simple modeling provisions in the V5 Keypad and CP5 combo, presently being shipped with the Mach 2.  We are working to make this available for the CP4/keypad combo.  Here's some recent dialog:
https://ap-gto.groups.io/g/main/search?p=%2C%2C%2C20%2C0%2C0%2C0&q=keypad+model
The keypad provides a simple user interface, while the mount retains the database and performs corrections based on it.

To address your last question, realize that APPM/APCC runs on the host computer, and can interact with your camera and other software in ways that the keypad cannot.  For example, APPM can initiate image captures and plate solves, which enables automation in the mapping process.  This also enables model data to adhere strictly to constant-DEC lines, which offers performance advantages in some usage domains.  Either APPM/APCC or the Keypad model can run passively in the background while using other third-party software.

The keypad model, in contrast, is intended to be ASAP (as simple as possible), with a small learning curve.  It can be used with, but doesn't require, other computer software.

Regards,
Mike Hanson


Re: Keypad 4.19.5 unsuccessful upload

Peter Nagy
 

To conclude this thread, there was never an issue in the first place. I don't know why both of my computers failed to upload 4.19.5 version into my Keypad the first day and suddenly the next day, it uploaded successfully at least three times using both of my computers. Case closed.

Thanks to Howard for his patience for helping me.

Peter


Re: APCC/APPM requirements for the Astro-Physics mounts.

ap@CaptivePhotons.com
 

I'd like to offer a new-customer perspective on this.  I came from a MyT and The Sky X and so had some concerns about a software based system as opposed to hardware/firmware, and what limitations this may impose.   I was not a fan of TXS generally, so was then not a fan of the … I'm not sure restrictions are so much the right word as perhaps hurdles you had to overcome when you wanted to use other software.  This despite it having been around forever and had a ton of interfaces/techniques documented.

 

I found the AP system a different world even if a lot of similarities.


It required APCC and APPM to build and use a model (and so far as I know that's the only way) just like TSX and tPoint.  And like TSX it has a ton of options and settings (though I will also say that the defaults are a lot more sensible and need less changing to just get started).  And like TXS (at the time) it is 32 bit only.  However…

 

It does not get in the way. 


It is possible to use the mount without APCC (through the ASCOM driver) though without the model, but with encoder benefit.  But I think rather pointless.

 

The use of APCC is transparent to other applications; it's just plain ASCOM.  While you can tweak things in APCC (e.g. limits), the application does not really 'see' that the mount is anything special.  I just converted to NINA and all was (almost) well.  The almost was frankly that I forgot to undo some special settings left over from TSX.

 

Now secondarily to that, NINA in particular has been customized so it can interact directly with APPM. You can actually use NINA to build your model; it does the work of invoking APPM, building and loading the model, you never need touch it.  I personally prefer to do it directly, but it's all in there.   An advantage of doing it from NINA is it can be pre-programmed to go off at a certain time, for hands-free model building.

 

I am to the point now that I only touch APCC once most nights -- at the end, I park from there instead of NINA, as I keep NINA and APCC's park defaults to different locations.

 

The only downside I've seen so far (again, as a new user) is the 32 bit limitations.  When using APPM itself (vs NINA or TSX) to control the camera, its memory limitations come into play.  However, these vanish if you tell APPM to use NINA or TSX (or probably others).  So it is really moot; people with large full frame cameras are better off just starting there, not trying to let APPM use the camera itself.  [Insert Ray's protest here, that the issue is really ZWO's and probably others lousy ASCOM driver memory utilizations, but from a user perspective it does not matter who is at fault -- just use the 64 bit application for camera and it is all moot].

 

My GUESS is also that doing these things in software vs firmware provide for a faster development cycle, and more flexibility since PC programs can grow faster on disk and computer memory than inside firmware.  In just the 3 months or so since I got my mount quite a few new features were added.

 

Short version: As someone coming from a "software" mount, the integration and interactions of APCC and APPM do not get in the way.  I think that's because Bisque was a software company that also builds hardware, but (my view) AP is a hardware company that also does software (well, Sirius Imaging does).

 

As to what's planned… I of course have no idea.

 

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Arvind via groups.io
Sent: Thursday, November 4, 2021 12:11 PM
To: main@ap-gto.groups.io
Subject: [ap-gto] APCC/APPM requirements for the Astro-Physics mounts.

 

Hi, A-P team:

 

I am asking this for a future purchase, and hopefully for the benefit of others who might have a similar question.

 

So far I have been under the impression that to be able to build a pointing model and use it with any of the Astro Physics mounts, I had to use the APPM to build a model, and APCC to use that model with the mount to improve pointing & tracking accuracy; especially for unguided imaging to factor in real-world sources of errors even with near-perfect polar-alignment. Of course, one can choose NOT to do all this and just do autoguiding to provide the necessary feedback and still get wonderful results with A-P mounts.

 

Is my understanding correct on the need for APPM/APCC to fully benefit from encoders & unguided imaging with the A-P mounts? If so, is there a plan to move the model building & usage to the mount computer itself eventually to allow customers to use any software, or even a hand-controller, to coordinate model building & usage? Perhaps a firmware update to CP4/CP5. Is there any other performance-related functionality that is only provided as part of APCC/APPM software?

 

Thanks & best regards,

Arvind

 

 


Re: APCC/Driver exception

david w pearson
 

Let me confirm what you are saying?

1) at park = true ,and when Parked at Park positions 1-5.   must unpark, start tracking before slewing can occur?
2) at park= true can occur if pointing at a star and tracking is turned off ?
3) at park= true and not at park positions 1-5, must unpark, and start tracking before slewing?
4) while slewing or tracking....at park=false

Is this correct?
thanks for your time
dave

On Wednesday, November 3, 2021, 10:48:31 PM PDT, Ray Gralak <iogroups@...> wrote:


335594 2021-11-03 01:59:07.145:            ASCOM: Info      : GET AtPark = True
335595 2021-11-03 01:59:07.180:            ASCOM: Info      : GET SideOfPier = East
335596 2021-11-03 01:59:07.296:            ASCOM: Info      : GET Connected = True
335597 2021-11-03 01:59:07.387:          Driver: Info      : CommandString TX=':GR#'
335598 2021-11-03 01:59:07.403:          Driver: Info      : CommandString: APCC response: ':APCC,109370,GR#', Response='01:44:32.1#'
335599 2021-11-03 01:59:07.558:          Driver: Info      : CommandString TX=':GD#'
335600 2021-11-03 01:59:07.575:          Driver: Info      : CommandString: APCC response: ':APCC,109371,GD#', Response='+51*29:34#'
335601 2021-11-03 01:59:07.885:          Driver: Info      : CommandString TX=':GOS#'
335602 2021-11-03 01:59:07.902:          Driver: Info      : CommandString: APCC response: ':APCC,109372,GOS#', Response='P99000200P000#'

And again here, the mount status says it is parked according to the response from the GOS command.

-Ray


> -----Original Message-----
> From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
> Sent: Wednesday, November 3, 2021 8:24 PM
> To: main@ap-gto.groups.io
> Subject: Re: [ap-gto] APCC/Driver exception
>
> Sorry Ray we are not communicating......Step by step....
> i was imaging M76 when weather pause occurred....Mount was parked for about a hour (APCC confirms)
> When weather cleared....CCDCommander told mount to unpark and go to M76.....which as I interpret from
> APCC log that it did (and the fact that is where  the mount was pointed  in the morning).
> Because time had passed,  M76 was not to be shot at this time, but should be imaging Sh2-234.
> When CCD Commander tried to slew from M76 to SH2-234 that is where the exception occurred.
>
> according APCC/driver log.....after weather pause, mount took about 49 seconds to slew to M76 after it had
> been parked in park position 4  for about than hour.
>
> possibilities
> 1) mount never parked when weather caused imaging to stop and just stopped tracking.  however
> APCC/driver said it did park
> 2) after weather cleared and imaging started up  again, mount slewed to M76  ( i may be wrong but scope was
> pointed where M76 was when exception occurred)
>      a) after going to M76...somehow park was issued and then immediately issued slew to Sh2-234 was issued
> causing the exception.
>      b)??????????
>
>
> hope that clears it up
> dave
>
>
>
>
> On Wednesday, November 3, 2021, 07:56:13 PM PDT, Ray Gralak <iogroups@...> wrote:
>
>
> Dave,
>
> > so why after slewing to M76 was APCC/driver reporting "at park"?  is there a command that
> > could cause it?
>
> Did you look at the log you posted? At the top of the log:
>
> CCDCommander
> 23:32:42  Starting imager exposure (6 of 6).
> 23:40:33  Very cloudy condition detected!  Pausing Action List.23:40:33  Very cloudy condition detected!
> Pausing Action List.
> 23:40:33  Parking mount...
> 23:41:58  Done parking!
>
> -Ray
>
> > -----Original Message-----
> > From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of david w pearson via groups.io
> > Sent: Wednesday, November 3, 2021 7:33 PM
> > To: main@ap-gto.groups.io
> > Subject: Re: [ap-gto] APCC/Driver exception
> >
> > Is it possible that after slewing to M76, a "park" was issued and before ASCOM/driver could respond or the
> > mount move,  there was a slew issued?
> > dave
> >
> > On Wednesday, November 3, 2021, 06:49:17 PM PDT, david w pearson <p.davidw@...> wrote:
> >
> >
> > thanks,,,,but a question because i am still confused......according to APCC log.....the mount had slewed to
> > M76 and "at park" was true...and when told to slew to Sh2-234 got the exception because it was thinking it
> > was parked.    so why after slewing to M76 was APCC/driver reporting "at park"?  is there a command that
> > could cause it?
> > dave
> >
> > On Wednesday, November 3, 2021, 06:11:25 PM PDT, Bill Long <bill@...> wrote:
> >
> >
> > The mount is parked and is being asked to slew. That is not a legal operation. Matt should unpark the mount
> if
> > it is parked and CCD Commander wants to slew the mount.
> >
> > 335589 2021-11-03 01:59:07.122:            ASCOM: Info      : GET Connected = True
> > 335590 2021-11-03 01:59:07.123:            ASCOM: Info      : GET RightAscension = 1.74197222222222
> > 335591 2021-11-03 01:59:07.123:            ASCOM: Info      : GET Declination = 51.4927777777778
> > 335592 2021-11-03 01:59:07.123:            ASCOM: Info      : GET Tracking = False
> > 335593 2021-11-03 01:59:07.124:            ASCOM: Info      : GET Slewing = False, MoveAxis(0)=0,
> > MoveAxis(1)=0
> > 335594 2021-11-03 01:59:07.145:            ASCOM: Info      : GET AtPark = True
> > 335595 2021-11-03 01:59:07.180:            ASCOM: Info      : GET SideOfPier = East
> > 335596 2021-11-03 01:59:07.296:            ASCOM: Info      : GET Connected = True
> > 335597 2021-11-03 01:59:07.387:          Driver: Info      : CommandString TX=':GR#'
> > 335598 2021-11-03 01:59:07.403:          Driver: Info      : CommandString: APCC response:
> > ':APCC,109370,GR#', Response='01:44:32.1#'
> > 335599 2021-11-03 01:59:07.558:          Driver: Info      : CommandString TX=':GD#'
> > 335600 2021-11-03 01:59:07.575:          Driver: Info      : CommandString: APCC response:
> > ':APCC,109371,GD#', Response='+51*29:34#'
> > 335601 2021-11-03 01:59:07.885:          Driver: Info      : CommandString TX=':GOS#'
> > 335602 2021-11-03 01:59:07.902:          Driver: Info      : CommandString: APCC response:
> > ':APCC,109372,GOS#', Response='P99000200P000#'
> > 335603 2021-11-03 01:59:07.904:          Driver: Info      : CommandString TX=':GS#'
> > 335604 2021-11-03 01:59:07.918:          Driver: Info      : CommandString: APCC response:
> > ':APCC,109373,GS#', Response='03:47:42.8#'
> > 335605 2021-11-03 01:59:07.971:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335606 2021-11-03 01:59:07.972:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335607 2021-11-03 01:59:07.972:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335608 2021-11-03 01:59:07.972:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335609 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335610 2021-11-03 01:59:07.973:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335611 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335612 2021-11-03 01:59:07.973:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335613 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335614 2021-11-03 01:59:07.973:            ASCOM: Info      : GET SiderealTime = 3.79523972222222
> > 335615 2021-11-03 01:59:07.974:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335616 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Declination = 51.4927777777778
> > 335617 2021-11-03 01:59:07.974:            ASCOM: Info      : GET RightAscension = 1.74225
> > 335618 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Declination = 51.4927777777778
> > 335619 2021-11-03 01:59:07.974:            ASCOM: Info      : GET Slewing = False, MoveAxis(0)=0,
> > MoveAxis(1)=0
> > 335620 2021-11-03 01:59:08.055:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > 335621 2021-11-03 01:59:08.055:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > 335622 2021-11-03 01:59:08.056:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > 335623 2021-11-03 01:59:08.056:            ASCOM: Info      : GET SiderealTime = 3.79526138888889
> > 335624 2021-11-03 01:59:08.062:            ASCOM: Info      : SlewToCoordinatesAsync()
> RA=5.49582868725247,
> > Dec=34.4413830565668
> > 335625 2021-11-03 01:59:08.062:  check_connected: Exception : bMustNotBeParked and g_bParked: True,
> > True : SlewToCoordinatesAsync
> >
> >
> >
> >
> > ________________________________
> >
> > From: main@ap-gto.groups.io <main@ap-gto.groups.io> on behalf of david w pearson via groups.io
> > <p.davidw=yahoo.com@groups.io>
> > Sent: Wednesday, November 3, 2021 4:51 PM
> > To: main@ap-gto.groups.io <main@ap-gto.groups.io>
> > Subject: [ap-gto] APCC/Driver exception
> >
> > Hi Ray,
> >
> > I am getting this error from ASCOM/driver
> >
> > "check_connected: Exception : bMustNotBeParked and g_bParked: True, True : SlewToCoordinatesAsyn"
> >
> > Do you have any insight on this exception and what may cause it?
> >
> > Background.
> > I use CCDCommander for my auto imaging script.
> > After parking the mount due to bad weather/Roof Closure, and being in a weather pause for maybe hours, i
> > get this error after coming out of a weather pause and restarting my imaging session.
> >
> > CCDCommander log
> > 01:59:08  JNow Coordinates: RA: 05h 29m 45.0s Dec: +34°26'29"
> > 01:59:08  Slewing to Sh2-234...
> > 01:59:08  Error Number: -2147220471
> > 01:59:08  Illegal operation while parked
> >
> > I have enclosed a summary txt file of CCDCommander and APCC(to shorter the search)
> >
> > In summary....CCDCommander goes into weather pause, and tells APCC/driver to park and it does.
> > After the weather pause, CCDCommander tells APCC/driver to go to last image and it appears to do
> > that.....however, "at park" stays true.
> >
> > question here.....when "at park" is true, does this just mean not slewing or tracking?  Slewing and tracking
> > stays false.
> >
> > CCDCommander discovers that the last object is not the planned  object due to the weather delay, and tells
> > APCC/driver to slew to correct object, and the Exception occurs.
> >
> > Mount is parked at alt/az of the last object when exception occurred and of course is still there upon
> > observing the mount next morning.
> >
> > I realize my issue is an interface issue between the mount and CCDCommander, but maybe if there some
> > possible issues
> > that make this happen i can work around it or get Matt at CCDCommander to fix.
> >
> > This has been a CCDCommander issue since i started in 2010 and has been noted by others over the years.
> > I have talked to Matt about it and he has given me workarounds to try, but none have worked.
> >
> > So i decided to try to figure it out myself, and pass info over to Matt.
> >
> > Any ideas what is causing  the APCC exception?
> >
> > I know this is not really your issue.....but a lot of us have been struggling with this for some time......you are
> > probably our last hope.(pun intended!)
> > Thanks... if you choose to accept this challenge!!  Hopefully easy for you!
> >
> > dave
> >
>
>
>
>
>
>
>
>







APCC/APPM requirements for the Astro-Physics mounts.

Arvind
 

Hi, A-P team:

I am asking this for a future purchase, and hopefully for the benefit of others who might have a similar question.

So far I have been under the impression that to be able to build a pointing model and use it with any of the Astro Physics mounts, I had to use the APPM to build a model, and APCC to use that model with the mount to improve pointing & tracking accuracy; especially for unguided imaging to factor in real-world sources of errors even with near-perfect polar-alignment. Of course, one can choose NOT to do all this and just do autoguiding to provide the necessary feedback and still get wonderful results with A-P mounts.

Is my understanding correct on the need for APPM/APCC to fully benefit from encoders & unguided imaging with the A-P mounts? If so, is there a plan to move the model building & usage to the mount computer itself eventually to allow customers to use any software, or even a hand-controller, to coordinate model building & usage? Perhaps a firmware update to CP4/CP5. Is there any other performance-related functionality that is only provided as part of APCC/APPM software?

Thanks & best regards,
Arvind



Re: APCC download - malware detection

Brent Boshart
 
Edited

I distribute software that I have written and this is a constant struggle with false positive virus detections.  I always run a Virus Total check and report any false positives to the Anti-Virus vendor. Some are responsive, others are not.

Brent


Re: Oh my god..it doesn't get better than this.

Eric Claeys
 

I am glad for you.  Do you have a screenshot using +/- 1" instead of 8" ?  At 8" it's hard to tell how well things really are.

Eric


Re: Oh my god..it doesn't get better than this.

Worsel
 

Tom

He did not...that's why A-P IS special!!

Bryan


I think Roland went out of his way to make sure my mount was super special.


Re: APCC download - malware detection

Erkaslan Aygen
 

Hi all,

Similar behavior with Kasperky…. 

Regards,
Ashen 

Le jeu. 4 nov. 2021 à 16:07, Worsel via groups.io <bryancashion=yahoo.com@groups.io> a écrit :
David

This may be similar to Norton's WSReputation.1 flag.  It means that the security software does not have enough usage info in its database on the tested software.  That's not a surprise for ANY astro software.  I use Norton and have bypassed the WSReputation.1 flag without issue.

Bryan


Re: APCC download - malware detection

M Hambrick
 

I seem to recall that I had to disable my anti-virus software (Webroot) the first time I downloaded APCC. After that first time it was no longer necessary.

Mike


Re: APCC download - malware detection

Worsel
 

David

This may be similar to Norton's WSReputation.1 flag.  It means that the security software does not have enough usage info in its database on the tested software.  That's not a surprise for ANY astro software.  I use Norton and have bypassed the WSReputation.1 flag without issue.

Bryan


Re: Oh my god..it doesn't get better than this.

Tom Blahovici
 

Using a regular pointing model. 100 points for half the sky.
Tom

6241 - 6260 of 88872