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
