2.6.0.0 meridian flip problem

Not opposed to it, but compared to other things we’re looking at it’s not super high on the list (mostly I suppose because this is not a feature that “most” SGPro users would need). If I’m wrong about that let me know… Ray has been the only one to express any interest at in in using that functionality.

i don’t know what the APCC adoption rate is, nor what other mounts allow in terms of these complex meridian limit ‘surfaces’. i can see a lot of people on the ap-gto mailing list seem to be using APCC though. for anyone whose mount/OTA/camera situation permits positive delays at every declination, i think it’s reasonable to just set your automation program to the smallest positive delay.

tomorrow night i’ll have to go back and see exactly where the meridian limit is for this target that failed - i never had a problem with the meridian flip in the past, but if the limit is right near the actual meridian then i guess the timing changes in 2.6.0.0’s meridian flip might be triggering this behavior.

anyway, i suppose SGP’s handling of this stuff could wait until those new pointing state timers are available in ASCOM. would the presence of the interface be enough to make this a higher priority? (meaning, it’s no longer a mount-specific feature if ASCOM is aware of where the meridian limits are)

rob

Hi Ken/Rob,

in the latest build of APCC Pro (1.5.0.18) there is now support for camera control and plate solving through SGPro, so I suspect going forward that there will be a good percentage choosing SGPro versus more expensive alternatives. I am still committed to allowing APCC’s meridian limits feature work with SGPro. I think I just need the appropriate ReST API call(s) to do this.

Best regards,

-Ray Gralak

Currently imaging and I too have had the auto centre after meridian flip fail, thus triggering an abort sequence, using beta 2.6.0.0.

I have cancelled end of sequence options, then selected centre on target, which completed fine, before then resuming the sequence.

My synch behaviour option is ‘synch’.

I will post logs tomorrow when the sequence completes (or later this evening).

thanks - i may have jumped to conclusions about what happened last night vs. what originally happened. unfortunately tonight i won’t be around to monitor what happens when it’s time for the meridian flip. i intend to make sure that the meridian limit is a few minutes greater than the meridian at my target’s declination just to eliminate the meridian limit as a possible cause.

@rgralak @pfile

I didn’t want to commit to anything before I investigated… but adding the API call was simplistic and is complete. Will be in the 2.6.0.1 beta as:

GET http://127.0.0.1:59590/flipdelay

{
  "Success": true,
  "Message": "Success",
  "DelayInMinutes": 15
}

POST http://127.0.0.1:59590/flipdelay

{
  "DelayInMinutes": 15
}
1 Like

Log file is here: here.

I flipped around 23.37. The mount flipped fine but the auto centre afterwards failed - appeared to take image fine but something went wrong. Centre on Target worked fine after aborting.

HTH

Barry

btw i just slewed to andromeda and it appears that there are 4 minutes between the meridian and the limit in APCC, that is, for this declination the mount will stop moving 4 minutes past the meridian. i think this should be more than enough time for the flip to initiate; it apparently was enough for the last 10 runs prior to the first one on 2.6.0.0.

what was different on the 2nd night of 2.6.0.0 was that i had set my SGP meridian delay to 30 minutes by accident and so APCC stopped the mount before SGP attempted a flip. just now i made sure that the SGP delay is set to 0 minutes.

thanks for implementing the API for the meridian delay! this will help prevent accidentally causing this problem again.

rob

ok i am back and i can see that the meridian flip did fail. after auto center step 1 the exception was thrown: “Auto center exception Error solving with PlateSolve2: The path is not of a legal form.”

however then recovery mode kicked in, the new auto-center succeeded, and the sequence continued.

rob

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)?

Many thanks

Barry

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…)

rob

https://goo.gl/qYo4tO

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:

Hello Ken/Jared.

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.

Thanks for the info.

Andrew J

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.

rob

Hi

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.

Sure, we’ll get it done… beta life.

Thanks Ken (& Jared) - have a good Christams break.

Recovery now activated in the faint hope that I’ll have some clear skies!

Ken/Jared,

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.

Thanks in advance,

-Ray