Thanks for the replay, Ray! That's what I had expected.  I should have that covered since slaving with DeviceHub and SGP both seem to work and both use the same ASCOM methods.  Based on one of your

If the second object was almost but not quite at the meridian, the mount would have acquired it with scope on the west side, then continued tracking until the scope was under the mount. That's

Howard will check your log. It will show all the commands that were sent. Rolando

The ASCOM log was linked to in the original post, but here it is again: ASCOM LOG. Actually I use Park 5. Interesting. I did have another target that was supposed to begin at 02:00, but I thought

Whatever happened, the mount did a meridian flip back again into a counterweight up position. The driver log should show what happened. Roland

Hi Joel, Please send me your ASCOM log file from last night. I'm going to make an educated guess here: Do you use Park 2 as your park position?

The pier flip definitely happened. Images before and after are flipped. I suck at reading logs. According to the SGP log the meridian flip was called for at 22:08:03 (about 1min after the target

It looks like the pier flip did not occur and the mount continued with counterweight up position. It's possible that the program that sent the pier flip command did not actually send it to the driver,

Is anyone using their mount for satellite tracking? I am starting to go through the Horizons manual. I am interested in amateur radio satellite tracking in particular. -- Dean

Thanks Roland. I have already brought the mount back with a CCW rotation, and restarted the mount just to make sure the motors and everything still worked properly (which it does). But I'm having

It appears that the scope tracked past the meridian and continued until it was past the west side upside down. Apparently you do not have the limits turned on, so there is nothing that would stop the

I have an AP1100GTO CP4 and use the ASCOM driver for mount control, with SGP and PHD2. Last night I had a pier crash and it is really puzzling as to what happened and I could use some help figuring

Hi Shane, Yes, through ASCOM, but as I alluded to, the API is lacking. It does not provide the dome with enough information to calculate position. In Active mode, APPM first checks if the driver

Hi Ray, I'm currently working on motorizing my dome and am in the middle of testing my newly written ASCOM driver and want to make sure that I can support APPM. How does APPM send the telescope's

Thanks Ray, I appreciate your patience in this thread. I know its a small niggly thing. Appreciate everything you've done. Cheers

Tony, APPM sends the telescope's destination coordinates to the Dome driver that to which APPM is configured. IMO the Dome driver should be intelligent enough to figure out where the telescope is

Vincent, The AP grease kit is not on their website, you have to call them for it, but I would think you could also get it from their European distributor. The kit includes good instructions. You

Think I'm slowly getting a grip on the main issue here. If I'm slewing the scope from within SGP then there is no delay - the scope and dome move together in beautiful harmony. But once an outside

So heres what the dome looks like now with the new APPM ver. It all works and probably won't get any fails. What I would really, really like is to find out who/how can get the dome to move in time

Hi Rowland - Hope you didn't lose any sleep over this issue! Thanks for the additional idea and detailed pictures - I just checked and all the screws there were rock-solid tight. So that's not