Background:
My Elbrus solver has been failing for a while but the local astrometry.net failover works so well that I have been ignoring the failures. I decided to fix it this morning and ran into the reported crash. Since I am not currently hooked up to the camera and mount (and it’s daylight out there…) I used the reference image to attempt the plate solve. This led to the crash described above.
Note that SGP does not seem to crash during the “Center Target” procedure when I am live and imaging.
When I open the sequence, open the image, right click on the image and plate solve from there, I get a pop-up that says “Failed to plate solve image! The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))”
I will continue to troubleshoot Elbrus today and re-install it if necessary. I suspect that when I get Elbrus solving again (I know it used to–just not sure when it quit) the crash will go away. I thought you might want to know about it, though. This is all of the information that I can think of to include. If you need anything else, let me know.
Shane,
The RPC_E_SERVERFAULT error is generally an indication that SGP can’t talk to elbrus. I would recommend uninstalling Elbrus and seeing if this persists. How was Elbrus initially installed? Was the Elbrus Installer used from our Download page?
Gosh…It was so long ago, I really don’t remember. I know it worked
for a long time and I don’t really know when it quit since the local astromety.net server takes over so nicely.
I’ll reinstall with the SGP Elbrus Installer and see what happens. My
main reason for posting this instead of just re-installing to start with
is to make sure that you are aware of the issue when SGP actually crashes.
Thanks for the detailed set of steps for recreation. That part has been fixed and will be out in 2.3.8. If it makes any difference, I cannot convince Elbrus to solve your FITS file either. Pinpoint has no issue with it… Maybe somebody else with a known working Elbrus setup can give it a shot to confirm my findings.
Yeah, I’ve re-installed both Elbrus and SGP. One of Jareds test files
works, one fails, and my file fails. I don’t really understand it and I
don’t know when it started failing. I’ve posted to the Elbrus group for
help.
I’m really tempted just to abandon Elbrus and make the local astrometry.net my only solver. It never seems to fail anyway …
I’m sort of of the same mind. Elbrus’s track record for me is not too good. So far I don’t think I’ve ever had a fail with astrometry.net that wasn’t somehow my fault. Grossly inaccurate plate scale after changing OTA, too short an exposure through a NB filter are my usual sins. Elbrus seems to fail often for no reason I can figure out. I sort of feel waiting for Elbrus to fail during centering after a slew to the target is just time wasted as it so often will fail.
It would be nice to know what the difference is between people who report highly reliable solves with Elbrus as opposed to people like myself who have a poor solve rate with it. I can’t help but think I am doing something wrong and causing these fails.
To be honest I can’t tell you how often Elbrus is successful or not. I always use the blind solve fail over option and have a local ANSVR setup. I generally don’t watch my setup all that closely unless I know something is about to happen (meridian flip, target change, etc). And that’s more because I just like watching SGP “do it’s thing.”
I know I’m generally successful when using Elbrus but I couldn’t tell you what my failure rate is. I do that the blind solve fail over is invoked occasionally but I can’t give you a number as to how often. If I were to guess I would say that Elbrus succeeds about 75% of the time.
I’m in the same situation. My Elbrus failures have been increasing. I can understand using Elbrus before I used a local astrometry.net. However, with the local astrometry.net never failing and being fairly fast any advantage of using Elbrus is minimal and that advantage is lost when Elbrus fails so often. So, what advantage is there in using Elbrus - especially if the definition for success is it fails about 25% of the time?
For me it’s speed. Blind solves take around 2 minutes on my system. Elbrus fails in about a second. I’m willing to pay a 1 second penalty to potentially avoid a 2 minute solve. Previously I had ANSVR better optimized but with my current camera I can’t seem to get it much faster than 2 minutes.
The only benefit that Elbrus has over Astrometry.net is speed. If you don’t care about speed or if your Astrometry.net solver is adequately fast then there’s no need to use Elbrus.
Alfonso, on the Elbrus list, is able to solve the image by setting the
threshold to 0.01 to avoid the galaxies. When I do that, manually
running Elbrus outside of SGP, it solves sometimes and does not solve
sometimes.
I cannot get it to solve in Elbrus from SGP at all.
I’m going to leave Elbrus active, but set it to 5x5-dual angle. This
way it will either work or fail immediately. I can do the dual angle,
because any image I create from SGP will have the angle set properly and
any other image, I will have already solved blind.
My astromety.net local server solves in either 7 or 13 seconds depending
on which telescope I’m using, so it’s really not that big of a deal if
Elbrus doesn’t solve it.
So, hopefully during the center (and rotate) on object phase, Elbrus
will solve many of my images very quickly and I’ll get the 7 or 13
second wait only occasionally. I will never press the “Solve and Sync”;
I’ll always use “Solve and Sync Blind”, but I really only need to do
this once per evening. I can also use the blind solve on new target
files that I didn’t take with SGP and thus may not have accurate
position and angle info in their FITS header.
Shane,
That’s pretty much exactly what I do. Elbrus is set to 5x5 at Dual Angle. It solves most of the time (tonight it’s batting 100%, and I’m testing…so tons of solves). But when it fails I have ANSVR ready to step in with the Blind Solve Failover option. Also you can use “Solve and Sync” as it will still invoke the failover if Elbrus fails.
There is another crash related to this that I can report with version 2.3.13.
If no plate solve options have been set up and you try to plate solve an image SG Pro crashes. Shouldn’t there be a graceful way to handle this event? I chanced on to this accidentally. Its been months since I’ve used SGP and after the recent upgrade on my machine I did a plate solve without loading my default profile with plate solve options correctly selected. If I select plate load options everything works fine.
[edit: It is related to this topic in the sense that once again a failure to plate solve causes SG Pro to fail.]
I can confirm the behavior Ajay describes. Without having a plate solver set up SGP 2.3.13 crashes when trying to solve an image. Here’s my log file: Log File
I cannot reproduce this behavior (likely because there are a multitude of ways to solve images in SGPro and I am not choosing the correct one). Can you please provide a sequence of steps to help guide me?
I’ve never had the issue that Ajay describes. I reproduced it simply by opening SGP and without doing anything else went to the target settings gear next to “Target Set 1”, loaded an image using “browse”, attempted to blind solve (failed) then attempted to solve by clicking on “solve.” When I do that SGP crashes. I’m not sure how much of an issue this really is since if you have the plate solver set up correctly in a profile or manually as part of a sequence then this doesn’t happen.