Date   

Cannot lower AP1100 102 arc min

Shailesh Trivedi
 

I have a new pier for my AP1100AE. I have adjusted the AZ position using PEMPRO for polar alignment. I am at latitude 38.6 degrees and according to the AP1100 user manual, I need to place the Altitude adjuster bar in slot 5 (37 -47degrees centered at 42 deg.)

PEMPRO is asking me to lower the mount 102 arcmin and, even after loosening the polar axis lock knobs, I am unable to lower the mount; now with an OTA and counterweights.

How do I lower the mount? Any pointers will help, thanks.

Shailesh 


Re: APCC move axis question

Dale Ghent
 

On Mon, Aug 30, 2021 at 11:21 AM, Ray Gralak wrote:

Hi Dale,

When MoveAxis is used you should see something like this in the ASCOM log:

000868 2021-08-29 21:05:41.779: ASCOM: Info : MoveAxis(0,-4) 000869 2021-08-29 21:05:41.789: ASCOM: Info : GET Tracking = True 000870 2021-08-29 21:05:41.789: Driver: Info : CommandBool TX=':RR958.37870#' 000871 2021-08-29 21:05:41.801: Driver: Info : CommandBool Reply Received (TX=':RR958.37870#'), RX='1'

Ah great. So I grepped my logs from July for this:

PS C:\ProgramData\Astro-Physics\ASCOM\Logs> Select-String -path "*_2021-07*.log" -pattern "moveaxis\(0,"

AP_ASCOM_2021-07-09_22-32-28.log:18284:018284 2021-07-09 22:38:23.814:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-09_22-32-28.log:18984:018984 2021-07-09 22:38:30.554:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:19417:019417 2021-07-09 22:38:38.012:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-09_22-32-28.log:20120:020120 2021-07-09 22:38:44.728:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:88873:088873 2021-07-09 22:57:24.753:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-09_22-32-28.log:89581:089581 2021-07-09 22:57:31.493:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:90014:090014 2021-07-09 22:57:37.713:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-09_22-32-28.log:90629:090629 2021-07-09 22:57:44.467:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:101828:101828 2021-07-09 23:02:12.883:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:105234:105234 2021-07-09 23:03:14.887:            ASCOM: Info      : MoveAxis(0,4)
AP_ASCOM_2021-07-09_22-32-28.log:105741:105741 2021-07-09 23:03:19.979:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-09_22-32-28.log:106469:106469 2021-07-09 23:03:31.292:            ASCOM: Info      : MoveAxis(0,4)
AP_ASCOM_2021-07-09_22-32-28.log:107013:107013 2021-07-09 23:03:36.366:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-14_21-45-08.log:16159:016159 2021-07-14 22:08:37.059:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-14_21-45-08.log:16774:016774 2021-07-14 22:08:43.800:            ASCOM: Info      : MoveAxis(0,0)
AP_ASCOM_2021-07-14_21-45-08.log:17296:017296 2021-07-14 22:08:51.184:            ASCOM: Info      : MoveAxis(0,3)
AP_ASCOM_2021-07-14_21-45-08.log:17908:017908 2021-07-14 22:08:57.946:            ASCOM: Info      : MoveAxis(0,0)

We can see the MoveAxis(0,x) calls being made, where the 0 means that RA axis and x is the movement rate being requested. For the curious, the mount starts moving at the requested rate until it is told to stop by issuing the MoveAxis() call again, but with a rate of 0. You can look at the timestamps to see how long the axis moved at the specified rate until told to stop with the following MoveAxis(0,0) call.

Taking those timestamps, we can open up the APCC log from the same session and look at what's happening there around the same time. Let's take the first MoveAxis() call mentioned at 2021-07-09 22:38:23.814 (times are local) and look up what APCC says happened then. I do know this was an example of this issue because I was testing the PA plugin that night and chatting with its author about it:

018281 2021-07-09 22:38:23.807:            ASCOM: Info      : GET Connected = True
018282 2021-07-09 22:38:23.808:            ASCOM: Info      : CanMoveAxis(axisPrimary) = True
018283 2021-07-09 22:38:23.808:            ASCOM: Info      : AxisRates(axisPrimary)
018284 2021-07-09 22:38:23.814:            ASCOM: Info      : MoveAxis(0,3)
018285 2021-07-09 22:38:23.831:            ASCOM: Info      : GET Tracking = True
018286 2021-07-09 22:38:23.831:           Driver: Info      : CommandBool TX=':RR-717.03402#'
018287 2021-07-09 22:38:23.842:           Driver: Info      : CommandBool Reply Received (TX=':RR-717.03402#'), RX='1'
018288 2021-07-09 22:38:23.872:           Driver: Info      : CommandString TX=':GD#'
018289 2021-07-09 22:38:23.888:           Driver: Info      : CommandString: APCC response: ':APCC,2250,GD#', Response='+87*50:46#'

We see the MoveAxis(0,3) call from 22:38:23.814 in the ASCOM driver log being received by APCC at the same time. The next 100ms show the downstream interaction which looks like what you gave as an example. So we can conclude that the ASCOM driver is registering the MoveAxis(...) call from the app, that it understands it, and it's passed to APCC which registers the receipt of it, and then seems to pass the related mount commands to the CP (CP3 w/ V2 in my case) to drive the mount as prescribed. I'm not sure if the CommandBool commands are what they should be since I'm not familiar with things at that level.


Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray:
I believe there is a known problem with some versions of SkyX (it's not a problem with the driver or APCC).
What is the exact version of SkyX that you are using?
32 bit 10.5.0 build 12978


Re: APCC move axis question

Ray Gralak
 

Linwood,

I believe there is a known problem with some versions of SkyX (it's not a problem with the driver or APCC).

What is the exact version of SkyX that you are using?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Monday, August 30, 2021 8:40 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

It's hard with cloudy nights to sit and do nothing so I thought I would try one last experiment. Big mistake,
though hopefully no damage done.

Warning: DO NOT try this with TSX.

I set up to have TSX connect via the ASCOM V2 driver, to see what it would do, and I'm vastly confused, but
it made a real mess.

First, the straightforward sequence, does nothing:

- Start APCC, connect, unpark (tracking = 0)
- Start TSX
- use the move command - nothing visible happens

After a bit of experimentation, I tried this:

- Start APCC, connect, unpark (tracking = 0)
- Start TSX
- In APCC set tracking = King (sidereal would be the same I think, it was just on King)
- use the move command

At this point the mount runs away. No slew indication shown, no emergency stop shown. I did a disconnect
from TSX, then from the mount - kept slewing. I finally ran into the room and unplugged the mount while it
was stuck saddle pressed into the DEC plate. I think I had the clutches loose enough nothing bad happened.
I hope. I think that's the order I did things to stop it, not 100% sure, but the net was I disconnected as much
as I could, there was no "stop" available, and I am absolutely sure it was still slewing while hitting the mount
until I powered it off.

So... I was wondering if I might report that TSX worked and we could see how, but TSX... bad. Do not do
that. It just sends the mount off into space where APCC doesn't seem aware of it.

Ray, if you are curious and want to look, the ascom and apcc logs are here:

https://drive.google.com/file/d/1qRbHdXwLP3dG3EStSiHlwnBJopgsLWh4/view?usp=sharing

So... no more TSX. Really bad idea. I can't imagine how bad this would be if you were remote with no power
off ability.

Linwood




Re: APCC move axis question

ap@CaptivePhotons.com
 

It's hard with cloudy nights to sit and do nothing so I thought I would try one last experiment. Big mistake, though hopefully no damage done.

Warning: DO NOT try this with TSX.

I set up to have TSX connect via the ASCOM V2 driver, to see what it would do, and I'm vastly confused, but it made a real mess.

First, the straightforward sequence, does nothing:

- Start APCC, connect, unpark (tracking = 0)
- Start TSX
- use the move command - nothing visible happens

After a bit of experimentation, I tried this:

- Start APCC, connect, unpark (tracking = 0)
- Start TSX
- In APCC set tracking = King (sidereal would be the same I think, it was just on King)
- use the move command

At this point the mount runs away. No slew indication shown, no emergency stop shown. I did a disconnect from TSX, then from the mount - kept slewing. I finally ran into the room and unplugged the mount while it was stuck saddle pressed into the DEC plate. I think I had the clutches loose enough nothing bad happened. I hope. I think that's the order I did things to stop it, not 100% sure, but the net was I disconnected as much as I could, there was no "stop" available, and I am absolutely sure it was still slewing while hitting the mount until I powered it off.

So... I was wondering if I might report that TSX worked and we could see how, but TSX... bad. Do not do that. It just sends the mount off into space where APCC doesn't seem aware of it.

Ray, if you are curious and want to look, the ascom and apcc logs are here:

https://drive.google.com/file/d/1qRbHdXwLP3dG3EStSiHlwnBJopgsLWh4/view?usp=sharing

So... no more TSX. Really bad idea. I can't imagine how bad this would be if you were remote with no power off ability.

Linwood


Re: APCC move axis question

Ray Gralak
 

Hi Dale,

When MoveAxis is used you should see something like this in the ASCOM log:

000868 2021-08-29 21:05:41.779: ASCOM: Info : MoveAxis(0,-4)
000869 2021-08-29 21:05:41.789: ASCOM: Info : GET Tracking = True
000870 2021-08-29 21:05:41.789: Driver: Info : CommandBool TX=':RR958.37870#'
000871 2021-08-29 21:05:41.801: Driver: Info : CommandBool Reply Received (TX=':RR958.37870#'), RX='1'

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Dale Ghent
Sent: Monday, August 30, 2021 7:43 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question


Catching up on my email and this thread -

I have also noticed this issue since I started using APCC Pro and models late last year, I just haven't had the
time or reason to run it to ground until now because punching the NSEW buttons in any app has been a rare
need for me and I couched it as something to look into later when I didn't have more pressing things to test or
attend to. The new polar alignment plugin in NINA uses the MoveAxis() methods as a part of what it does, so
this issue is getting wider visibility now.

I did notice the same behavior with SharpCap's manual controls using any of its pre-defined list of rates, so
my original suspicions that NINA was doing something wrong with MoveAxis() and rate selection were
dispelled with that (and I was suspecting that was the case at first, given the minefield that MoveAxis() and
aptly-named IRate interface can be in terms of the standards ambiguity that you've pointed out). I think Andy
also mentioned that he was also seeing this under SGPro, which brings the number of apps experiencing this
anomaly to at least 3. I PA with SharpCap Pro's PA tool then and for now, and I do the 90* movement that it
requires using the APJog utility which doesn't use MoveAxis(), at least when moving the scope in set
increments.

I did just look back through my AP ASCOM and APCC logs to a time in the past where I know I tried
exercising MoveAxis() commands via the polar alignment plugin, and this is the only mention of "MoveAxis" I
see in the logs (timestamp elided for brevity)

ASCOM: Info : GET Slewing = False, MoveAxis(0)=0, MoveAxis(1)=0

All instances of when MoveAxis() was exercised in the app look like the above. The head-scratcher is that
there's nothing that seems obvious in relation to moveaxis in the corresponding APCC log. I can zip the two
together and forward it to you if you'd like.

Between the hurricane remnants moving towards here and day job stuff, I doubt I will be able to uncover my
mount and look into this in detail anytime soon, at least during this week.

/dale

On Aug 30, 2021, at 08:42, Ray Gralak <iogroups@siriusimaging.com> wrote:

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected
through
USB.
Andy, I also tried using a serial port connection to the mount, which to APCC is the same as the virtual COM
port in a USB connection. Again, there was no unexpected behavior.

The only thing left is for you to use the APCC log zipper and zip your APCC and ASCOM logs from last
night. It is important to include both logs, so make sure that you use the APCC Log zipper and not the
ASCOM Log Zipper (they are two different utilities). If you could provide me with a download like to the zip
file, I'll take a look.

Also, what is the exact version number of NINA that you are using?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 10:41 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected
through
USB.







Re: #APCC - V1.9 Tracking Error #APCC

Roland Christen
 

Your tracking curve looks good. I assume that you had PE correction turned on.
As for the rest, I cannot comment since I don't know what you were trying to accomplish. It would have been instructive to see a tracking curve with PE turned on and the model turned on.

Rolando



-----Original Message-----
From: Rouz <rbidshahri@...>
To: main@ap-gto.groups.io
Sent: Sun, Aug 29, 2021 12:53 am
Subject: Re: [ap-gto] #APCC - V1.9 Tracking Error

Clear tonight.

1-Checked PEC file from mount, was ok
2-PHD guide assistant with main scope and PEM ON, near Dec 0 and Meridian, relatively flat (except for drift).
3-Dense model Declination -Graduated Ra density, 128 points, PEM ON
4-Model numbers look reasonable 

5-Slew to Bubble nebula at Dec 62 (within model) 300s subs 

PEM ON, refraction on, Dec arc tracking OFF = elongated stars
PEM ON, refraction off, Dec arc tracking OFF = elongated stars
PEM ON, refraction off, Dec arc tracking ON = elongated stars
PEM OFF, refraction on, Dec arc tracking on = elongated stars





--
Roland Christen
Astro-Physics


Re: APCC move axis question

Dale Ghent
 

Catching up on my email and this thread -

I have also noticed this issue since I started using APCC Pro and models late last year, I just haven't had the time or reason to run it to ground until now because punching the NSEW buttons in any app has been a rare need for me and I couched it as something to look into later when I didn't have more pressing things to test or attend to. The new polar alignment plugin in NINA uses the MoveAxis() methods as a part of what it does, so this issue is getting wider visibility now.

I did notice the same behavior with SharpCap's manual controls using any of its pre-defined list of rates, so my original suspicions that NINA was doing something wrong with MoveAxis() and rate selection were dispelled with that (and I was suspecting that was the case at first, given the minefield that MoveAxis() and aptly-named IRate interface can be in terms of the standards ambiguity that you've pointed out). I think Andy also mentioned that he was also seeing this under SGPro, which brings the number of apps experiencing this anomaly to at least 3. I PA with SharpCap Pro's PA tool then and for now, and I do the 90* movement that it requires using the APJog utility which doesn't use MoveAxis(), at least when moving the scope in set increments.

I did just look back through my AP ASCOM and APCC logs to a time in the past where I know I tried exercising MoveAxis() commands via the polar alignment plugin, and this is the only mention of "MoveAxis" I see in the logs (timestamp elided for brevity)

ASCOM: Info : GET Slewing = False, MoveAxis(0)=0, MoveAxis(1)=0

All instances of when MoveAxis() was exercised in the app look like the above. The head-scratcher is that there's nothing that seems obvious in relation to moveaxis in the corresponding APCC log. I can zip the two together and forward it to you if you'd like.

Between the hurricane remnants moving towards here and day job stuff, I doubt I will be able to uncover my mount and look into this in detail anytime soon, at least during this week.

/dale

On Aug 30, 2021, at 08:42, Ray Gralak <iogroups@siriusimaging.com> wrote:

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through
USB.
Andy, I also tried using a serial port connection to the mount, which to APCC is the same as the virtual COM port in a USB connection. Again, there was no unexpected behavior.

The only thing left is for you to use the APCC log zipper and zip your APCC and ASCOM logs from last night. It is important to include both logs, so make sure that you use the APCC Log zipper and not the ASCOM Log Zipper (they are two different utilities). If you could provide me with a download like to the zip file, I'll take a look.

Also, what is the exact version number of NINA that you are using?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 10:41 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through
USB.





Re: APCC move axis question

Ray Gralak
 

Andy,

One other possibility is that the move axis rate was near the maximum of 999.99x. Then, when moving to the West, the tracking correction rate subtracted from 999x, which was a legal move rate. However, to the East the tracking rate correction added to the move rate and caused it to go over 999.99x, and thus no movement. Turning off the tracking rate correction would clear the value added or subtracted; therefore, the rate in both directions was legal.

So, if that could have been the case, try lowering the move rate slightly in NINA.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 10:41 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through
USB.


Re: APCC move axis question

Ray Gralak
 

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through
USB.
Andy, I also tried using a serial port connection to the mount, which to APCC is the same as the virtual COM port in a USB connection. Again, there was no unexpected behavior.

The only thing left is for you to use the APCC log zipper and zip your APCC and ASCOM logs from last night. It is important to include both logs, so make sure that you use the APCC Log zipper and not the ASCOM Log Zipper (they are two different utilities). If you could provide me with a download like to the zip file, I'll take a look.

Also, what is the exact version number of NINA that you are using?

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 10:41 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through
USB.


Re: APCC move axis question

Andy Ermolli
 

Ray, The only difference that I see is that you are connected via TCP LAN/WIFI while I am connected through USB.


Re: APCC move axis question

Ray Gralak
 

Andy,

Here's a video that I just created to try to reproduce the issue you are seeing. In my case, NINA and APCC work correctly:

https://youtu.be/_LjjM42UPQE

It was difficult to see any of your NINA settings in your video, so if you see anything different in my settings let me know.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 8:44 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Here is a brief video showing what I am seeing. I'm starting to get hang of YouTube video uploading!
https://youtu.be/A-Q0RwHu8ik


Re: APCC move axis question

Andy Ermolli
 

Here is a brief video showing what I am seeing. I'm starting to get hang of YouTube video uploading!
https://youtu.be/A-Q0RwHu8ik


Re: APCC move axis question

Ray Gralak
 

Andy,

In the custom rate setup in APCC I tried to change it to "relative to zero" and "relative to sidereal" but that
didn't seem to make any difference.
That won't change the behavior. That simply changes how the rates are shown in the status fields.

I also tried the move axis command without APCC, just using the AP V2 driver, and that always worked fine
with both the CP4 and the CP3 V2chip (with the CP3 I had to choose a rate of 4 or less and that is expected).
Assuming MoveAxis was being used, I have confirmed that the behavior is the same with or without APCC running. So, I am not sure what you were seeing, except that maybe PulseGuide was used instead of MoveAxis.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of Andy Ermolli
Sent: Sunday, August 29, 2021 4:34 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

This is a non issue to me because now I know to turn off tracking correction should I use the automated 3PPA
in Nina. That should be done anyway as Ray pointed out.
As far as I can tell other move commands in NINA work fine. The only other instance where NINA moves the
mount is during framing of the target. I believe that uses the slew command, not move axis and I didn't see
anything unusual happening during the framing process.
In the custom rate setup in APCC I tried to change it to "relative to zero" and "relative to sidereal" but that
didn't seem to make any difference.
I also tried the move axis command without APCC, just using the AP V2 driver, and that always worked fine
with both the CP4 and the CP3 V2chip (with the CP3 I had to choose a rate of 4 or less and that is expected).
So in essence for my specific use case I am happy with the current software and drivers as they are.


Re: APCC move axis question

Andy Ermolli
 

This is a non issue to me because now I know to turn off tracking correction should I use the automated 3PPA in Nina. That should be done anyway as Ray pointed out.
As far as I can tell other move commands in NINA work fine. The only other instance where NINA moves the mount is during framing of the target. I believe that uses the slew command, not move axis and I didn't see anything unusual happening during the framing process.
In the custom rate setup in APCC I tried to change it to  "relative to zero" and "relative to sidereal" but that didn't seem to make any difference. 
I also tried the move axis command without APCC, just using the AP V2 driver, and that always worked fine with both the CP4 and the CP3 V2chip (with the CP3 I had to choose a rate of 4 or less and that is expected).
So in essence for my specific use case I am happy with the current software and drivers as they are.


Re: #APCC Pro 1.9 w/ASTAP platesolve test always fails #APCC

legendtrail@...
 

To the OP,
A few weeks ago, I upgraded Windows 10 to 19043, and began having problems with a number of applications. This included the same
sort of problems you have mentioned. I installed APCC and tried running a model, and it just would not solve 2+2.  Whenever this happens
to me, and the whole user world isn't screaming, I start looking at my particular environment. I have to assume it's not the application. In this
case, I had to give controlled folder access to APCC, Maxim, and Pinpoint, and provide private firewall access to Pinpoint. Now everything
solves locally in about 15 seconds and my environment is still secure, as much as it can be.  I don't know anything about your environment,
but its worth looking at your security plan and making necessary changes.


Re: APCC move axis question

Ray Gralak
 

So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where
"supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How
does it know the proper slew rate?
The ASCOM MoveAxis method takes two parameters: an axis number and a rate in degrees/second. When initially defined (years ago) the rates were intended to be independent of sidereal rate, for anything from custom telescope control systems to tracking artificial satellites.

Since then, some drivers have interpreted the Right Ascension MoveAxis rate to be relative to the sidereal rate. However, the AP V2 ASCOM driver has always interpreted the axis rate to be relative to zero for both the RA and Dec axes.

I think the ASCOM driver is compliant with ASCOM documentation, but I am open to adding a configuration option to allow the MoveAxis RA rate to be relative to sidereal.

-Ray


-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, August 29, 2021 2:23 PM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding
the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.

However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The
ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that
the previous tracking rate should be restored when the move axis rate is set back to zero.

So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where
"supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How
does it know the proper slew rate?

Maybe I should just vanish from this discussion and let Dale or one of the NINA folks decide if there's
anything to do. I'll just make a mental note not to use the arrows in NINA.

Thank you for taking a look and the explanation.

Linwood






Re: APCC move axis question

ap@CaptivePhotons.com
 

Ray said:

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.
However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that the previous tracking rate should be restored when the move axis rate is set back to zero.
So it may be the structure of the command sent from NINA? It's supposed to specify a slew rate? (Where "supposed to" is apparently clouded in lack of a clear standard, but in this case if it did, it would work?) How does it know the proper slew rate?

Maybe I should just vanish from this discussion and let Dale or one of the NINA folks decide if there's anything to do. I'll just make a mental note not to use the arrows in NINA.

Thank you for taking a look and the explanation.

Linwood


Re: APCC move axis question

Ray Gralak
 

Hi Linwood and Andy,

I took a quick look at this issue, and I don't believe there is a problem with APCC. APCC is properly adding the rate supplied to it whether or not pointing and/or tracking rate correction is enabled.

However, the ASCOM driver is sending an RA movement relative to zero, which is maybe the problem. The ASCOM definition for this method is unclear if the rate should be relative to sidereal or not. It only states that the previous tracking rate should be restored when the move axis rate is set back to zero.

-Ray

-----Original Message-----
From: main@ap-gto.groups.io [mailto:main@ap-gto.groups.io] On Behalf Of ap@CaptivePhotons.com
Sent: Sunday, August 29, 2021 8:59 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] APCC move axis question

Ray said:

You should disable tracking/pointing correction during polar alignment routines, or you may get a bad polar
alignment result.

That's a fair point, but really steps around the core issue.

As a simple example, the NINA control panel has simple N/S/E/W controls. These stop working when pointing
corrections are active. I have no idea if there are other places in other programs that also use move-axis.

Should these in fact be failing when pointing corrections are active?

I just tried a trivial example:

- Opened APCC, initialized (tracking = 0), pointing corrections disabled
- Opened NINA, connected
- Using NINA control slewed N, then S - worked fine, fast (APCC showed it slewing)
- Checked pointing corrections
- Slewed N, S - no motion. Only thing I saw on APCC (or maybe ASCOM V2) was flickering from custom to
sidereal rates as I pushed the button

This itself is hardly an earthshaking issue since I can just use the APCC controls to slew (if my sleep deprived
brain can remember in the wee house), but it does bring with it a concern that other features of NINA or other
software connecting via ASCOM my not work.

Or is everyone pretty sure this is a very isolated case and nothing else uses move axis?

Or are you saying that Move Axis itself, if allowed, would break the pointing model?

Linwood

PS. Logs available if desired from that brief test.





Re: APCC move axis question

ap@CaptivePhotons.com
 

Andrea wrote:

 

  • Linwood,
  • Can you remind me your mount type?
  • About one year ago I saw something similar in Skyx but I thought was because the mount was new ( Mach 2). After that I learned to use the move commands in appc and I don’t know if it has been fixed. In my case the move click in Skyx caused a perpetual slewing that I needed to stop in appc. I didn’t use any model at that time.

 

It's an AP1100AE.

 

I had a MyT with TSX before, and used NINA, and did not have this issue (no APCC involved in that case of course).

 

Linwood

 

5841 - 5860 of 86335