You could substitute the following words for “wait for meridian”:
SGP is ready to take the next frame. It will check to see if the next frame can be completed before it hits the meridian. If it can be completed, it will start the exposure. If it cannot be completed, it will sit and wait until the mount has tracked into the meridian. It will then initiate a meridan flip and continue imaging from the other side of the pier.
Conversely, if the box isn’t checked, SGP will check at the end of each exposure and see if the mount has passed the meridian. If not, it will start the next exposure. If it has, it will perform a flip.
For this second option to be usable, you should be able to track the length of your exposure plus some buffer (for example, the time to do an autofocus) past the meridian without danger of hitting the pier. This is what I use with my 1100. I don’t mess with delays or anything, I just let it track past the meridian to complete the image it is working on, then allow it to flip.
yes, i can probably track up to 2h past the meridian if the camera rotation is favorable and about 1h past if the rotation is unfavorable (the STT filter wheel is not symmetrical.)
so i have SGP set to flip around 30mins past the meridian, and APCC set to stop tracking around 40mins past the meridian, because i can’t make assumptions about the rotator angle of course.
i think i have had ‘wait for meridian’ incorrectly checked all these years. all i want SGP to do is to 1) let an exposure continue past the meridian if need be, and 2) not attempt to flip before the meridian has been hit. since at the most i’m using 30min exposures, it sounds like what i should do is set SGP to flip at the meridian, uncheck “wait for meridian”, and leave APCC set to 40mins. then in the worst case SGP should initiate a flip 30 mins + change after the meridian, so those extra 10 minutes should be enough to solve/sync/flip without APCC stopping the mount.
I think that having SGP set to flip 30 minutes past the meridian means that SGP effectively acts like the meridian has shifted to 30 minutes later. So it will use a time that is 30 minutes after the mount would hit the meridian to decide whether to flip. That isn’t what you are after, based on your description. Instead, you should not set any delay in SGP and set APCC’s meridian limits for 40 minutes after the meridian for a fail-safe if something goes awry. And, as you say, uncheck “wait for meridian.” With those settings you will generally be shooting or finishing up an image as the mount tracks across the meridian, then SGP will initiate a flip after the completion of that image but before it starts another one.
As I mentioned, this is exactly what I do. It is simple and reliable.
Dang. I tried to set Minutes Past Meridian to Flip to -15, and got a message that my mount doesn’t allow flips before the meridian. Paramount MX+ using the ASCOM driver (which I think is required by SGP). I don’t know if this is determined by the ASCOM driver, the mount, or TheSkyX, but I don’t see any way around it. It looks like I’m stuck with losing the imaging time.
the 2nd paragraph of my reply describes (again) how i have it set up right now, not what i am proposing to change.
the 3rd paragraph is my restating of what you have told me,
by “flip at the meridian” i mean to not set any delay at all in SGP (flip at the true meridian)
the reason i had “wait for meridian” checked in the first place is that i was always under the impression that SGP might try to initiate a flip before the meridian if it was unchecked. i was working off the idea that some mounts can be explicitly commanded to do a meridian flip at any time, while with an AP mount the only way that happens is if you do a slew to the target with counterweights up. if SGP tried to flip before the meridian, no flip would happen, and a pier crash could eventually occur. i set all this up before APCC existed; now i think there’s not as much danger if SGP fails to flip (but there is still some danger as i mentioned above).
that’s what i was referring to above. IIRC there’s an ASCOM property called SideOfPier. if it’s read-only, then SGP can’t flip before the meridian. if it’s writable by a client app then SGP can flip before the meridian. sounds like both bisque and AP export this property as read-only, so no early flips. i suspect with all the extra logic in APCC that it might now be “safe” for AP to allow this property to be written, but not sure.
my understanding is that the ‘safe in this pointing state’ timers that chris proposed would put all this to bed, but i’m not sure if anyone in the ascom-dev group is actually working on that.
Yes, that all sounds good. Set your time to flip at 0 and “worst case” you start an image right before that…in which case you’ll flip somewhere around 30 minutes past the meridian (assuming 30 minute exposures)
This is determined by the ASCOM driver returning true for CanSetSideOfPier. If we cannot set the side of pier then we have to wait until we track past the meridian and then issue a slew.
Just so I understand, what’s the advantage to most folks of setting Minutes Past Meridian to Flip to a positive value? If SGP interpreted +21 to mean “flip the first time an exposure ends after the meridian, and don’t start an exposure that will run past +21,” that would also solve my problem. But according to Rule 1 above, SGP will never flip before +21 in this case, right?
BTW, I posted on the Bisque forum about this, mostly to see if there was some possibility of getting the ASCOM driver modified. The initial feedback there seemed to be that other automation software doesn’t face this issue, but I’m not sure everyone correctly understood my description of the issue. (And I’m quite sure that I don’t follow all the explanations!) Anyway, no one has volunteered to rewrite the driver yet.
The reason that people set a small positive value for the minutes past meridian is to allow the mount sufficient time that it really has tracked past the meridian when the meridian flip slew command is issued. Without this it’s possible that although the meridian has been reached the mount is still in a state where it thinks it hasn’t tracked past the meridian and the slew doesn’t change the pointing state.
All that happens to do the flip is that a slew command is sent to the mount. SGP then checks that the pointing state has changed and if tit hasn’t fails. You then see this, do a slew manually a minute or two later and it works because by then the mount is sufficiently past the meridian.
This is partly down to how SGP implements the flip. If it were to note that the slew had failed to change pointing state and try again a little later - possibly after another image had been collected - then the mount would have had time to track past the meridian and the next try would work. This would eliminate a vast number of support queries.
so just a followup, i unticked ‘wait for meridian’ and set the meridian delay to 5 minutes just to be safe as chris mentions above. the first night, for some reason APCC crashed and the flip never happened (i don’t think this was related at all, and the deadman’s timer in the mount firmware worked flawlessly.)
the 2nd night everything went well.
maybe the “wait for meridian” checkbox should be called “never pass meridian while imaging” or something like that. while i’m sure if i RTFM’d i hope i would have understood what it did, i completely misunderstood what it was for.
If APCC “crashed” I would love to see the log file to determine what happened. Please email it to groups3 AT gralak dot com along with the time that you believe it crashed.
A lock-up is not necessarily the same as a crash. A lock-up could have just been a popup modal dialog in back of the main window. Or, it could have been a serial port driver crash. The APCC log zipper utility will grab all the logs, but I just need an estimated time to know where I should start looking in the logs.
seems like it was a hard lockup, the APCC log file just ends right around the time that SGP says it lost contact with the mount:
[10/21/17 02:09:06.812][DEBUG] [CP Update Thread] ASCOM Telescope: Error in GetCurrentPos : Lost communications with mount. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: Lost communications with mount.
this machine is definitely underpowered and has fallen over by itself before. anyway i will send you the log. maybe there are some windows logfiles that might say something about what happened?
i don’t know if this is related to unticking “wait for meridian” or not but i just hit what is maybe a corner case - i started up on a target very close to transit. when SGP started centering and focusing, it was just before the (slightly delayed) meridian in SGP. when everything finished, the target was about 7 minutes past SGP’s meridian, per the display at the bottom of the window. SGP started the exposure without flipping; this turns out to be right on the hairy edge of the ‘stop tracking’ limit in APCC and more than likely it’s going to hit the limit before SGP tries to flip. i have temporarily set APCC to ‘just warn’ but if this situation occurred in the middle of the night, the imaging session would be over…
yes - it was still running when i woke up in the morning, unresponsive. am running FTDI usb/serial converters as the stick PC only has usb ports. is there logging of segfaults in drivers in any windows logs?
I don’t know, but given what you said was the last line of the log, APCC was querying for Sidereal and there was no response. That’s a command that APCC often sends to the mount so I doubt there is a software bug thereotherwise many people would be seeing this. I’m guessing that maybe the serial port driver or the USB bus had an issue
