Plate solving has been working well for me for a while, both with the local astrometry.net and the online version. In the last week though, with both this version of SGP and the last, it seems totally lost. It solves the reference image, then takes a pic to see where it is now, and solves that. It then starts slewing to an area of the sky nowhere near the target. It does this whether I use the “center now” button, or if I right click the reference image and select “center here”. I am using my own image taken with SGP as a reference image, and it has the RA and DEC in the FITS header. The proper pixel scale is set in SGP (.376). I start a week of holidays tomorrow, and hope to use it imaging as much as possible. I have spent hours the last few nights trying to figure this out with no luck. Here are the log files.Dropbox - Error
While I am not ruling out bugs, none of the “Center Now” code has changed in a long time. Typically when you see wild slews like this it deals with mount settings… like the mount thinks it’s in the wrong hemisphere or sync issues where the mount is pointing to the correct location, but the software thinks it is on the wrong side of the pier.
I will try and take a look through the logs in the next week or so (I am also on vacation).
The scope seems to slew accurately when I use CdC to control it. So I did a 3 star alignment and then used CdC to slew to NGC 688. It missed slightly and was not in the small field of view of the Edge 9.25 at f10, so I tried to use the plate solver to finish the job. And again, it took off wildly cross country, even though it is almost right on target. Mount settings haven’t changed. Have a good holiday! I for one know you have earned it.
If you are indicating that you were already close to your target prior to invoking auto center, SGPro does not think so:
[8/7/2015 12:14:05 AM] [DEBUG] [Telescope Thread] Telescope: Syncing to J2000 RA: 14.128806264 Dec: 88.1140657503
[8/7/2015 12:14:05 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Error in Sync : SyncToCoordinates() RaDec slew is not allowed while scope is not Tracking. (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: SyncToCoordinates() RaDec slew is not allowed while scope is not Tracking.
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object args, Boolean byrefModifiers, Int32 culture, String namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object providedArgs, ParameterModifier modifiers, CultureInfo culture, String namedParams)
at System.Type.InvokeMember(String name, BindingFlags invokeAttr, Binder binder, Object target, Object args, CultureInfo culture)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 443)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type parameterTypes, Object parms) in c:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 483
at ASCOM.DriverAccess.Telescope.SyncToCoordinates(Double RightAscension, Double Declination) in c:\ASCOM Build\Export\ASCOM.DriverAccess\Telescope.cs:line 1126
at ag.Sync(Double ra, Double dec)
[8/7/2015 12:14:05 AM] [DEBUG] [Telescope Thread] Attempting to write fits header info for
[8/7/2015 12:14:06 AM] [DEBUG] [Telescope Thread] Performing auto center step 3 (scope)…
[8/7/2015 12:14:06 AM] [DEBUG] [Telescope Thread] Auto center slewing scope to match reference…
[8/7/2015 12:14:06 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to J2000 RA: 20.2008333333333 Dec: 38.3169444444444
[8/7/2015 12:14:06 AM] [DEBUG] [Telescope Thread] Telescope: Slewing to RA: 20.2008333333333 Dec: 38.3169444444444
SGPro thinks that your scope was pointing at RA: 14.128806264 Dec: 88.1140657503. Unfortunately, as you can see above, it was unable to tell your scope that during the failed sync operation (says scope is not tracking). Then, we continue on (trusting that your scope knows what it is doing) attempting to slew to RA: 20.2008333333333 Dec: 38.3169444444444… quite a distance from your current position solve.
I’m not sure if I follow what exactly you think the problem is. Sorry to be thick…where do you feel the communication breakdown occurs that causes this problem? And what could be responsible for this? I am just lost trying to figure this one out, and am finding out this week just how addicted I have gotten to plate solving my way to the targets. Strange that this problem arose when I have made no changes to any hardware or software that I can think of. I have been doing wide field Milky Way imaging this weeks so far, but hope to use the Edge HD on M16 over a few nights this week when the weather clears, and could sure use the plate solver for that.
I am not really sure. You sent about 8 logs over so I took my best guess as to which one illustrated the problem. In that log your scope reported you at RA: 14.128806264 Dec: 88.1140657503, failed to sync, then moved on to slewing to RA: 20.2008333333333 Dec: 38.3169444444444. In your original post, you reported that the scope was close to that target. So, in the log I looked at:
Your scope reported it was actually not close to the target
Your scope failed to sync because it was not tracking
This likely means that your scope might not be reporting where it is really pointing and SGPro cannot sync it to make sure we know where it is before sending it off to the intended target.
Many problems are target dependent… especially with solving.
On some of the plate solve attempts I was very close to the target, but on others I was at the park position (though unparked), or at another target. So I am not sure either which one you were looking at. So the scope may have reported that it was not close to the target.
You write above: “Your scope failed to sync because it was not tracking”
Now we might be getting somewhere. WHEN does it say that the scope was not tracking? When I took the plate solve image? Before? I HAVE had the scope seems to stop tracking a few times lately for no good reason. But I do look at all the plate solve images as they come in, and with no tracking with my Edge 9.25 for a 10 second plate solve exposure, I have lines instead of stars. So I think it must have been tracking when I actually took the images to plate solve the scope’s current position. Although I do recall rejecting the occasional plate solve image lately because it was not tracking and gave me lines instead of stars, so I got it tracking again and then retook the plate solve image. I wonder if that is what you are seeing in the logs?
But bottom line is that no matter where the scope is pointing, near the target or from the home position, it takes an image and solves it okay. But it then takes off in the wrong direction for the target until I abort the slew. Whereas before this problem began, I could start with the scope at any point in the sky and it would have no problem solving where it was and going to the target precisely.
[8/7/2015 12:14:05 AM] [DEBUG] [Telescope Thread] ASCOM Telescope: Error in Sync : SyncToCoordinates() RaDec slew is not allowed while scope is not Tracking.
This is directly AFTER “step 2” of the centering process.
It does not matter of the solve is successful if we cannot communicate the position to your mount. Some mounts don’t accept syncs so SGPro makes an assumption that if your mount rejects this, you have other plans. That said, I think it is pretty safe to add code that prevents the slew if the sync fails for this specific reason. Also… even with a valid sync, if the mount thinks it’s on the wrong side of the pier, you will also see this type of behavior. Before running center… to test with no danger, I would just run “Solve and Sync” in SGPro. After this is done, go to the scope tab in the CP and check to make sure the mount is reporting the exact location the solve just reported…
I’ll try that at the first opportunity, hopefully within a day or two. Just curious…if the scope didn’t know what side of the pier it was on, wouldn’t it have trouble going back to the park position? The scope goes where it should when controlled using CdC for go tos, or when using the ASCOM interface window to park it. So at least as far as those programs go, the scope still seems to know where it is.
It may be better to check the CanSync ASCOM property to decide if sync is available. That will return false if sync is not available. It’s likely to be more reliable than relying on every driver implementer throwing the exception that you expect.
Incidentally if the mount isn’t tracking imaging isn’t going to be successful so it won’t matter if sync works or not.
Thanks Chris. As of the first beta of 2.4.2, this is exactly what SGPro does. I am proposing, that if can sync is true and it still fails that we terminate the sequence for safety reasons.
