SGP focuser hang up - bug?

Here’s the problem:

Temperature reading from UK made Lakeside focuser sometimes disappears. Then when running auto-focus the focuser will move to its starting position and then freeze. Often only option is to close down the whole programme. Fault not persistent, but occurs enough to make remote imaging impossible.

I run Win 7 with the latest version of SGP. Fault seems unique to SGP and does not occur with Maxim/ or Lakeside’s own utility. Log of incident which occured at around 3am local time below. Really baffled by this and any help very much appreciated. I see from the archive others have had a similar experience with this combination of hardware/software?

I had this occur very occasionally when using W7 - unplugging the usb lead solved the issue. I have never had this with W10. I always felt it was a usb/W7 issue rather than Lakeside or SGP.

Which Lakeside focuser control box are you using - the newer USB one or the older serial one (which requires a serial/usb lead)?

Barry it’s the latter, but I do use a Keyspan adapter with the more reliable chip. I’ll try my win 10 laptop. I’ve emailed Peter (maker of the unit) to see what he makes of it. Did the problem manifest itself in the same for you with Win 7? Missing temperature value, then focuser locking up?

Hi Richie
The missing temp reading only ever happened in W7 and the stepper motor was able to function as normal: so I could AF but simply had no temp reading.

It was quite infrequent though. When it happened at start up, I simply closed SGP unplugged the Lakeside USB/serial, Rep lugged and then when SGP restarted and I connected to th e focuser temp readings would display.

If it happened partway through a sequence (which was even rarer) I simply continued the sequence.

I switched to W10 last autumn and it has never happened since.

Barry

Looking at the log the problems start with an error from the focuser:

[09/01/17 02:55:22.115][DEBUG] [CP Update Thread] ASCOM Focuser: Error in GetCurrentPosition. : Exception has been thrown by the target of an invocation. (System.Runtime.InteropServices.COMException (0x80040402): Timed out waiting for received data)

This was generated by the focuser driver, presumably because of some internal problem.

There are then a series of errors like this:

(System.ApplicationException: Object synchronization method was called from an unsynchronized block of code.)

It’s not clear about these but SGP relies heavily on multitasking and so uses synchronisation a lot, it could be that SGP isn’t coping properly with the error from the focuser.

It’s all being reported from the SGP methods

at qw.mp()
at qq.id(Boolean A_0)

The names have been obfuscated and will change from version to version but it may be possible to use an assembly decompiler to work out where this is happening.

My guess is that the focuser is returning an unexpected exception and SGP is catching the error but not managing it properly.

This all finishes here:

[09/01/17 03:08:55.476][DEBUG] [Camera Thread] Error in auto focus! Focuser failed to move to the requested position (2205). Focuser reports it is at 0.
[09/01/17 03:08:55.478][DEBUG] [Camera Thread] Adding sequence level notification: Error in auto focus! Focuser failed to move to the requested position (2205).
Focuser reports it is at 0.

Not sure if the focuser has resumed and is giving a valid position of 0 or if SGP has stopped trying to talk to it. In any case several other things now seem to be wrong, PHD2 seems to have lost the guide star and an attempt to resume fails because the image doesn’t solve.

A focuser log and a DriverAccess log for the focuser may help.

It’s tricky because the focuser was working for hours. It would be really good if the focuser driver problem could be found. Ideally it shouldn’t throw an exception. But that’s what it should do if it really can’t recover and SGP should be able to cope.
Coping may be nothing more than closing down gracefully, reporting an equipment failure.

Chris
Thanks for looking at the log. The out of focus stars explain the subsequent failures (ie plate solving). I was in bed at the time this all happened and when I looked at the last screen download it was the first auto focus exposure run with the focuser racked out by 600 or so steps - the starting point to produce the V curve. I’ll have a look at gathering more log evidence. The Lakeside did indeed revert to zero - just seen that when using the Lakeside Utility.

Tried to reproduce the failure of the focuser using SGP on a Win 10 laptop last night and no problems experienced over four hours. That’s just a one night sample so need more imaging time to conclude that the operating system is the difference, but reporting the experience for what it’s worth.