I believe you’re referring to another user? Ken hasn’t posted in this thread. Yes, we’re currently looking into this. Just trying to wade through all the logs and data. There are lots of variables at play here.
Thanks,
Jared
So on the surface I think I have a pretty good idea why this is happening. In one of the 2.6 releases (maybe the first). We removed the solve and sync prior to a meridian flip. The thought being that we could “trust” the location as returned from the telescope, because we likely told it where to go in the first place. I’m guessing this was a false assumption.
So I’ll be adding back in the solve prior to the meridian flip (when using Auto Center post flip) but we’ll skip the sync pre-flip.
Thanks,
Jared
1 Like
Sorry, it is wrong log.
Here is the mentioned one:
Thanks for looking into this @Jared! I’ll definitely download the update with the fix when it’s available. Now all I need are these darn clouds to go away…
Thanks for the help!
Ya… probably a bad example. I was in no way implying that this was caused by other software only that changes in other software can sometimes have rippling effects through SGPro and we had no data to point one way or the other.
Not a problem Ken and glad to see that you and Jared are on it. Ripple effects are one of the things I’m always concerned with in dealing with a new piece of software and how it might jam up the works. It was just a coincidence that MountWizzard and your update were installed by me on the same day. Not having experience with MW, I thought it was the culprit.
My thanks to AllABoutRefractors for starting this topic.
Has anyone tried the 2.6.0.18 release yet to see if it fixed the centering problem after the flip ???
thanks.
Jared,
Instead of getting the coordinates from a plate solve (and for sure not from the mount!), you could just use the target coordinates. After all, the flip sequence is almost identical to the initial slew and center to the target coordinates.
Regards,
Horia
@Dennis1951, I’m hoping to try this weekend. The weather claims we’ll get our first break in the clouds here in weeks…
AIUI one way of starting a sequence is by using the current position rather than having a target position. In that case there wouldn’t be a target position to use. That’s why a solve is needed before the meridian flip, it’s the only way to be certain that there is a position to be used after the flip.
Chris,
I do not follow this.
By target I mean the object I want to imagine and I assume that the coordinates of the center of the target are known a priori.
I would expect that simply issuing a “slew to coordinates” command, where the coordinates are those of the target, would bring the scope on the appropriate side of the meridian and reasonably close to the right position. Not only I do not understand the need to find out where exactly the scope is pointing before the flip and the use of that information but, given that the system was happily taking pictures, the assumption that, before the slew, the scope was pointing at the target seems reasonable anyway. After the slew, a very the simple centering loop (measure / correct) would do the rest.
All of this under the assumption that the mount is not completely lost but then we have another problem to solve.
Regards,
Horia
IMO it’s just because a novice user might center a target manually, but with no sync ever performed the mount might not think it’s pointing to that target. so if they just asked the mount where it was, then the pointing would be off on the other side of the meridian. by first solving the current pointing there’s no ambiguity whatsoever.
as you get going with SGP eventually you’re just going to input the coordinates of what you want to image and rely on SGP to center it. if everyone used SGP that way there’d be no need to solve before a meridian flip; i assume then this is just to support the use case of someone manually pointing to their target and not understanding that they should sync somewhere along the line.
LOL, me too !!
Exactly!
Maybe you set the coordinates in SGP and decided you didn’t like the framing and manually adjusted it. Or maybe you didn’t even bother setting a target and just slewed to an object manually and started a sequence. Unfortunately we don’t know why you’re at the location you’re currently at, just that we need to get you back to that location. The position as indicated by the telescope cannot be trusted (I think we accidentally proved this 
) So we have to get the position ourselves.
This is only the case if you’re using the Auto Center option for meridian flips. Just FYI.
Thanks,
Jared
any Luck ??? I am still using 2.5.1.17 and it centers just fine !!!
Nothing yet…I have had nothing but terrible weather for weeks. They are threatening some clear skies on Thursday, but I’m not holding my breath…I’ve got the new version loaded and ready to go. Now I just need some stars to image!
I have used the 2.5.1.17 versions several times now over the past few weeks and the merdian flip has worked perfectly every time. So tonight, hopefully, I am going to try the latest beta and see what happens…WISH ME LUCK !!! 
1 Like
@Jared, I’m sad to report I don’t think the 2.6.0.20 update fixed the issue. I recently did get out and was able to try the new update, but the problem persists. Unfortunately, in going to look for the log file (it’s been over a week ago that I ran this sequence), it appears my log file is no longer available. It seems to have been deleted (not sure if SGPro deletes log files automatically or not). Anyway, I don’t have that to post here, which may not be very helpful, but the behavior is the same as it was in the previous iterations. The flip reported that it was successful, but it was off in both RA and DEC (see attached pics. These have been overlaid so they line up with one another. You can see the offset from the preflip file (frame 10 - randomly chosen) to the post-flip file (frame 58 - randomly chosen)…please ignore the terrible subs - the data from the night was not very good). I’m hoping to have another shot this upcoming Friday - not sure what would be more helpful: a) running another sequence with the beta version in order to post the log file or b) rolling back to 2.5.1.17. I’m guessing the former, given that there seems to be a consensus that 2.5.1.17 is successful.
Thank you, again, for looking into this. Please let me know what else I can provide to help you debug this!
SGPro 2.6.0.20 now solves prior to the flip and then, on the other side of the mount, it will get you back to that position (within the tolerance you set). Because of this we cannot really assist without a better understanding of what happened (logs).