SGPro 3.1.0.402: completely froze during a Autofocus run

OS: Microsoft Windows 7 Professional
Ver: 3.1.0.402
.NET: 4.8

Description

SGP froze during a Autofocus session. SGP became completely unresponsive and I was forced to use the task manager to kill the SGP process. This actually happened twice during the same evening. The second time was during an unattended imaging session as part of a sequence where I ran AFs between each frame (gathering data for filter offset calculations). The problem occurred during the 13th AF run. The last entry of the logfile says:

[12/05/19 22:20:32.792][DEBUG] [Camera Thread] Auto focus HFR calculated at: 1.81
[12/05/19 22:20:33.803][DEBUG] [Camera Thread] Incremental Fit Result (1): quality=%; a=0; b=0; c=0;
[12/05/19 22:20:33.805][DEBUG] [Camera Thread] Moving focuser to next position (7467)…
[12/05/19 22:20:33.805][DEBUG] [Camera Thread] MoveFocuserAbs: Start, move to 7467…
[12/05/19 22:20:33.805][DEBUG] [Camera Thread] ASCOM Focuser: MoveSync - start…
[12/05/19 22:20:33.805][DEBUG] [Camera Thread] Focuser moving to 7467
[12/05/19 22:20:52.589][DEBUG] [Main Thread] PopulateDataModel: Transferring view to the data model…
[12/05/19 22:20:52.596][DEBUG] [MF Update Thread] Performing serialize…

From this point only the “PHD2 Listener Thread” entries occurs in the logfile, all other threads stopped logging. The logfile can be downloaded below.

Note that when SGP froze the first time during that evening the entry was identical: a focuser move was initiated, and the last entry was [MF Update Thread] Performing serialize…

I haven’t been able to try to reproduce this due to bad weather. The focuser appears to be working, I have tested it in daytime. But you should know that I wrote myself the ASCOM driver for my focuser, and I know it is not implemented very professionally. I plan to rewrite it soon, but I’m not sure the focuser is to blame here?

Thanks, Mikael

Logs

It looks like the focuser never returned control back to SGPro… if it had, SGPro would have timed out. We need to move a lot of this stuff out of the sequence thread so that it can monitor that stuff… 4.0 maybe.

Have you made sure that your driver is thread safe? SGPro is (in)famous for clowning drivers that do not protect against this properly.

Thanks for the feedback Ken.

No, it is not thread safe. Actually I’m just vaguely familiar with these multithreading issues, having just recently started programming again when writing the AF logviewer (20 years after my university courses! :). As I said the driver is not pro at all! I quickly wrote it about 2 years ago, and it worked flawlessly until now. So I never went back to finish my quick and dirty solutions. But I never considered multithreading anyway. I just saw this old post that will surely help me with that:

Still, I’m not excluding a hardware error, the Arduino controlling the focuser was exposed to quite low temperatures that night (below 0 Celsius). Is there any reason to believe that SGP 3.1 would be more demanding on the driver in terms on handling multithread calls to it? Because it worked without a single hiccup for 2 years up to when I started using the 3.1 betas. Just trying to increase the likelihood that my repair fixes something actually broken!

Not that I’m aware of… that said, 3.1 saw so many changes that the way we interface with focusers may have a different fingerprint now. It’s probably not just a coincidence that it started acting up with 3.1 (maybe though… extreme cold does weird inconsistent things to gear). My thoughts are that:

  • SGPro isn’t necessarily more demanding, but rather, asks for information and gives commands in a different order than it used to. This may expose a bug in the driver (like a race condition… that would explain the behavior we see where the driver never returns control to SGPro).
  • SGPro actually is (unintentionally) harder on the driver and we can throttle that (drivers should actually protect their hardware from abuses like this though).
  • Lastly, there may be an actual defect in SGPro that happens so rarely (timing based) that it is difficult to identify and easier for me to point fingers everywhere else but back at myself.

You can turn on the DriverAccess trace in ASCOM or output your own logs to check on thought number 2. We can also use ASCOM logs and merge them into SGPro logs to get a full picture of what is happening.