so similar to the other threads here lately on this topic, i’ve been having meridian flip problems on .457 with the latest version of APCC (APCC Pro v1.8.0.5). APCC is sending the limit with offset to SGP. i haven’t delayed the meridian at all in APCC so my understanding that anytime after crossing the meridian the mount should flip when slewing to an RA which is past the meridian. none of the “counterweight up slew” boxes are ticked.
i can’t be 100% sure if SGP is waiting for the meridian before requesting a flip, however, in this case SGP does seem to be asking for a flip just minutes after the scope crossed the real meridian. i never seem to have this problem with my 1800s narrowband exposures; it always happens with my 240s RGB exposures. i assume this is because the probability of a flip request closer to the meridian is higher with shorter exposures.
here are a couple of SGP logs for this problem. i also have APCC logs zipped up if @rgralak needs to look at them.
i may have erred about the version in this post - the computer is turned off for the day. i did apply all the updates that APCC itself offered me (and the driver) so it is likely i am running 1.8.1.1. when i power up shortly i’ll report the correct version.
sorry, yeah i was wrong about the version (i had just looked at AP’s website thinking the latest was called out there, since the computer was already shut down).
so indeed i am on 1.8.1.1. after reading the other thread about this i upgraded as soon as i could.
yes, and although the mount had probably tracked a minute or so past where it was when SGP tried to flip it, in the morning i asked it to slew to the RA that it was currently pointing to and it flipped. so it seems likely that it should have flipped when SGP asked for it.
can i send you the APCC logs so you can check if the mount was really past the meridian when SGP asked it to flip?
one thing i’m noticing is that the telescope is currently at the meridian and SGP is reporting the time to flip as 45s. when i opened the meridian flip configuration in SGP, it was set to 1 minute.
with a limit surface set to 45 minutes and an offset of 30 minutes, i think that SGP should show 15 minutes until the flip when the telescope crosses the meridian.
i set the delay back to 0 minutes in SGP just to make sure it was not somehow overriding what APCC was sending it and toggled the “send limit to SGP” box in APCC a couple of times, but the status display at the bottom of the SGP window never updated. so it sure seems like SGP is not getting the delay value from APCC for some reason - either it’s not listening or APCC is not sending the right value to SGP. maybe whatever value SGP is using is causing it to ask for a flip before the meridian occurs.
i think for now since i have a static meridian limit in APCC, i’ll just set SGP to 15 minutes past the meridian manually in SGP and i guess i’ll be fine.
Rob, you have clicked the Limit to Meridian checkbox in your configuration above. If I am not mistaken, that means that APCC will trigger a Meridian Flip when the actual meridian is crossed, regardless of the limit set. This is consistent with what you observed.
“Limit to Meridian: Limits the Flip Offset to be at most set to the sky’s real life meridian.”
i guess i don’t exactly know what “at most” means in this context. if it means that the flip offset is set to the actual meridian delay at that declination, then maybe it implies that APCC sends the actual meridian as the flip point, that is an SGP setting of 0 minutes past the meridian. which as you say is consistent with what happened… maybe there is a race condition for a few seconds where SGP thinks the target is past the meridian but APCC does not?
i don’t think i ticked that box on purpose so either i accidentally set it that way at some point or it’s always been ticked.
“At most” means that there could be a safety hole carved out around the meridian (for example near Zenith) which prevents the scope from reaching the meridian. Ray can confirm if my interpretation of the manual is correct.
in anticipation of good weather tonight i started messing with this again. of course i was not being scientific and upgraded SGP before i messed with APCC.
what i can’t understand is how it was working before. i feel like something must have changed in APCC and i didn’t notice. the tooltip for “send limit to SGP” now says nothing will happen unless “counterweight up slews within west limits” is enabled. i’m 100% certain i never had that enabled, because to me this is a little counterintuitive - if there is a non-zero flip offset then it seems like when SGP issues the slew that it thinks will cause a meridian flip, the mount will be within the west limit with the counterweight up, and it won’t actually flip (since it’s been told that slewing to a counterweight-up position in that zone is OK.)
however, without this box ticked it’s obvious that APCC is not sending the meridian delay to SGP. and @lucam yes, you are right, when you tick “limit to meridian” SGP’s reported meridian changes to a number of minutes equal to the difference between the meridian limit and the APCC offset, meaning it snaps to the meridian itself. which is not what i want.
at any rate without the counterweight up button ticked, APCC was apparently not sending anything to SGP and i have no idea what the SGP meridian delay was actually set to. it couldn’t be negative, and even if it was 0 since i have no user-configured meridian delay set in APCC it should have flipped, so it would appear there is some disagreement between the two programs of the actual location of the meridian.
anyway i guess i’ll find out if it works tonight - i don’t see why it wouldn’t since the configuration now matches the tooltips - but i don’t understand why commanding a slew which would ordinarily cause a meridian flip will still cause a meridian flip with “counterweight up slews within west limits” set.
@pfile, sorry I have had limited time to follow this forum and others. I looked at the limits in the code and unfortunately I don’t see any problems in the most recent build.
that’s OK; i don’t think there is actually a problem beyond my configuration, but per the above post i don’t understand why APCC needs to be configured the way it does for this to work.
Without West counterweight up slews enabled the meridian limit is just a tracking limit, not the flip point. Enabling counterweight-up slews allows SGPro to slew to targets within the limit, which might happen during a plate solve/receenter or new target operations.
