AP app stack


Rich
 

Just spent the last 8-9 hours trying to figure out why I can’t plate solve or initiate SGP sequences through AP V2 Ascom Driver - APCC.  Turns out when PHD2 (Ascom client 1) tried to talk to my 1600 through AP V2 (not sure of the priority or order) it was trying to create the virtual com crap (won’t work on my machine), then tried to go through REST API via TCP/IP socket 127.0.0.1:600001(? I’m guessing).  PHD2 couldn’t talk to the mount so my plate solver  ASTAP/ ansvr (apache server) at 127.0.0.1::8080 couldn’t get updated data for the plate solve because it couldn’t operate the mount. Same thing happened with SGP (ascom client 2) only the program froze solid (ah those interfaces).  PHD2 would wait for the interface to go live and just blink out when I tried to look at what was happening in AP V2.  I know there is a virtual com port issue because the ascom client interface just started trying to create virtual COM3 and COM4 on my machine.  Don’t know where that came from because I’ve been talking to the mount via ethernet TCP/IP REST API.    Does any have a clue what’s going on, but more importantly how do I get back to imaging?????

 

Thanks,

Rich Gibbons


 

Hi Rich

what versions of the applications are you using?

Generally, I start up APCC and connect it to the mount before I do anything else. 

That seems to work for me regarding connection order

On Sun, Nov 6, 2022 at 6:02 AM Rich via groups.io <gibbonsrk=verizon.net@groups.io> wrote:

Just spent the last 8-9 hours trying to figure out why I can’t plate solve or initiate SGP sequences through AP V2 Ascom Driver - APCC.  Turns out when PHD2 (Ascom client 1) tried to talk to my 1600 through AP V2 (not sure of the priority or order) it was trying to create the virtual com crap (won’t work on my machine), then tried to go through REST API via TCP/IP socket 127.0.0.1:600001(? I’m guessing).  PHD2 couldn’t talk to the mount so my plate solver  ASTAP/ ansvr (apache server) at 127.0.0.1::8080 couldn’t get updated data for the plate solve because it couldn’t operate the mount. Same thing happened with SGP (ascom client 2) only the program froze solid (ah those interfaces).  PHD2 would wait for the interface to go live and just blink out when I tried to look at what was happening in AP V2.  I know there is a virtual com port issue because the ascom client interface just started trying to create virtual COM3 and COM4 on my machine.  Don’t know where that came from because I’ve been talking to the mount via ethernet TCP/IP REST API.    Does any have a clue what’s going on, but more importantly how do I get back to imaging?????

 

Thanks,

Rich Gibbons




Ray Gralak
 

Hi Rich,

 

> Just spent the last 8-9 hours trying to figure out why I can’t plate solve or initiate SGP sequences through AP V2

> Ascom Driver - APCC.  Turns out when PHD2 (Ascom client 1) tried to talk to my 1600 through AP V2 (not sure

> of the priority or order) it was trying to create the virtual com crap (won’t work on my machine), then tried to go

> through REST API via TCP/IP socket 127.0.0.1:600001(? I’m guessing). 

 

Just because APCC created virtual ports does not mean that the driver tried to use them. The driver will not try to use virtual ports then fall back to REST.

 

The usual reason for no response was that APCC had trouble communicating with the mount.

 

To stop APCC from creating virtual ports you will need to:

 

1. Always start APCC first (recommended) instead of letting the driver start up APCC.

2. In the Mount group box, uncheck "Auto-Connect" and "Create Virtual Ports first". In the “AP V2 Driver” groupbox, uncheck “Auto-connect”. Here is a screenshot:

 

3. On the “Virtual Ports” tab, delete any active virtual ports, and set the port number to “None”, like this:

 

 

But this won’t stop a communications problem. After you have setup everything above and if you still have your mount setup, try connecting again and instead of PHD2, try connecting with the AP Jog utility, which is included with the AP V2 driver. This is a bare minimum connection that will tell if APCC and driver are communicating. If they are then it might be a problem with PHD2 or SGPro that is the real issue. For example if the USB connection to the camera fails or is intermittent there can be long pauses in some applications trying to communicate with the camera. So what you are seeing may not be a mount problem.

 

-Ray

 


Rich
 

Hi Ray,

Having had problems with virtual com ports I disable their creation wherever I see the possibility.  I always launch APCC first unless I’m trying to track down something. I had Auto-Connect on the mount and nothing checked on the AP V2 Driver box.   Whenever I tried to access the AP V2 (after APCC was running and connected) through SGP or PHD2 via their setup/config options it would launch the AP V2 setup utility and either freeze or close.  Can there be multiple instances of AP V2 Driver? Prior to last night I made sure no virtual com ports were “waiting”.  COM3 and COM4 showed up last night I assume after I hit the setup config options in SGP and PHD2. I thought everything was going through REST.  I have not noticed any lag/latency on my sensor USB links. 

I was checking tracking last night and noticed Tracking was “Custom” .  I did not and do not know what that means, specifically (I learned about Kings Tracking Rate for the first time). I have a 54 point model loaded  so I pushed the Point and Rate Correction buttons.  Could there be a correlation with the interfaces to SGP and PHD2?  Shooting in the dark here.

 

Thanks for any help,

Rich Gibbons

 

From: main@ap-gto.groups.io <main@ap-gto.groups.io> On Behalf Of Ray Gralak
Sent: Sunday, November 6, 2022 6:28 AM
To: main@ap-gto.groups.io
Subject: Re: [ap-gto] AP app stack

 

Hi Rich,

 

> Just spent the last 8-9 hours trying to figure out why I can’t plate solve or initiate SGP sequences through AP V2

> Ascom Driver - APCC.  Turns out when PHD2 (Ascom client 1) tried to talk to my 1600 through AP V2 (not sure

> of the priority or order) it was trying to create the virtual com crap (won’t work on my machine), then tried to go

> through REST API via TCP/IP socket 127.0.0.1:600001(? I’m guessing). 

 

Just because APCC created virtual ports does not mean that the driver tried to use them. The driver will not try to use virtual ports then fall back to REST.

 

The usual reason for no response was that APCC had trouble communicating with the mount.

 

To stop APCC from creating virtual ports you will need to:

 

1. Always start APCC first (recommended) instead of letting the driver start up APCC.

2. In the Mount group box, uncheck "Auto-Connect" and "Create Virtual Ports first". In the “AP V2 Driver” groupbox, uncheck “Auto-connect”. Here is a screenshot:

 

3. On the “Virtual Ports” tab, delete any active virtual ports, and set the port number to “None”, like this:

 

 

But this won’t stop a communications problem. After you have setup everything above and if you still have your mount setup, try connecting again and instead of PHD2, try connecting with the AP Jog utility, which is included with the AP V2 driver. This is a bare minimum connection that will tell if APCC and driver are communicating. If they are then it might be a problem with PHD2 or SGPro that is the real issue. For example if the USB connection to the camera fails or is intermittent there can be long pauses in some applications trying to communicate with the camera. So what you are seeing may not be a mount problem

 

-Ray

 


Ray Gralak
 

Hi Rich,

Having had problems with virtual com ports I disable their creation wherever I see the possibility. I always launch
APCC first unless I'm trying to track down something. I had Auto-Connect on the mount and nothing checked on
the AP V2 Driver box.
COM3 and COM4 showed up last night I assume after I hit the setup config options in SGP and PHD2.
I thought everything was going through REST. I
1. You should uncheck "Auto-connect" in the Mount group box to prevent APCC from creating the virtual ports if the ASCOM driver
starts APCC.

2. You should enable the "Auto-Config" checkbox in the Ap V2 Driver group box. This will make sure the driver stays configured.

I was checking tracking last night and noticed Tracking was "Custom"
That's normal with a model loaded and tracking rate correction is enabled.

-Ray