Guys, sorry I haven’t had a chance to report back here on this issue. I’m hoping before next week to make available a beta version of APCC where you can pad the flip point X number of minutes before the mount’s meridian limit. APCC will be able to send the padded flip point so SGPro can flip the mount before it hits the mount’s meridian limit.
Also, I looked into the negative meridian limit issue, and it may not be SGPro’s fault after all. APCC is sending the absolute value of the limit value so there never could have been a negative limit. That said, I don’t know for sure if SGPro will accept the negative limit value, but if Jared and Ken said it should then this build should also address that issue.
thanks - if i understand what ken and jared said, SGP won’t accept a negative limit because SideOfPier is not writable. well, i guess they never confirmed that you can’t set a negative limit via the API, but you certainly can’t in the SGP user interface.
All that needs to be done is for SGPro to issue a slew to the same target at the appropriate time. The mount will Automatically flip to the appropriate side. There is no need to write to SideOfPier.
One possible solution is for SGPro to attempt to write SideOfPier and if an exception occurs issue a goto to the same RA/Dec. For mounts that don’t flip this is safe because the mount should already be at that RA/Dec so it ends up being a no-op. For A-P mounts a flip would occur automatically if the meridian delay is set appropriately.
We flip in one of 2 ways, depending on what CanSetSideOfPier returns:
If CanSetSideOfPier returns true we set SideOfPier to run the flip. If that fails we attempt the slew method. This allows us to flip prior to the meridian.
If CanSetSideOfPier returns false then we wait until the mount slews past the meridian and issue a slew.
It sounds like Rob is wanting to flip prior to the meridian which is not possible in this case.
Jared, could the logic change slightly? APCC sends the hour angle flip point so SGPro knows that. When the mount passes the flip point and CanSetSideOfPier is false, could SGPro issue a “Go to” the current RA/Dec? If the mount can’t flip it’s essentially a null operation, but if running APCC it would be able to flip. The reason why I am asking this is A-P doesn’t want to enable writing to CanSetSideOfPier at this time for various safety reasons.
So this should, theoretically, already be happening. SGP really only limits the values in the UI based on CanSetSideOfPier but if that value is prior to the pier (by being set in the API) then SGP will still respect that. And then we’ll decide how to flip based on CanSetSideOfPier which in the case of the AP should already be happening.
But SGP will only flip at or after that point. Will APCC attempt a flip at the same point?
It seems like maybe this should be working? I’d probably need to look at an SGP log that had this value set via the API and see what the result is. Another issue that could arise is that if someone opens the meridian flip settings in SGP it will “bound” that value back to 0 if APCC had set it as negative. Is APCC ever resending this value?
the behavior is programmable in APCC. you can tell it to flip the mount, or stop tracking, or park, or just put up a warning. i have mine set to park in place (i think i got burned once with ‘stop trackinf’ when phd somehow started tracking again and put the camera into the tripod)
seems like the UI silently overwriting the API value could lead to unexpected behavior… i think ray said upthread that apcc sends the limit on every slew since the limit is a surface which is a function of declination. but if the user opens the dialog the limit will be destroyed and apcc wouldn’t know to resend it at that point.
When a meridian limit (actually a tracking limit designed to keep the scope from hitting the pier) is reached, “stop” and “park in place” currently have the issue that the mount never goes past the limit, so SGPro never does the flip. Once Ray’s able to add a “buffer” to APCC, SGPro will think the pier flip should be done when the buffer is reached (I assume because APCC will tell SGPro that’s where the “meridian” is), and since the mount will continue tracking until the buffer is exhausted and the actual limit is reached, SGPro should initiate the flip shortly after the buffer is reached. Ray can correct me, but I don’t think a negative value is needed once the “buffer” is implemented.
If I understand things correctly, in the case where someone is using the “meridian limits” in APCC (like I do), APCC sends SGPro the time the limit will be reached, and hence when a flip should happen, which is most cases is past the meridian - depending on DEC, it can be a couple hours past the meridian.
Please contact me via private message if you are currently running APCC with an Astro-Physics mount and would like to test a beta version of APCC (Standard or Pro) that adds a user-configurable “buffer” before the meridian limit.
The beta version works by setting the meridian flip point earlier than than the meridian limit. The earlier flip point is sent to SGPro. Once the mount reaches the meridian limit it can be flipped with a slew to the current RA/Dec. If left tracking the mount will eventually hit the meridian limit and do the configured operation (e.g. stop tracking, park, etc.)
hi @jared - i am testing ray’s changes and i ran into something that i thought was fixed a while back. having said that i am running a downrev version of sgp (3.0.0.7), so maybe this is a bogus bug report.
ray’s new method for sending the meridian delay to SGP is working well, however, i got very unlucky with timing tonight. SGP checked if a meridian flip was necessary, then an autofocus fired, and by the time the next exposure started, there was not enough time to complete the exposure before the limit was reached. i know a similar problem came up long back and i thought you had moved the meridian flip check to happen right before an exposure was started.
recovery mode kicked in, but because i asked APCC to park the mount on limit reached, the recovery got stuck since the mount would not slew. i’m not sure if it makes sense for the recovery code to try to unpark the mount or not. i guess i can avoid this by asking APCC to flip the mount when the limit is reached.
@jared, here are the logs if you are interested. highlights:
[11/03/18 21:43:18.806][DEBUG] [Sequence Thread] Checking if Meridian Flip is needed
[11/03/18 21:43:18.808][DEBUG] [Sequence Thread] Telescope is on the West side of the mount
[11/03/18 21:43:18.808][DEBUG] [Sequence Thread] Meridian Flip not needed, Hour Angle < Degrees Past To Flip: 1.58837499999997 < 3.75
[11/03/18 21:43:24.771][DEBUG] [Camera Thread] Performing Sequence Generator auto focus using Half Flux Radius. AFID: 2
[11/03/18 21:50:17.222][DEBUG] [Sequence Thread] Created base name for frame capture: tmb_ori_bubble_Light_OIII_5nm_2018-11-03_215017_1800s_bin1x1_sky_90.2deg_rot_0.2deg_OIII
0528980 2018-11-03 22:21:23.940: Info, Meridian Limits, Limit reached - Parking mount - Dec=61.3538972242121, MeridianAngle=113.510841671607, Hour Angle=0.748849093914032
( back to SGP, guidestar lost as mount starts to park)
[11/03/18 22:21:41.172][DEBUG] [PHD2 Listener Thread] Error: Guide star reported as lost!
so basically at the time the meridian check was done, 22:21 - 21:43 = 38 minutes, but with a 30 minute exposure and ~7 minute AF time, i hit the limit.