Any solution for this error after plate solve? Can´t center

I’ve had this problem for a long time, but since it goes into recovery mode twice and then resolves, I haven’t given it much importance, but I’m a little tired.
The issue is that after doing plate solve and centering it takes almost 20 minutes to solve and continue with the sequence.
I have set an error of 130" for a distance of 420mm, I don’t know if the EQmod has anything to do with it, but the SGP instructions regarding the meridian change are fine. I have a 15 minute delay margin to do the plate solve so that The object can focus well, but no idea please?

Thank you

https://www.dropbox.com/scl/fi/7yayu0uzb35sasnjvfhvz/sg_logfile_20240928203719.log?rlkey=axcaiffd2kt7r839ukbcnnnn0&st=3pwdsued&dl=0

The error begins at 23:55.

I am seeing different posts from a few years ago seeing the same problems with EQMOD, I don’t know if there is a magic key, for now I will try putting the telescope option in Offset, now it is in SYNC, as I have read, the same thing happens to me, The mount does not move to correct, and after 4 global attempts out of 10 centering attempts it self-centers and follows the sequence, but I have to wait 20 minutes without the mount moving, I don’t remember this always happening.
If someone with EQMOD has had the solution, I appreciate it.

No solution with Offset mode…

I took a look through your logs and the issue seems to be that SGPro needs to recover because the mount has mysteriously stopped tracking (or at least the drivers tells SGPro this). SGPro does actually detect an attempt to center with the mount parked or not tracking and will automatically correct the issue. In this case, it does check at 23:53:00.084 and the mount reports everything is ok. Then… just 2 minutes later, during the centering run at 23:55:16.347, we see the mount is reporting that it is no longer tracking (I assume you would have noticed if the mount parked so ruling out parking as the issue). There is nothing in the logs showing any kind of mount command from SGPro during those 2 minutes.

[09/28/24 23:53:00.084][DEBUG][Sequence Thread][SQ;] Mount startup good, reports not parked and tracking...
[09/28/24 23:55:16.347][DEBUG][Telescope Thread][SQ;CE;] ASCOM Telescope: Error in Slew : SlewToCoordinates()  is not permitted while mount is parked or parking.
[09/28/24 23:55:45.768][DEBUG][Telescope Thread][SQ;CE;] Telescope: Sync Slewing to RA/Dec request, but mount is not tracking (and mount not at park), starting...

So… it seems like maybe something external to SGPro is disabling the mount… maybe the driver itself? Maybe some safety limits. I am not sure. SGPro can recover from this, but, as you noted, it takes time to do so.

One thing you might want to do is also capture ASCOM trace logs for the mount and then we would be able to see all commands to the mounts (not just from SGPro) during that 2 minute period. It is highly likely that EQMod has its own logs as well. Guidance on ASCOM trace logs is here:

https://help.sequencegeneratorpro.com/HowtoGenerateASCOMTraceLogs.html

Hi Ken, thanks as always for your interest.
I also noticed that it said the mount was parked or untracked, but in no case was it parked or untracked. I was able to notice that. The issue of security limits, I am bold, but they are completely disabled in Eqmod, it is a good idea to be able to have the ASCOM logs, it is a good idea…
I’ll see if I have it activated and as soon as I have them I’ll send them to you.
Thank you very much Ken, let’s see if we can solve this problem.

Hello Ken, until today we have not had good weather here in Spain these weeks. I have finally been able to create the Eq6 log, through ascom, as you said, I will show it to you to see if we can find out what the problem is. It starts around 00:33. I attach the log of the SGP session and the log of Eq6. I appreciate your time, let’s see if we can solve this problem. Thank you!

https://www.dropbox.com/scl/fo/fyqjn4d2c3vua7b2h80io/AOJfhpukgtvCXvYq4bsZtGQ?rlkey=cedavvte0raku31qv1o10nzjv&st=yyny4o1y&dl=0

So the issue in these logs is decidedly different from the original issue posted. I do not detect any spontaneous disconnects or parking in these latest logs. The issue I see is that EQMOD is configured to reject location syncing and you have SGPro configured to use location syncing.

The only reason to disable this in EQMOD is if you are actively maintaining your own pointing model. Most people do not and this functionality should be enabled. If this is intentional, you must update the sync method in your sequence / profiles to use the offset option.

image

Further guidance here:
https://help.sequencegeneratorpro.com/UsingEQMODwithSGPro.html

And here:
Telescopes / Mounts

Hi Ken, for some reason if I put Offset, the sequence is canceled when it is time to change the meridian. “Failed to complete automatic meridian flip, aborting sequence” I would tell you that this problem appeared suddenly, without touching anything in Eqmod, and I already tried changing to offset, but it didn’t work.
I don’t know what else to try, I’ll look at the EQmod options that you recommend, but everything is the same as it is in your documentation.

Are you in need of using “offset”? In other words, are you maintaining your own model in EQMOD. Using the offset option is much more difficult than sync and places the burden of sync directly with you and out of the hands of SGPro. Are you 100% certain in the accuracy of the model you are using? If not, I highly recommend allowing SGPro to sync the mount and letting it do its thing.

I used offset to see if my problem was solved. My original problem is having this option in Sync. Of course I don’t need to have offset on, but I’m just trying to test with any change. Offset is not a correct option. Setting Sync is the correct one, but the synchronization takes effect after many attempts. And only when centering after a meridian change.

I think it is possible to allow sync AND still have EQMOD still modify your location with its own offset and you’ll want to ensure that this is not happening. Unfortunately, I have no direct experience with EQMOD and cannot be of much help there. EQMOD is difficult to use and is why it is literally the only mount for which we have created specific instructions:

https://help.sequencegeneratorpro.com/UsingEQMODwithSGPro.html

If this has been followed and the issue still persists, maybe somebody else using EQMOD has had a similar experience and can help.

I can help with the visibility for something like that.

I’m sure it’s nonsense, but it all seems very strange to me after years of it working well, and one day without warning, it makes these errors. All the steps are as you mention.
I appreciate your help, I hope I can have the help of some colleague here, Let’s see if someone is encouraged.
Ken always grateful

1 Like

Well I’ll update you. I have written in the Eqmod forum, and after several recommendations none of them work, I have carried out dozens of tests with the synchronization, reference points, deleting them, leaving them on, various options, and there is no way, only after a few minutes is when it focuses . I can’t find the solution to this problem, and another thing I haven’t said is that it happens to me on both computers. So if anyone with Eqmod is kind enough to give me some more advice, I would appreciate it. I feel helpless after many years as an astrophotographer and user of both platforms, I can’t find the solution.

SGP and EQMOD work fine for me in doing automated meridian flips. Platesolving would seem to be rather independent of EQMOD, but perhaps there is a relation. I have read many years ago on an EQMOD forum that EQMOD does not “like” many sync points close together in its pointing model. Thus I always set SGP to Offset instead of Sync for the Telescope Sync Behavior. Then also set EQMOD to Dialog for not automatically updating the pointing model. Either way, when Platesolving EQMOD does not even need a pointing model.

Platesolver I use is ASTAP. ASTAP communicates with SGP, and SGP communicates with the mount (so with EQMOD in this case). Not being able to solve is usually caused by either the wrong time on the imaging computer, a wrong user profile (i.e. location) in SGP or a wrong plate scale set for the camera in SGP. When those things are all set correctly and the platesolve image is both in focus and not showing mount movement (elongated stars), then ASTAP should always be able to correctly solve the image. Unless clouds are drifting in…

My SGP settings for platesolving are to always use a Luminance filter and take 5 second exposures. It would be great if SGP could stop guiding during platesolve (same as it can stop guiding during autofocus), but with 5s exposures guiding is usually not a problem for solving.

@Ken can we have an option to stop guiding during platesolve?

Hello Ventania,
I appreciate your response. Eqmod and SGP with the meridian flip are perfect for me, I have no problems, also if I start a sequence it goes directly to the object, it centers it the second time. So I understand that the synchronization is good, it is just centering after meridian flip.
The timetable issue is a very good idea, and I have already seen that there is a time lag of a few hours, so I have downloaded software to have it updated every 10 minutes. The other cases you present are fine, no clouds and well configured resolution.
With the configuration you recommend in Sgp “OFFSET” and dialog in EQmod, I seem to remember that I have already tried it, but I will try it again removing all the saved points. I hope these tips work. I have you informed…

The only relation is that plate solvers that require a hint will use the mount’s current location (which, of course, is often the result of a previous solve). If that initial solve and sync fails (which it was in the attached logs) then subsequent solves will also fail (unless blind).

Just a reminder that, when using OFFSET, you are relying on EQMODs internal model and SGPro will never attempt to inform the telescope of where it is pointing.

Thanks Ken, putting it in OFFSET doesn’t really give a good feeling.
When synchronizing the time, it seems to keep failing, but it doesn’t take that long, I’ll try to auto-synchronize every 1 minute. It may be the solution…
Thanks to both of you.