Having had a chance to look at the log (attached in previous post), the relevant section states:
[21/12/2016 23:36:40] [DEBUG] [Pier Flip Thread] Meridian Flip: Starting Meridian Flip Procedure
[21/12/2016 23:36:41] [DEBUG] [Pier Flip Thread] Meridian Flip: Stopping the Auto Guider
[21/12/2016 23:36:41] [DEBUG] [Pier Flip Thread] Meridian Flip: Sending Telescope command to execute meridian flip
[21/12/2016 23:36:41] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is West
[21/12/2016 23:36:41] [DEBUG] [Telescope Thread] ASCOM Telescope: attempting pier flip using sideOfPier
[21/12/2016 23:36:42] [DEBUG] [Telescope Thread] Setting Pier East
[21/12/2016 23:36:42] [DEBUG] [Telescope Thread] ASCOM Telescope: Waiting until pier side changes…
[21/12/2016 23:36:53] [DEBUG] [Telescope Thread] ASCOM Telescope: Side of pier changed, waiting for scope to report it’s done slewing…
[21/12/2016 23:37:11] [DEBUG] [Telescope Thread] ASCOM Telescope: Scope to reports it’s done slewing…
[21/12/2016 23:37:11] [DEBUG] [Telescope Thread] ASCOM Telescope: Settling scope 3 seconds…
[21/12/2016 23:37:14] [DEBUG] [Telescope Thread] ASCOM Telescope: Pier side is East
[21/12/2016 23:37:15] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope command to meridian flip has completed
[21/12/2016 23:37:15] [DEBUG] [Pier Flip Thread] Meridian Flip: Telescope has performed meridian flip
[21/12/2016 23:37:15] [DEBUG] [Pier Flip Thread] Meridian Flip: Flipping Auto Guider calibration data
[21/12/2016 23:37:15] [DEBUG] [Pier Flip Thread] Autoguider (Direct Mount Guider) successfully flipped calibration data
[21/12/2016 23:37:15] [DEBUG] [Pier Flip Thread] Meridian Flip: Performing Auto Center
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Center telescope message received…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Solving with Plate Solver Pinpoint…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Setting filter for auto center…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Setting filter position 1…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Setting filter: Lum…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Moving filter wheel, isMoving, check 1…
[21/12/2016 23:37:16] [DEBUG] [Telescope Thread] Moving filter wheel, isMoving, check 1 is complete…
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] Adjust focuser pos per filter: Moving focsuer to focus position (7741)…
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] Focuser moving to 4004
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] Focuser move call complete
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] Focuser position matches requested position (4004), continuing…
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] focuser move is complete…
[21/12/2016 23:37:18] [DEBUG] [Telescope Thread] Moving filter wheel, isMoving, check 2…
[21/12/2016 23:37:19] [DEBUG] [Telescope Thread] Moving filter wheel, isMoving, check 2 complete…
[21/12/2016 23:37:19] [DEBUG] [Telescope Thread] Performing auto center step 1…
[21/12/2016 23:37:19] [DEBUG] [Telescope Thread] Auto center exception No FITS image file is attached.
[21/12/2016 23:37:19] [DEBUG] [Pier Flip Thread] Something has gone wrong when centering after the meridian flip, but recovery mode is NOT active!
[21/12/2016 23:37:19] [DEBUG] [Pier Flip Thread] Adding sequence level notification: Something has gone wrong when centering after the meridian flip, but recovery mode is NOT active!
[21/12/2016 23:37:39] [DEBUG] [Pier Flip Thread] Meridian Flip: Procedure complete
[21/12/2016 23:37:45] [DEBUG] [Sequence Thread] Blocking Pier Flip: Failed to meridian flip, aborting sequence (False)
[21/12/2016 23:37:45] [DEBUG] [Sequence Thread] Adding sequence level notification: Failed to meridian flip, aborting sequence.
It appears something went wrong with the exposure for the auto-centre at 23:37, with no image attached (ccd is QSI683). I wonder if this is related to the refactoring of the auto centre process.
The sequence start with its auto centre executed correctly along with the Centre Here after I cancelled End of Sequence. The rest of the sequence carried on fine after I resumed the sequence.
As a separate note, I have stopped using Recovery with my 10 Micron mount as I no longer guide, however, if I had had Recovery enabled last night, would SGP attempted to auto centre again and if successful resumed the sequence (I never thought of this scenario when I stopped using Recovery, I was only thinking of the PHD2 interactions)?
it should reattempt - i have recovery mode active and last night i had 2 post-meridian flip failures and both were successfully recovered from.
the logfile is attached; i zipped it while SGP was still running (a little worried that it might get deleted if i quit SGP, i’ve never seen a log go missing before like what happened on the 1st night…)
Thanks Rob - I will switch recovery back on. Still something odd about the post meridian flip auto centre though. However it didn’t stop the evening’s sequence run though:
I see with your new 2.6.0.1 Beta release you made some changes to the “flip delay API calls”. Will this new functionality address the Pier Flip issue that AP mounts have that they cannot accept a negative value in the meridian delay as discussed in this thread: APCC and meridian flips - Feature Requests - Main Sequence Software ?
I checked with Ray Gralak on the AP GTO Yahoo Group to see if this was address in the latest release of APCC. However, he responded that “Sequence Generator Pro still lacks the needed API call(s) for APCC to pass a meridian delay, so no new functionality yet. If Ken and Jared add the API calls then it would be possible.”
I was just curious if this has been addressed in the 2.6.0.1 and the changes to the flip delay API.
i think ray just did not read the thread recently - what ken did was to implement the API for the very first time in 2.6.0.1 - this is not a change to the flip delay API call, it is the addition of a flip delay API call. ray should be able to write the app he was talking about now.
the negative delay thing is separate IMO. ken and jared would have to comment but my feeling is that it represents a very big change to the way the pier flip logic works.
I am also having the ‘going into Recovery mode after a flip issue’ with a Mesu 200, SGP 2.6.0.0 and PHD2 2.6.2. Could this be related to the interface with PHD2? I noticed when I ran my sequence tonight that SGP seemed unable to get PHD2 going. It started the program but did not seem to connect any of the devices.
This is a completely different issue (negative flip delay values for AP mounts) and will not be addressed by the availability of the new API calls.
We think we know what is going on here. All flips will go into recovery… if you want to use 2.6.0.1, make sure that you have recovery on (that will work fine right now).
I’m pretty sure that I have Recovery switched on. I assume you will be able to sort this issue. I quite like the other features (especially the ability to dither after ‘x’ frames), and would prefer not to have to roll back to a previous version.
After setting the meridian flip point through the API in v2.6.0.5, is there someplace that value should be reflected in the SGPro user interface? I am not sure where to look.
If so, I found that place earlier, but it always shows “0”, even after opening and closing it. (And that’s why I posted the question).
BTW, I can send the flip time (in integer minutes) in APCC and read it back from SGPro, so SGPro seems to retain the values I set. I just can’t find the value I set in the user interface. I am not running a sequence, so maybe that’s the problem?
@Ken. Nevermind, I found it. It’s the Control Panel, not the Equipment Profile Manager, which looks similar. The delay value is being updated correctly, so I just need to do a little more testing before I release a build of APCC with that feature.
And, thanks again for adding the flip delay API call.
What exactly does the APCC “Send Limit to SGPro” do, and how is SGPro supposed to react to it?
My OTA is on the east side pointing east, counterweights down slightly. I have East and West Limits checked in APCC as well as “Send Limit to SGPro”. APCC says there are 11 hours and 53 minutes till the mount hits the meridian limit. It has a Current Meridian Delay of 1.61 hours on the right side of APCC. Looking in the APCC log file, it sent SendMountMeridianDelay of 1.6 hours which matches the Meridian Delay time.
This is sending the Meridian Delay (1.61 hours) rather than the meridian limit (11h 53m) as the name “Send Limit to SGPro” and associated help message suggests. Is this correct?
SGPro’s Control Panel has a “Time to Meridian” of -00:51:53 11:43 PM. I do NOT have the “Use Auto Meridian Flip” set.
It is12:36 AM right now. Adding the negative 51:53 gives 11:43 pm so the math makes sense but why is there a negative 51:53 to the meridian? The scope looks like it has about 5 hours before it reaches the meridian.
I thought the “Send Limit to SGPro” checkbox in APCC was supposed to tell SGPro not to do a meridian flip until the meridian tracking limit was reached, in my case, in 11h 53m.
i have not been able to test this, but i believe all it’s supposed to do is keep APCC and SGP in sync with respect to where the meridian flip point should be (when the ota is on the west side of the pier). so if you have a meridian limit set in APCC for 2 hours past the real meridian, APCC is automatically telling SGP that the mount can track 2 hours past the meridian.
you’re on the east side which i don’t think is relevant to SGP. it’s when the OTA is on the west, that a meridian flip would be necessary.
btw if you’re on the east with the counterweights down, aren’t you pointed west?
at any rate, what SGP is looking for is a number of minutes past the meridian to track, so setting SGP to 11h53m would pretty much be a disaster for most mounts. the meridian delay in shown APCC must reflect the fact that your meridian limit for OTA on the west side is 1.6 hours past the true meridian. does that seem right?
The name of the new APPC checkbox (“Send Limit to SGPro”), the help message that appears when hovering over the box, and the fact that the box is on the “Meridian” limits tab in APCC imply to me exactly what you said - APCC should tell SGPro where the meridian limit is and hence when to perform a flip.
I spent several hours last night playing with APCC and SGPro, moving the mount in RA and DEC, turning east and west meridian limits on and off in APCC, checking and unchecking “Send Limit to SGPro”, and looking in the log file to see what caused APCC to send messages to SGPro. When I wrote my post the OTA was on the east side, but I had the same result on the west side - SGPro was not displaying the time the meridian limit would be reached, but instead was almost always displaying some negative time which I believe is where the EAST limit was, not the west limit.
Regarding your last paragraph, I don’t know if SGP is looking for a number of minutes past the meridian to track (for example, 120 minutes past the meridian), or if SGPro is looking for the time when it needs to do a flip, i.e., when the mount reaches the west limit as defined in APCC (for example, flip at 2:30 am). If it’s the former, then telling SGP 11h53m or anything above 6 hours would be a disaster, but if it’s the later then 11h53m (or more precisely, 11:53 pm) could be fine. In my testing above when the OTA was all the way on the east side pointing north, it could move for 11h 53m before it reached the west meridian limit, without hitting the pier.
If I understand correctly, when using the meridian limits in APCC, you do not manually set the meridian delay - it’s determined automatically. Instead, you define the meridian limits beforehand, and APCC then determines for the current DEC when the mount needs to flip. It displays it as “Time before limit reached: 02h 44m 02s”, not as an actual time.
This new feature is part of the reason I just bought SGPro, so I thank Ray and the SGPro team for making the changes.
SGP expects minutes past the meridian, since the wall clock time would change every night and you’d have to update it. the API for external programs to set the limit is very new - although a program could easily calculate flip times and set it via the API, for a human a time-based setting would be a nuisance.
you are right, APCC displays this stuff as a “time until”… however SGP does too: down in the lower status bar there is a clock counting down hours/minutes until the flip point is reached. but that displayed time is calculated; the setting in SGP is always a number of minutes past the meridian.
pre-APCC things were pretty simple; you’d (optionally) specify a meridian delay in the driver and tell SGP what the delay was and everything would just work… but of course the deal with APCC is that you can set limits which vary with declination and so the need arises for APCC to tell SGP where the flip point should be, as the delay is now variable depending on where the scope is pointed in declination.
Sorry for the delayed reply. I was out of town last week. I usually try to minimize information in a user interface so it won’t be confusing, but are there any enhancements you would like to see to APCC to make this feature easier to use or to provide more status information?
Hi ray, i am ashamed to say i have not been able to try it - my camera died a couple of weeks ago and i’m dead in the water.
i did want to ask though, i thought i read reports sometime back that one of the newer versions of APCC did not work well on low-end stick PCs. IIRC that was resolved but i wanted to check with you before upgrading as i am using an atom-based intel stick these days.
