I have had this same issue now a couple of times recently, both with the previous Beta and now with the latest Beta. At 21:58:20 the plate solve has failed, probably due to the clouds but instead of going back to the recovery mode, the SGP has aborted the sequence. My recovery settings are attempting every 10 minutes for 10 hours.
Link to log-file attached. Any ideas why the failure happens?
https://drive.google.com/open?id=19HcH2L5_qqG4H3DYSuCIbSr1YKnaShAh
Thanks,
Mikko
Seems like maybe a timing issue where a couple things we use were deadlocked. I have some changes to abort signals coming out soon… hopefully, they will address situations like this.
Thanks Ken, looking forward…
Any update to this Ken? I’m on he latest version and have now issues basically every night. As long as it’s clear, I’m OK but it seems that any passing clouds which stay a bit longer will make the SGP to abort the session.
Thanks,
Mikko
Yes, this was resolved over 2 weeks ago… just forgot to note it.
Bummer as I still seem to have this issue. Together with a platesolve issue now where out of blue it won’t work unless I shut everything off once. Or sometimes the platesolve just freezes during the download phase. The latter one is a totally new one for me.
Can you upload a log with the latest version demonstrating the error?
Thank you,
Jared
Sorry, still haven’t done this. But I did notice a couple of things yesterday; When forcing manually a autofocus before the next frame, the auto guiding does not stop. This was true also with the old revision. Should this be so? Also, when the clouds rolled in yesterday and the platesolve image had zero stars on it, I cancelled the platesolve which automatically started the end of sequence process. Should this be the case?
I did change the platesolver to be ASTAP after reading some good things about it and when I started the sequence yesterday, it worked and it worked fast. But as said, then the clouds rolled in so I have no more experience of it yet.
No, this is a bug. It is fixed in 3.1.0.412
I tested this here and it works as expected. Please send us logs showing the behavior.
Here’s yesterday’s log file.
https://drive.google.com/open?id=1Fy74RmHjeB6WTxALq-XSoDRWcjV4-J38
One more thing I have noticed now a couple of times; I get an autofocus warning that the value of two consecutive focus points are similar (or something like that) and after this the autofocus stops even when clearly the v-curve is trending down.
Mikko
I’m not sure about the auto focus pause issue. In that log you sent there were only 3 auto focus runs that were executed during a sequence and all 3 successfully paused and resumed the guider. Are you sure youre not talking about “manual” focus runs outside of a sequence? You had several of those too.
We will be addressing the manner in which SGPro makes decisions about how it collects data in SGPro 4.0. For now, you should work to ensure that you don’t have 2 values close together and either increase backlash compensation, increase your step size, move to 9 data points or all three.
Correct, I was talking about manually forcing an autofocus between the frames. I was assuming that the autoguiding would equally stop then also.
Mikko
SGPro will not modify PHD2 unless a sequence is running.
Got it, makes sense. The weather was poor and cloudy yesterday evening so I thought I’ll try the recovery again and see if it keeps trying as it should and sure thing, didn’t notice anything unusual. Every ten minutes the recovery started as expected so what ever issue I might have had before is hopefully gone.
Mikko
Well I had another unsuccessful recovery night, actually I don’t think I have had one successful with any 3.x version yet. I’m planning to upgrade to the latest version before the next session hoping that would help. Meanwhile, here’s the log from the last night. I’m trying to understand what happens at 02:55:38.744 but it goes beyond my understanding. Can someone take a look at the log and explain to me why the sequence was aborted.
https://drive.google.com/open?id=1Deqf5b27U40ndZJg0x8Fz9X7ka0dOYQa
Mikko
Do you mean you are looking to understand why you were in recovery mode or why recovery mode stopped trying?
Why the recovery mode stopped trying…
I see the solve failed 10 minutes earlier, not sure why that happened either.
Mikko
The original recovery started when the camera failed to download the image. This can be caused by a multitude of things. It looks like you are using the new QSI driver. Those drivers are new enough that it might be worth it to keep logging on there since SGPro has no idea why a camera did not return data, just that it didn’t.
Recovery attempts will quit when the target’s end time is encountered.
I have added a sequence level notification to try to make the reason recovery quit a bit more clear.
OK, I might try to find the older QSI drivers and install those back. The sequence has three targets, the last one ending at 6.45 so I don’t understand why it would think that it was done with the sequence.
Mikko
Because the target you were on when centering failed passed that target’s end time… therefore the sequence failed. Movement to the next target when the previous target fails is not on by default. If you desire that behavior, you’ll need to turn it on in the recovery settings.