I reported this issue first on the PhD forum but Andy says it appears to be related to the SGP guider API so am re-posting it here:
Andy said:
The debug logs indicate the crash happening right after the exposure request is issued to the SGP API guider, so I think we need to have Main Sequence Software look at it first. They will need to see your SGP log.
FYI, this is all with the 2.3.14.2531 version of SGP, not the 2.4 beta.
I had originally downloaded the current development build of PhD 2 as well as the current SGP guider API in order to test the new comet tracking in PhD. Once I was done with the comet, I went to a conventional object and conventional guiding and had repeated PhD 2 crashes not long after guiding was asked (by SGP to PhD) to start. I uninstalled the current version of PhD and went back to 2.3.1i (which has been stable for me) and it still crashed with that. Finally I also uninstalled the new SGP API and went back to the old version of the API (V 1.1.0). It now works properly again with no crashes.
FYI, the crashes DID NOT happen when I was testing the PhD comet tracking, probably because I was doing manually triggered images with frame and focus and was manually starting and stopping guiding from PhD. It only happened when SGP was commanding the guiding to start and stop as part of a sequence.
Can you post the log from the SGP API Guider? It will be in your My Documents folder if you have logging enabled. The changes in the SGP API Guider are pretty minor between 1.1 and 1.3. It’s unlikely that any of those would case different behavior.
We’ll probably need the PHD log as well so we can coordinate the crash in PHD with the other logs.
It is pretty odd, It seemed to start when I went to the new comet tracking version of PhD to try it on Lovejoy, then went away after reverting to the older versions of the API and PhD. OTOH, I did see it one more time after that, a few nights later, but was preoccupied with a mount slew issue. I don’t think that is related to SGP or PHD, however, and am working on fixing that now - likely a hardware issue.
I’ll have to do some more digging and maybe put out a version that has some additional logging. It appears that the API guider timed out while attempting to get the image. However the timeout is 60+exposure time so in your case 66 seconds. And the error occurs 5 seconds after the image was requested.
1.3.0 actually has logic in it to suppress this error from making it to PHD, in which case you would have just received the previous image data. So as of now i’m not really sure how it got into this state so fast.
I’ll put together a version that adds some additional logging. But for the time being you’re probably safer using 1.3.0.
OK, I still have to wonder why I went (almost) all summer w/o this issue and it suddenly showed up again. No hardware changes at all and the only SW changes were the API and PhD versions.
I will try to stick with 1.3.0 if possible.
As I recall from before this was related to longer guide exposures. Would it be worth trying a shorter time (maybe 2-3 sec. instead of 5-6)? With my mount and alignment, longer times usually give more stable tracking but I could use 2-3 sec. at least until the bug is squashed. Maybe Andy could comment on this as well.
Would the 2.4 beta be in any way less likely to do this? I now have that on my laptop so could try it.
You may be able to get decent results with the shorter exposures for now if you increase your hysteresis and/or decrease your aggressiveness. With the shorter exposures you will get more seeing variations, so you can try to smooth things out a bit with those parameter changes. But even at 2-3 seconds you should be averaging out most seeing. I seem to see the variability go up more under 1.5 sec or so. At least that’s how it seems to me under my skies.