SGP crashing when taking flats

Every time I try to run a sequence of flats SGP crashes as soon as the sequence starts.
Here’s the link to the log file:

@PeterGoodhew

The logs, unfortunately, point to some very unspecific crash and then termination of the runtime. Can you upload the sequence (.sgf) file instead? We may have more luck there.

Ken

Ken,
Sequence uploaded: Dropbox - Error
New log uploaded:Dropbox - Error

(I am posting to this thread because I had the same problem, so I can get notified as to any resolution.)

Same here…I was told it might be caused by not mapping a network drive in windows but not sure if your issue is the same. Would like notification of fix.

This issue is not the same…

OK. Thanks for the SGF. Made the issue a lot easier to track down. We will release and test the fix in the 2.5.1 beta. Depending on how close we are to release of the new AF, we will either just release 2.5.1 or we will port this fix into 2.5.0 (since it is a crashing issue).

In the meantime, if you’d like SGPro not to crash, turn off the “Slave on sequence start” for sequences that do not connect to a scope or observatory…

Ken, here are a bunch of logs with 2.5.1.6 from this afternoon where it was continually crashing trying to get 120 Flats on my Canon 6D.
I did not have “Slave on sequence start” checked.

I also got the same crashes yesterday with 8300 and Canon.

If both of your cameras are behaving this way, it is, unfortunately, for entirely different reasons. The logs you just posted show an error very specific to our usage of DCRAW (not used by the 8300). I have no idea what’s happening, so I’ve added some additional trace code in 2.5.1.7 that I hope will help point to the issue.

[4/23/2016 4:03:58 PM] [DEBUG] [Sequence Thread] Created full file name (file does not exist): C:_C2D6SM_E3\FLAT-E-rc12x8\FLAT-E-rc12x8_0423_t0000.100_ISO1600_0057.fit
[4/23/2016 4:03:58 PM] [DEBUG] [Sequence Thread] Extracting RAW data…

Ken, many thanks. Problem solved for me.
Great support from you guys.
Peter

Sorry Ken, I probably misspoke above saying 8300 also crashed. Probably thinking last week when I had 1 crash only on 8300. I had 6Ds on both scopes doing flats yesterday, so definitely a Canon issue.

Please note that 2.5.1.7 makes no attempt to fix this, but contains more trace logging to try and narrow it down…

It was recommended that I map a drive to my server rather than directly storing flats to it. I tried that last night and after the 10th 5 second flat SGP crashed again. version 2.5.0.xx. I assume I can use 5 second exposures and call them lights to get around this issue.

I am fairly sure that calling them lights is not going to help avoid this crash. According to Ken this DCRAW related crash will only occur with DSLRs. If that is what you are using, it is likely the same issue all of us have been having. You should send Ken your logs with the new debug code to help track this down. Adding a 5 second delay to my flats did not help either.

Agreed… nothing to to with the flats type. Unfortunately, the new trace code is only in the 2.5.1.8 beta.

Latest Flat run crash with 2.5.1.8.

I am more convinced than ever that some thread interaction manipulating UI elements can trigger one of these failures. Not all of course, but some.

I just started this from scratch, having just installed 2.5.1.8 then ran the Flat sequence. I did not touch anything and it was running great up to about #13. This surprised me because the last time I ran the Flats I think with 2.5.1.6 it crashed continually after 1 or 2 frames for a while until finally it got into a mod where it finished the 120 frames.

This time at frame #13 I grabbed the control panel and moved it just to start using some UI elements. Crashed immediately at frame #14, which was written out and looks like the rest.

I have seen this same behavior many times before. But also many times it just crashes after a few or many frames without my touching the program.

I am presently using an old SBIG ST-402ME not a DSLR.

@jmacon

If you can manage to get this to happen again, can you save off the image in the logs:

“C:\Users\jerry_000\AppData\Local\SequenceGenerator\Temp\cannonRaw-0.tmp”

I would like to run some experiments on the file to see if it’s data related in any way. Also remember that when you grab it, you will need to do so prior to re-opening SGPro as that action cleans out all temp data directories.

On the other hand, you mentioned that UI interaction is also a possibility. Do you remember what kind of UI interactions you had?

@toml I’m not exactly sure I understand this. Either way it seems like you’d be storing data “directly” on it. Do you mean using a path with a letter driver vs using a network (UNC) path?

Also, as usual, we will need logs to see what’s going on… There are no known workarounds for the issue you are describing.

Sure, here is.

Just started this one from scratch again. Finished 4 frames then crashed. I did not touch anything.
I included the 4th (last) frame it saved. 2 files in temp.

On the prior one, it crashed with this action: “This time at frame #13 I grabbed the control panel and moved it just to start using some UI elements. Crashed immediately at frame #14, which was written out and looks like the rest.”.