With the help of an SGP expert I have (apparently) been able to confirm that a very useful parameter has been removed from the PS2 result. When the PS2 solve takes place, all the solve info disappears before its content can be read. Can we have this back please? Its needed! [Apparently it used to be there in PS1 but has now gone, despite its usefullness.]
Lawrence
He is referring to keeping the PS2 window open after solving. Unfortunately, I don’t know if that’s something Jared/Ken can fix. The software is actually written by the planewave guys.
The one I miss is in the log file, it used tell you the accuracy of centering . Now it only tells you it is within your limits.
On the Planewave window there is a check box that will keep the window open. Otherwise, it counts down and closes. So you need to get to the window and click the check box before it closes.
Perhaps this is only visible when it is solving; there is no such option
that I can see on the PS2 set-up window.
I’ll check it again tonight in realtime.
Lawrence
Yea, I didn’t see that option on PS2. PS1 definitely used to have that option.
Here is a screen shot of PlateSolve 2. Look for the “Keep Open” check box near the left bottom. The box to the left of it is the count down timer until it closes.
my obs computer is off, but I know I looked there and it wasn’t. He/we are running 2.29 if that matters?
I do remember seeing that on earlier occasions but it is no longer
there. This info is valuable when you need to know how far off the
current pointing is. If the actual scope mount is unable to get to the
correct place within x pixels, we need to know that. I had a guessed
setting of ~20 pixels and the scope never got there after 1 iteration
and I couldn’t see how far off it was. Yes, you can keep increasing it -
but there is a better way.
The PS2 solve screen vanishes efficiently… 
Did the ‘upgrade’ remove it, I wonder?
Lawrence
Lawrence,
It does tell you what you’re looking for on the auto centering dialog that pops up. That page will close too, but it stays up longer than the PS2 dialog.
I guess it’d be nice if it was logged?
I’ll have to look again when I can run through a session. Last night was
abandoned before I got started when the forecast clear skies didn’t happen!
Currently, the only way to identify any solve data results is by a very
careful look at the log file; not feasible at night in subdued light
when you are tired and just want it all to work! In addition, its hard
to find the entry!
Lawrence
Yea, you can see it on the auto centering dialog at the bottom. Keep in mind this is a non-issue once you have plate solving working. I haven’t adjusted mine in 4 years.
sg_logfile_20160925202857.txt (318.8 KB)
Last night was ‘interesting’. I have uploaded the log but cannot find the entries concerning PS2’s results - at least not those listing the error distance between ‘go to’ and target. I watched the PS2 process and was not able to click on ‘keep open’ because the solve was too fast… So I was none the wiser after this. However, PS2 crashed during the third process and took SGP with it, so I lost all the data anyway. I changed laptops during the short evening just in case SPG crashed, so I was well prepared. However, this time PHD2 went AWOL after calibration and then clouds came in…
Lawrence 
That’s unfortunate. I always build checklists for my software now. It’ll keep you on task even when it’s law and you’re tired.
You can do it ️
Any other detail on this? When you say that PS2 crashed and took SGPro with it I expect to see an abrupt end to the logs. Your logs show a normal shutdown of SGPro. Maybe you mean something different? About what time period should we be looking at?
Hello Ken
After I posted, I looked again at the log. I then realised that it was
inadvertently misleading. The log file and associated crash was on the
other laptop, not on my ‘observatory’ one. The log is from my
observatory laptop and shows (or doesn’t show the problems with the PS2
’crash’. It stopped on stage 3 and the message said something that I
forget - but indicated that it had effectively crashed. As soon as I
clicked ‘cancel’, as expected the screen went white and SGP had crashed
again.
I had expected to do the whole session on ‘supernova’ but had major
problems with PHD2 after a target change, and then its guiding failed
completely.
I have two operational laptops that I am hoping to configure identically
in case I have to swap following a crash.
I am going to work on a revised plan next time: PHD2 has to be guiding
on different targets before I can resume incorporating it within the SGP.
I apologise again for a semi-accurate summary.
Lawrence :-[
sg_logfile_20160925195137.zip (39.8 KB)
I have now uploaded the correct log from the correct laptop! You will see when it started - ~1951BST. IT shows where (and hopefully why) the program subsequently crashed. I have read through it but I am unable to understand most of it. If you are able to interpret anything from it I would be most interested to know. FWIW the session was abandoned with the laptop and everything moved to the other one (known as observatory).
regards and thanks
Lawrence
OK, well… there is no smoking gun in the logs, but this is what I think happened:
The primary issue seems to be that your solves are failing. I can’t be sure exactly why, but I have some suggestions:
[25/09/2016 20:19:39] [DEBUG] [Telescope Thread] PlateSove2 Param: Width - 696
[25/09/2016 20:19:39] [DEBUG] [Telescope Thread] PlateSove2 Param: Height - 520
Brilliant analysis - many thanks. I had believed that I had set up the control panel(s) properly but my recent look at how the sequence works showed me that my understanding was wrong. I use several different configurations eg one scope for sun (which therefore doesn’t do solving) and others for other specific jobs. Now I see that I do have to ensure that there are matching sets of control panels/sequences - and all set up with valid paths.
As reported on occasions, SGP has failed to escape from the sudden loss of a camera connection. At that point the program is dead. Because this happened several times I checked the hub p.s.u. and discovered that a replacement unit had failed identically. Since replacing that unit I think that the only crashes have been failing to solve ones (not every time). I use the term crash because if/when it happens, nothing can be done to rescue the program. Clicking on any option (eg abort) causes the white screen and ‘program not responding’ message. A true crash may possibly not appear in the log.
Either way, progress has been made and I will re-do all configurations and sequences.
Many thanks.
Lawrence
[Ken] Ken http://forum.mainsequencesoftware.com/users/ken Founder &
Developer
September 29@Lawrence http://forum.mainsequencesoftware.com/users/lawrence
OK, well… there is no smoking gun in the logs, but this is what I
think happened:
- Sequence is running and attempting to center on a target
- Sequence fails to plate solve with PS2 and terminates the sequence
- You attempt to manually plate solve a frame with Astrometry.NET
and this fails- You attempt to manually plate solve a frame with Elbrus, but it is
not set up correctly and fails- At 20:27:54 all equipment is disconnected from SGPro
- SGPro never crashes and is terminated (seemingly) normally at 16:43:45
The primary issue seems to be that your solves are failing. I can’t be
sure exactly why, but I have some suggestions:
- You do not have a blind solve failover setup. I highly recommend
installing and using ANSVR for this.
This started me checking out the configuration. I had installed ANSVR on
both laptops but not referred to it correctly in one of the control
panel profile configurations. Similarly I had failed to set up the blind
solve properly.
- You are not using SGPro’s sequence recover option. This is handy
and gives your sequence more chances to carry on of failure is due
to the environment.
OK - now understood.
- Upgrade to SGPro 2.5.2 beta to solve a serious failure on target
centering
Will do.
Figure out why PS2 is not solving for you. Is this accurate?
[25/09/2016 20:19:39] [DEBUG] [Telescope Thread] PlateSove2 Param:
Width - 696
[25/09/2016 20:19:39] [DEBUG] [Telescope Thread] PlateSove2 Param:
Height - 520
It depends. The Ultrastar is 1392x1040 pixels in bin-1. For target
locations it is set for bin-4 images (or should be). If I did any bin-2,
that would show the above.
I am now re-examining all the profiles and sequences.
Thanks again.
Lawrence