G11 Gemini Meridian Flip Failure

My mount consistently fails meridian flip. At first, I thought it was problems with ASCOM and Gemini, but now I get the ASCOM settings from Gemini for sure. It has worked.

My settings are:
SGP_flip%20settings


An excerpt from the log file:
Meridian Flip failure log.txt (84.6 KB)

All advice is appreciated.

Regards,

Charlie

1 Like

@cfbradshaw9373

We will need logs to help. The section you posted does not show a flip… plus we need information from many parts of the log to diagnose.

OK! Attached! The log showed the last east value before I hit the limit. After this, I parked and did a manual flip.

sg_logfile_20190922141744.txt (1.65 KB)

@cfbradshaw9373 Unfortunately, that log file does not have an attempted meridian flip in it.

That’s because it did not do it and hit the limit. I don’t know why the flip did not occur. It should have happened at about 5 degrees. There’s got to be a parameter off, but I’ve not found it.

@cbradshaw

I should have been more descriptive. The log file you sent literally has 8 log lines in it.

According to PEMPRO, the ASCOM driver should not have the J2000 checked. Perhaps that is the cause. Next time out, I will try that.

Regards,

Charlie

I’m not sure what you mean by that

In the Gemini ASCOM settings images I posted, the advanced Gemini setting have a check in the box for “Gemini expects J2000 coordinates”. Perhaps this is not correct. I don’t know, but it’s the only thing I can think of that would change the apparent position of the mount.

One other change is to reduce the time past meridian from 20 minutes, which should be fine for my limits of 110 degrees.

Could be, but SGPro can talk to a mount accurately whether it is J2000 or JNow. You are intentionally asking SGPro to wait a full 20 minutes after your mount passes the meridian?

It’s only 5 degrees. My limit is at 110, which is 20 degrees past meridian, Have I calculated wrong?

No… just making sure it was intentional.

I guess I will experiment next Friday. I know it should work.

Thanks!

Charlie

I sent the wrong log file. This file was after I manually aborted the sequence and had the mount park recenter on the target. I will send the correct log file tomorrow after work.

Here is the log I should have sent

(Attachment sg_logfile_20190921195854.txt is missing)

Unfortunately, the log is too big. Do you have a dropbox?

You need to have your own dropbox, upload your file there and provide a link. It’s simple and free.

Peter

I’ve not used this before. Hopefully, it works!

@cfbradshaw9373

Yes, that worked fine. Lots of stuff going on in that run. Essentially, you lost the guide star, just minutes before the flip would have occurred. SGPro attempts to recover… it is successful recovering the guide star, but fails to recenter itself on the target. The mount refuses to move to the target position because it indicates that request would cause it to slew outside of its safety limits:

[09/22/19 02:12:50.066][DEBUG] [Telescope Thread] ASCOM Telescope: Error in Slew : CheckDotNetExceptions ASCOM.GeminiTelescope.Telescope SlewToCoordinates System.Exception: Slew to outside of safety limits (See Inner Exception for details) (System.Exception: Slew to outside of safety limits)

So… it’s not the SGPro missed your request to flip… your sequence just quit right before that would have happened.

Thanks! That was my take as well, but I did not catch the ASCOM error in the thread. Apparently, the clouds came in at just the wrong time.