#1 - Also make sure you’re using “Dialog Based” User interface in EQMOD under ‘User Interface’
#2 - Manual Rotator is in SGP click the down arrow under mount connection in sequencer.
It seems as though you are trying to use a pointing model of sorts (based on how you indicate you perform startup). SGPro does not really play well with models because when we tell your mount where it’s pointing it modifies that value based on its own internal model. Here is a guide that EQMOD users have reported as a SGPro compatible setup. I’m unsure if it needs updating:
http://www.mainsequencesoftware.com/Content/SGPHelp/UsingEQMODwithSGPro.html
Thanks for that but I do not use EQMOD just synscan from Skywatcher, but I will try to setup in ascom synscan
@Dpatt. In an earlier response you seemed to imply you were building some sort of pointing model? What are you using to do that?
I’m just trying to do an alignment to help the software know my exact location to help with locating the target I wish to photograph. I did this with APT and pointcraft. It worked great. Not so with SGP. Should i not do this? Should I just use framing and mosaic without doing an alignment? But does this explain why the position error gets greater rather than closer to the target? I can only sometimes get to the target within 400 pixels
If by “the software”, you mean SGPro, this is unnecessary as SGPro only uses the last sync. Aside from that, it looks like there is an issue with the DEC axis. You are asking to go to -25.289 deg (J2000), SGPro, converts it to JNow and asks you mount to go there. Your mount appears that it might have given the Dec a little bump, but the next frame shows Dec in the EXACT same place every time (never moves off of -24.772 deg). So… despite requests to move a place, the Dec axis is not budging. This means one of two things:
- There is enough slop on the Dec gears that 3 attempts to move the Dec was not enough to engage the gear. More attempts would wind this out.
- There is a miscommunication in epoch. Your mount tells SGPro that it uses JNow and SGPro reads and sends to it using JNow. If there was an issue where it is interpreting what SGPro sent it as J2000, it may think that it’s already where it needs to be and just do nothing.
Have you made sure that your mount’s ASCOM drivers are up to date? Does the ASCOM driver let you switch epoch from JNow to J2000?
Thanks for your reply I will check everything you have suggested. I have a few days off from tomorrow to have a play with the settings. I let you know how I get on
I must admit I am very interested in this thread as is exactly the issues is have with AZEQ6 and same software setup. I get 2 symptoms, failed PS 2 or repeated solves with ineffective bumps, usually in DEC with dec around 150 pixels out and RA in 10-20. Tolerance is 50 px. Dec is given bump but will move 5-10 px up or down. I was starting to think about unbalancing mount in case backlash was being problematic. I must admit I have never played with PS settings because I don’t understand them. Nor do I recall my dialogue settings so will test that. I’ll start logging now if there are others with similar issues. I’ve always assumed it was “user error” but there are a few things in here I’d like to try.
1 Like
Hi. I’m not the only one with this or a very similar issue. Let me know how you are getting on with the settings. I’ve been using another program called APT and have no problems with plate solve and it uses the very same Plate Solve 2 program on the computer. I do like the SGP program with the framing and mosaic wizard. I hope to solve this little problem.
Hi Dpatt,
I have exactly the same problem. It all started with the actual version. And I don’t have a solution to that.
Can you clarify this? You started seeing this with what change?
@Dpatt @DavidS @chriseq6
The fastest way to a diagnosis of the issue here is to cross reference SGPro’s logs with the mount’s logs at the time the DEC command is issued…
I have this problem @DavidS describes in nearly every session since 3.0.3.169 - never in a version before - could be coincidince or not. Very often, the first plate solve (e.g. for focussing) works, but not the folowing plate solve. I will try to find the EQMOD logs of the last night this happend and post it here.
I am wondering if you are having an issue that some see with PlateSolve2 where the first solve will work, but in the logs, any solve afterward will say something to the effect of “APM file found, but could not be opened”. Let me know if you have any logs showing this behavior and I can take a look.
Sometimes plate solve just does strange things. I always notice that after I get that first solve that all the other ones happen fast.
I do however have trouble sometimes if I try to solve through a SII filter. I’ve learned that the LUM filter is the best one to use when Plate solving.
On the occasional time when it just gets locked up or sits there forever trying to solve I just park the scope and do a restart on SGP and that almost always solves the problem. Pun intended!
I am wondering if you are having an issue that some see with PlateSolve2 where the first solve will work, but in the logs, any solve afterward will say something to the effect of “APM file found, but could not be opened”. Let me know if you have any logs showing this behavior and I can take a look.
Thanks, Ken, unfortunately last session was more than 2 weeks ago. I just learned about the 2 weeks limit of the logs…
Hi,
Did this get resolved?
I am having the same issues with the same conditions,
eqmod,sgpro,ps2
working fine on east side ,
never working on west side
No - i still have the issue. What i find is that it does 3-4 platesolves with ineffective pulses and then number 5 or there abouts the pulse is effective and it gets within my 50px tolerance so i never bothered with it further.
I’ll snapshot the logs as suggested by Ken in Oct ‘19. Might take me a little.