APCC move axis question


Andy Ermolli
 

Does APCC take the move axis command? I'm using the V2 driver 5.21.01connected to a virtual port Com10 created by APCC. I use NINA as the Ascom client app. 

If I push the move axis button in the client app I see the custom rate change in the Ascom Driver window but not in the APCC status window. The mount does not move.
The mount this time is the AP900 with firmware V2. 

If I connect NINA directly to the driver and not use APCC then the move axis command works as expected.


Ray Gralak
 

Andy,

APCC has always supported the "MoveAxis" command through the ASCOM driver.

I just tried it, and it works for me using the V1 chip using my own ASCOM test application.

BTW, since you are having so much trouble with MoveAxis, have you tried the AP V2 ASCOM Driver's APJog utility? It works by slewing the specified distance instead of using MoveAxis. It's way more predictable than using button presses which might get delayed by Windows and user interface events.

-Ray

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

Does APCC take the move axis command? I'm using the V2 driver 5.21.01connected to a virtual port Com10
created by APCC. I use NINA as the Ascom client app.

If I push the move axis button in the client app I see the custom rate change in the Ascom Driver window but not in
the APCC status window. The mount does not move.
The mount this time is the AP900 with firmware V2.

If I connect NINA directly to the driver and not use APCC then the move axis command works as expected.


Andy Ermolli
 

Hi Ray,
I have the Jog utility but I am trying to use the three point polar alignment routine with NINA and that requires the client app to be able to use the Moveaxis command.
If it's working for you it must me something with my settings or my client app. I am going to keep digging into the settings.
What client app are you using?


Andy Ermolli
 

I have an update. Had my virtual port set to com10 and it didn't work. When I set the virtual port to com20 everything worked fine. 
Is it OK to keep the port at com 20? I read in the manual that I wouldn't be able to use pulse guide with a port number higher than com10.
I use PHD2 for guiding which connects to the AP v2 driver.


Chris White
 

Interesting Andy. I use phd2 for guiding and my virtual ports are 20 and 21 I believe. I have no problems that I know of. I have not used the new apcc pro update yet, so maybe this port number thing is something new?


Andy Ermolli
 
Edited

There is something going on with my Com ports that I don't quite understand and the virtual ports in APCC seem to interfere with my actual com ports.
Chris do you have your mount connected directly to the computer or to a hub? My mount is connected to the UPBV2. I wonder if that is the issue.


Stacey Mills
 

You need to make sure that APCC closes itself rather than having another program terminate it improperly.  When APCC closes itself it closes (inactivates) the virtual ports.  If the program is terminated without normal closure the virtual ports will still be there "active" and the next time you start APCC they won't be available and it will have to make new virtual ports.  Use Device Manager and check your COM ports.  It helps to check the "View, show hidden devices"  which will show inactive Com ports.  It's OK if they're there but they shouldn't still be "active."

-Stacey


Chris White
 

On Sun, Aug 22, 2021 at 08:15 PM, Andy Ermolli wrote:
There is something going on with my Com ports that I don't quite understand and the virtual ports in APCC seem to interfere with my actual com ports.
Chris do you have your mount connected directly to the computer or to a hub? My mount is connected to the UPBV2. I wonder if that is the issue.
My mount is connected directly to my computer.  All my imaging gear, etc... is connected through a Pegasus Advance which is mounted on the OTA.  This cables off to the PC which is under the mount. 

Where did you read about pulse guiding not working if the VP's were above 10?  IIRC when I setup APCC a few months ago it was suggested to use really high numbers to ensure there would not be any conflict between the VP's and the actual ports. 


 

>>> Interesting Andy. I use phd2 for guiding and my virtual ports are 20 and 21 I believe.

i've only used ports 20 and 21, and had no issues with APCC. i don't think port numbers that high are the issue. usually it's lower port numbers that could cause potential interference

On Sun, Aug 22, 2021 at 4:37 PM Chris White <chris.white@...> wrote:
Interesting Andy. I use phd2 for guiding and my virtual ports are 20 and 21 I believe. I have no problems that I know of. I have not used the new apcc pro update yet, so maybe this port number thing is something new?



--
Brian 



Brian Valente


Ray Gralak
 

What client app are you using?
As I said, I am using my own ASCOM driver test application. It doesn't use buttons. It just has the ability to set a MoveAxis value, which stays until changed. This makes it easy to confirm the mount is moving.

The problem is many people have Windows problems or are using a remote desktop application or something else (e.g., WiFi) that causes an issue. For instance, a button press may not always register with an application making a user think there is a problem with the software when it's their computer or network that's the issue.

-Ray

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

Hi Ray,
I have the Jog utility but I am trying to use the three point polar alignment routine with NINA and that requires the
client app to be able to use the Moveaxis command.
If it's working for you it must me something with my settings or my client app. I am going to keep digging into the
settings.
What client app are you using?


Andy Ermolli
 

I am convinced that the issue is either within windows or could be related to the fact that I have the mount not directly connected to the computer, no doubt. I was hoping that someone else had run into it before and they had an easy solution, that's all.

If I connect directly to the ASCOM Driver without using APCC everything works perfectly so that's what I am going to do for now. A pointing model would be nice but it's not really required for the type of imaging that I do (wide field).

I opened the device manager with the view "View, show hidden devices" checked and I didn't see anything strange.
Regarding pulse guide and ports over Com10, I read it in the APCC documentation, this is the link https://www.siriusimaging.com/Help/APCC/virtual_ports_tab.htm
It's the second bullet point in the top quarter of the page. Should be easy to find.


Ray Gralak
 

Regarding pulse guide and ports over Com10,
Just to be clear, this is a reference to PulseGuide, the software application I wrote almost 20 years ago. This is not the same as the ASCOM pulseguide method.

-Ray

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

I am convinced that the issue is either within windows or could be related to the fact that I have the mount not
directly connected to the computer, no doubt. I was hoping that someone else had run into it before and they had an
easy solution, that's all.

If I connect directly to the ASCOM Driver without using APCC everything works perfectly so that's what I am going
to do for now. A pointing model would be nice but it's not really required for the type of imaging that I do (wide field).

I opened the device manager with the view "View, show hidden devices" checked and I didn't see anything strange.
Regarding pulse guide and ports over Com10, I read it in the APCC documentation, this is the link
https://www.siriusimaging.com/Help/APCC/virtual_ports_tab.htm
It's the second bullet point in the top quarter of the page. Should be easy to find.


Andy Ermolli
 

Thanks for clarifying. I didn't catch that.


Andy Ermolli
 

I think I figured out what was causing my issues with move axis. I had tracking correction turned on in APCC, that seemed to conflict with the direction arrows in NINA.
Once I turned it off the direction arrows worked consistently as expected. The easy fix is to turn off tracking correction during the automated 3 point polar align with NINA and then turn it back on after it's done!


Ray Gralak
 

Andy,

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

BTW, changing polar alignment invalidates the model anyway.

-Ray

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

I think I figured out what was causing my issues with move axis. I had tracking correction turned on in APCC,
that seemed to conflict with the direction arrows in NINA.
Once I turned it off the direction arrows worked consistently as expected. The easy fix is to turn off tracking
correction during the automated 3 point polar align with NINA and then turn it back on after it's done!


ap@CaptivePhotons.com
 

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.


Ray Gralak
 

Linwood,

Yes, this seems like a bug and is already on my list to investigate. I have just barely caught up with answering online and private offline questions, looking at logs, etc. This hasn't left me much free time to focus on fixing the issues reported.

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





ap@CaptivePhotons.com
 

Ray:

Yes, this seems like a bug and is already on my list to investigate. I have just barely caught up with answering online and private offline questions, looking at logs, etc. This hasn't left me much free time to focus on fixing the issues reported.
Yeah, I understand the feeling, I find it hard to believe you can get any actual development done with the volume of email.

The mixed blessing of having people actually use the software you write! 😊

Linwood


Andrea Lucchetti
 

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

On Sun, 29 Aug 2021 at 17:59, ap@... <ap@...> wrote:
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.







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