Does anyone know how to get SGP to do its meridian flip before the time shown in the lower right of the screen (under Scope)? I am finding that the FW is getting way to close to the pier an hour before the scheduled flip time and I can’t add a negative number in the “Minutes Past Meridian to Flip:” box.
SGP does not ‘flip’ any mount. There is no ASCOM ‘flip mount’ method.
SGP simply issues a slew command that is interpreted by your telescope driver which does the flip. That only works if it on or past the meridian.
Even if you could flip, you would not want to without a healthy delay…or the mount would end up with the counterweight higher than the camera on the other side and you have another clash.
@buzz Any mount can do as you say, but some mounts can be forced to flip. If the mount returns “CanSetPierSide” as true, then “SideOfPier” can be set to force a flip. I believe SGP does check this property and use it appropriately. Whether it safe to flip is another story.
I’ll need Ken or Jared to confirm but I’m pretty sure they stated in a post last year that they simply issue a slew command, hence my post.
So, whats being said here is that SGP takes the meridian info from the mount software (APCC for my AP1100GTO mount) and issues a “flip” command based on those settings?
@buzz According to this post by @Ken from Feb 2016, they do use SideOfPier
For pier flips, SGPro supports two different kinds of mounts… those that allow us to send a command to flip and those that don’t (then we use normal slew commands in lieu of this). orm meridian flip
This depends on the mount. If the mount supports CanSetSideOfPier then we flip via the SideOfPier (our preferred method). If the mount does not then we have to wait until it tracks past the meridian and issue a slew. Also in the case where SideOfPier is not supported we cannot flip prior to the meridian.
I had thought that APs could flip before the meridian. Maybe this is something with how your limits are setup in APCC. Thoughts @rgralak?
Thanks,
Jared
all, thanks for the clarification, that’s good to know as my next telescope may have more restrictive limits
Here’s a post that might help:
jared - i think we went thru this in another thread some time ago. APCC can set limits before the true meridian and one of the actions APCC can take when it hits this limit is to flip the mount. but obviously SGP won’t be expecting that and at best would end in a successful recovery. at worst of course the sequence would come to an end.
i believe that ray stated that the AP Driver does not support CanSetSideOfPier / writing SideOfPier because AP’s management is not sure it’s a safe thing to do without giving it more thought. obviously with all the meridian limits that APCC supports, the user could declare that it is safe by setting appropriate limits on the east and west side of the pier.
IIRC chris chimed in before and said that maybe the right thing to do in ASCOM anyway would be to support some new methods which drivers could export, with semantics like “minutes until unsafe in current pointing state” or “minutes until safe in opposite pointing state.” but i’m not sure this stuff ever came up with the ASCOM developer committee.
@jared if APCC sends a negative meridian delay to SGP via the “send limits to SGP” API, does SGP clamp that to 0?
I’d have to validate that through the API. I know if you then go and open the meridian flip options that it would reset it to 0 if that happens to work. Honestly I’d really need Ray to weigh in here. He knows what APCC is capable of more than I.
Thanks,
Jared
OK thanks. just as a data point, i tried a couple of things last night (with no success.)
-
set an early meridian limit in APCC and check “send limit to SGP” - SGP kept imaging past the limit. APCC was set to “warn only” because i didn’t want the mount to stop for purposes of the test; not sure if that has any bearing on what APCC sends to SGP.
-
set an early/late meridian in APCC with “send limit to SGP” set. if i set +1 hours in APCC, SGP showed 60min in the meridian flip configuration pane. if i set -1 hours in APCC, SGP showed 60min (no sign change.) when the meridian was set 1 hour early (+1h in APCC), SGP imaged right past the early meridian and did not attempt a flip.
so - i’m guessing that the lack of writeability of SideOfPier still prevents an APCC-driven AP mount from doing an early flip.
i guess another concern i have with the “send limit to SGP” is that even for delayed meridians, since both SGP and APCC are using the same time value, isn’t there a race condition here? APCC’s limit should always be a little later than SGP’s just to give SGP time to issue the slew, but if APCC sends it’s limit to SGP that doesn’t leave any time for the pre-flip housekeeping. maybe APCC is trimming what it’s sending to SGP; i assume SGP would not modify the limit set via the API…
thanks,
rob
Hi Rob/Jared,
Rob, that’s a good point about the possible race condition with the flip time. That comment reminded me of a note I had made to myself about the possibility of that exact issue.
So, please give me a day or two to look into this. I think it would be easy to add in another time duration value in APCC to cause the flip to happen a user-defined number of minutes early of the APCC’s meridian limit. I’ll also double check the value APCC is sending when the target is to the East of the meridian in a counterweight-up position.
BTW, I’m not sure if the reported issue is with 2.x or 3.x? Jared, has anything changed in this area of SGPro for 3.x? I’m guessing probably not, so I probably can just test with 2.x, correct? (I think I only have a license for SGPro 2.x.)
-Ray
sounds good - unfortunately i’ve never used the “send limit to SGP” since after adding riser blocks to my telescope, i can safely pass the true meridian, and so my APCC limit is essentially a straight line 45 mins after the meridian. thus i just have it statically configured in SGP (though there is still the possibility for APCC to stop the mount before SGP slews - i think if you get really unlucky with image timing this can happen, and if SGP is waiting to go to the next target it can also happen, but such situations are pretty rare in my experience.)
OP’s problem is the problem i had before i added the risers; i needed to flip a little bit early, but my understanding is due to the lack of writability of SideOfPier, that it was impossible for SGP to cause a flip to happen early on an AP mount. i think you had mentioned that roland/howard/george/marj had decided this was too dangerous to implement. a question i have about this is how is it any different than specifying an early meridian (say, without APCC and only in the AP driver) and then issuing a slew after the early meridian is passed? clearly the user could cause an east-side pier crash using an early meridian even without writable SideOfPier.
i have sgp 3.x so i can test your changes if necessary (however i have not yet upgraded to the latest ascom release, which could be a showstopper if your beta requires it.)
a question i have about this is how is it any different than specifying an early meridian (say, without APCC and only in the AP driver) and then issuing a slew after the early meridian is passed? clearly the user could cause an east-side pier crash using an early meridian even without writable SideOfPier.
If a user sets the meridian delay manually then they have accepted the risk associated with setting that meridian delay. However, if an application (not necessarily SGPro) arbitrarily causes a pier flip from an unexpected position then a pier collision may occur since there are no hard stops like on some mounts.
APCC prevents crashes by allowing the user to define the meridian delay as a function of declination.
-Ray
Are you using the meridian delay feature on APCC (or even the ASCOM driver, both support it)? That is what I use. Meridian delay should be honored by SGP (APCC should pretty much override anyway if SGP did not), and in my case (Mach 1) it will flip once the scope reaches the moment defined by the delay.
Something to note about meridian delay…certain things that SGP does may result in a check slew, where the mount will slew to the true meridian, then back to the right location pre-meridian (if you are in the pre-meridian part of the delay). This is particularly noticeable with plate solving, which might result in multiple check slews.
you are saying that if you set the meridian delay early in APCC then SGP is allowing you to enter a negative number in the “minutes past meridian to flip” configuration?
it’s my understanding that SGP just won’t let you enter a value less than 0 here, and “send limits to SGP” is under the same restriction.
I’m using the Meridian delay feature but it has no effect on the SGP Flip time, I tried -1 hr and 1hr:
How about turning your filter wheel upside down? About to flip, my mount flips when I tell it to with the hand controller. Right now I have it set to flip I think it’s 20 degrees or something like that passed Meridian. As you can guess I don’t flip.