Autofocus during sequence froze entire interface for 50 seconds

[lowenthalm]

This was with the latest 4.1 beta release.

I ran the attached sequence to perform a refocus. The entire interface froze as it was performing the initial focus slew. The frame that froze showed the blur of the focus change in progress and it stuck there for almost a minute. You couldn't click or move SharpCap sequence editor window (Maybe this might have been a side effect of whatever was happening in Sharpcap causing Parallels on my Mac to have have problems properly servicing the SharpCap processes). I could switch to other Windows programs and they seemed to work fine.

Freeze appears to occur at 00:13:10 in the attache log. I have included a section of the initial startup where the camera was connected and trimmed out everything after that until just before I ran the focus sequence (attached). It looks like there was some sort of error at the camera. The mount and focuser are operated through the CPWI ASCOM driver with data sent through a USB 3.0 USB cable to my camera which then connects to the mount (with a Celestron focuser attached to it) through the USB 2.0 hub on my ZWO camera.

I saw this behavior once before running this same sequence. I have never seen the behavior when running FWHM focusing directly. I have used each about equally as often recently, so I don't think its a sampling effect.

[admin]

Hi,

an interesting log, thanks for sharing...

The delay is a slowness in switching the camera from live mode to still mode for the focusing run (still mode avoids a lot of issues about exactly *when* a frame was captured relative to the movement of the focuser). ZWO cameras require a bit more work for this switch (basically close to a closedown and reopen) and SharpCap is becoming stuck for 50s or so in a small block of code related to the closedown. Actually the log restricts the places it could be to only 2 or 3 possibilities (although none seem an obvious cause). I have added some more logging so that if it happens again we should be able to work out exactly where it is getting stuck, which would then help explain what is going on.

cheers,

Robin

[lowenthalm]

More adventures here. When I started testing with the latest release, it worked fine the first time, then the second time I ran my refocus sequence it got stuck in a loop with the focuser not moving, but it thought it had, it kept taking exposures, but didn't get anywhere. I captured the log after it had been stuck in this loop for a minute or two. Forgot to get a screen capture. Hopefully the log tail attached here will be enough for you. It contains the sequence that was being run. I killed the sequence, then ran it again, and everything was fine.

[admin]

Hi,

OK, I don't understand quite what is happening there as it looks like it was scanning and got to position 22802, and then the next measurements come in at position 22840. The scan was working inwards, so shouldn't have requested the move to 22840. Is it possible that something else moved the focuser position 'behind the back' of the focus scan? It's possible that if it thinks it has asked for 22792 (or whatever the next position is), it would wait forever expecting the focuser to get there in the end... I will check that possibility, but it doesn't explain why the wrong value was being returned.

cheers,

Robin

[lowenthalm]

Yeah, I was pretty confused by the log too. As soon as I saw the problem, I wished I had turned the focus trace logging turned on. A few versions back I had it turned on, but it was so verbose I had to turn it off as it made it hard to find the relevant section of the log to send you when a problem occurred. Maybe the comm traffic with the CPWI focus driver would have made the cause clear. Could you possibly enable focuser logging temporarily when autofocus functions are running?

As I look at the log again, I realized that it was the first time I ran focus. Prior to first focus (that got stuck in the loop I sent), I had been doing some tests of:
SEQUENCE
PRESERVE CAMERA SETTINGS
SET CONTROL "Exposure/Gain Shift" TO -1
PROMPT "Press OK to Continue." ENABLECONTROLS False
END PRESERVE
END SEQUENCE

[Which worked correctly! Your fixed in this release worked.] and then tested out:

SEQUENCE
PRESERVE CAMERA SETTINGS
AUTOEXPOSE FLATFRAME
PROMPT "What happened?" ENABLECONTROLS False
END PRESERVE
END SEQUENCE

Which failed for some reason I couldn't figure out: the histogram was over 50%, so I adjusted the exposure/gain to get it under 50% and it still failed.

I gave up on "AUTOEXPOSE FLATFRAME" for the evening and moved on to getting first focus. I looked at the temp and manually changed the focuser position to the estimated best starting position by entering the desire focus position value into the focus position edit field in the SC camera controls panel. Then I ran my auto focus sequence and ran into the problem. I wonder if the focus position edit field still had focus when the autofocus started. Its possible I hit the keyboard and punched something in, but I don't think that's likely. Just to be sure, maybe autofocus should unfocus any current camera control field to prevent accidents from happening.


I ran the the focuser at least another tenish times and didn't see the problem again (I am collecting data before dark to characterize my focuser behavior right now). I will test it some more this evening and be sure to turn on focuser tracing during my focus testing.

Of course, it could have been a sporadic problem in the CPWI driver. I am sure there are bugs lurking in there!

[lowenthalm]

Not sure this is the same thing, but it started getting super slow updating the focuser position (the little editable text box control) in the focuser control panel after a focuser sequence scan.

This happened for several runs of my refocus sequence (Previously posted). It worked fine earlier in the evening, but later in the evening, suddenly SC finished the focus scan and moved to the focuser position it grew very slow updating the focuser position text box. I was copying the value from this text box to a spreadsheet, which is why I realized that it didn't always have the right value when I copied it. It messed up a few of my earlier entries - so I had to go back and redo them.

I turned on focuser logging and found that the little text box wouldn't even undim and become editable during the last focuser sequence run of the night. It completed successfully, but the focuser position text box was stuck in with the last scan position value and this time, the text box stayed dimmed out - unlike previously when it stayed editable, but just slow to update. I closed the sequence status dialog and the FWHM focus panel, but the scane position still was dimmed and unupdated. I finally went to CPWI, where I proceeded to home and park the mount. I noticed that this operation triggered the focuser position text box to update with the correct value and undim. Attached is the tail end of the focus run where it moved the focuser to position 22873.

Super confusing. Hope the above made some sort of sense. Its late and my brain is a bit fried, apologies if the above isn't particularly coherent.

[admin]

Hi,

from that log it's tricky to be sure what is going on, but I did deal with a couple of bugs yesterday that might be relevant

* Slow response with over remote desktop with large frames or high frame rates

* Very slow response if excessive logging messages are created and log window is open.

Some fixes for these will be in next week's update (the second is largely trying not to log excessively in some situations). I think that the first one might be part of the general slow response issues we have been seeing.

Anyway, for now, I'd suggest turning off the camera verbose logging as that may be adding to the problem (and it makes tracking down info in the log a lot harder).

cheers,

Robin

[lowenthalm]

OK. I wonder if Parallels relies on remote desktop? Never thought of that, it makes total sense that it would! I guess its just like folks that run Sharpcap on a headless computer located at the scope via WiFi or an internet connection!

[admin]

Hi,

I'm not sure about remote desktop, but there is an extra layer of software going on between SharpCap and the real video card hardware, which means that (just like remote desktop) more time can be spent trying to draw things onscreen.

cheers,

Robin

[lowenthalm]

I believe I spotted at least once where it froze up much longer than normal during FWHM focus, but after what was definitely less than 10 seconds, it seemed to recover. Maybe it hit that timeout you put into the last release. It dawn on me what had happened a while later in the evening, so there was no hope at that point of snipping out the relevant part of the log for you. Will test the next release as soon as I can.