Hi
I am using sgp 2.4.2.25
I am trying to capture callibration frames tonight and sgp keeps crashing
Last logfile for any ideas
sg_logfile_20160108190626.txt (833.5 KB)
Based on your logs and the fact this issue seems isolated, I can only venture that:
- The disk is out of space
- The disk is unhealthy
- SGPro had device level trouble getting data from the device (to save to disk)
The last thing written by your logs signifies that it is about to write data to disk.
Hi
I finally got it to work last night , by introducing a couple second delay between exposures ??
I can only surmise that sgp / my computer/my camera cant cope with too much going on at the same time
Harry
Harry,
What type of computer are you using? My guess is you’re exceeding it’s capabilities. Is this a mini-pc or other type?
Chris
Hi
Its a laptop that is about 3 years old with 8 gig of ram and over 750 gig free on the hard drive
the processor is a 1.6htz Celeron with windows 10
not a beast of a computer , but should be ok
Harry
Yea, I’m running a newer quad core Celeron… about the same stats and I don’t have any issues. Do you have a ton of programs running in the background?
I’m grasping. I run SGP without any issues on my little mini-pc. Have you run a SMART test on it to see if it’s about to fail? Maybe where it has SGP has bad sectors.
Hi
Have checked hardware on computer and all seems fine 
also it is not running much else ,so this is not a problem
Just seems it cant cope for some reason , anyway a small delay between exposure’s seems to have cured it
so as long as it stays that way , its not a problem
Harry
1 Like
Cool, sorry we couldn’t be more help Harry!
Chris
@Harry is not alone on this issue. I always have crashes taking calibration frames with my Canon 6D. I don’t remember any with my SBIG 8300M. Not sure about my Nikon D600, will check.
For the Canon:
Always happens taking calibration frames, not real imaging runs. I don’t remember a time in recent months when this has not happened. Happens early in the sequence In the included log it crashed on image #3 of 40 flats. Usually when I start the sequence again, it runs fine, but sometimes it continues to fail more than once.
My computer is a very new fairly fast quad core (3.2ghz) with 8 gbyte mem. Windows 8.1.
Revision: happens on all my cameras.
1 Like
Hi
I have not had this problem during a normal image run only during calibration runs
Harry
1 Like
Is it repeatable? Can you guys generate two or three logs with similar info?
Same issue here! Calibration frames (some times) crash SGP. Not an issue in regular capture cause I dither.
The medicine? Add a delay between frames (2s is enough).
Camera SBIG STF8300, PC windows stick (win10) writing to an SD card.
I’ll try to find a log file with the issue.
Cheers,
Jose
Jose, thanks for the tip, I will try next time.
I have the same problem with my STF-8300, ocassional crash so far only when taking frame/focus subs. Hard to duplicate/reproduce seems like a random thing.
You asked for logs, so here are some:
This zip has 3 logs for SBIG 8300M. The first 2 were initial crashes trying to take flats. The 3rd was the successful run.
This zip contains 12 logs for Nikon D600, 2 of which were successful, the rest crashed.
All 3 of my cameras have this crashing problem.
@mads0100 asked if it is reproducible. Not only is it reproducible, but I cannot remember an instance in the past several months when it did not happen on the initial 1 or 2 tries to take flats, biases, or darks.
And it generally does not happen with real imaging runs, but some crashes associated with taking an image, usually downloading it, have occurred during imaging runs.
UPDATE: It always happens for me taking flats, but only rarely taking darks. It may be related to some timing issue with short exposures. The darks are much longer than the lights. The 2 sec delay does not seem to help my lights.
Hi,
Well the 2 seconds delay didn’t work this time. I was capturing some calibration images @ bin 2x2 and it crashed 
Log available here:
https://dl.dropboxusercontent.com/u/45959662/sg_logfile_20160116201709.txt
Cheers,
Jose
Well… at least this error seems consistent (when it happens). I can’t even venture to guess why you experience crash / lock, but I do know the code section that it’s happening in…
Version 2.5.0.3 will have much more detailed (temporary logging) in the area at fault. Any assistance causing it to happen again with the new logging in place would be greatly appreciated. I took 200 bias frames with the SBIG sim 4 nights in a row now with no issue so I have to assume it deals in some way with real hardware. We don’t have any (real) SBIG 8300 based CCDs with which to test.
sg_logfile_20160106205803.zip (172.4 KB)
My crash report while taking focusing frames (and moving the focuser).
Rx_Timeout and “SGP stopped working”
Enclosed error message screenshot and logfile.
STF-8300M
EQG-G
Starlight Instruments focuser
Windows 10 Pro on fast i7 SSD machine
SGP 2.4.3.25
Alright… SGPro crashers (@jmtanous, @jmacon). 2.5.0.3 has been released as beta. It does not contain any code to address this issue, but contains code that will hopefully allow me to find it.
This issue is not isolated to SBIG, but seems most prevalent there. As such, I added a lot more code to the SBIG download and save data path. I think if I can find it for SBIG, I can fix it for all other types too (like in @harry 's case).
If you can reproduce this reliably (@jmtanous sounds like maybe you can?), I would be grateful to see it in a SGPro 2.5.0.3 log.
@4everNewbie, your issue is not related to this thread. It sounds like bad stuff happening with the actual camera connection though.
Ken,
I am out of town, as soon as I get back (next weekend) I will try to reproduce the issue.
Cheers,
Jose
Just tried a set of flats with my STT-8300M this morning. First run produced the attached crash.
Status bar said it was downloading image. My usual process with flats is to ‘Rotate through events’, one event for each filter so I can confirm correct exposure, after which I switch to ‘Finish entire events first’ to take 40 images per filter.
This process in the past has almost always failed after a few images for 1 or 2 attempts, after which it runs all the way through fine.
Same today, first run got through about 20 images before the crash. Second run (log not attached) ran all the way through perfectly. It did 4 cycles Rotating, then finished a total of 11 per filter not rotating.