Camera control panel blank after camera reconnection?

[lowenthalm]

I am using version 4.1.14265.0-64bit, which installed without issue for me and has generally been running like a champ!

I have been using this version for several days now (since April 24th) and have now had two cases where the camera and hardware control panel suddenly went completely blank (black, as I am in night mode), after several hours of running. The first time it happened, I just assumed it was some strange random problem I had never seen in SharpCap before running under Parallels with Windows 10 (sorry about the weird hardware setup!). Strangely, my scripts and everything kept capturing the rest of the night as if nothing was amiss. I had scripts I could run that did the things I needed to do to, such as shut down the camera cooler when I finished for the night, so I managed to finish the night flying blind without having to restart SharpCap and wait for the cooler to come back to temperature.

The second time it happened, I suspected a SharpCap bug related to recent changes I saw in the change logs concerning camera reconnection, so I grabbed the SharpCap log so I could investigate the next morning. After trying various things in SharpCap, like trying "Reconnect to Camera" without success, I ended up closing the camera and reopening it, which restored normal control panel display. When I later looked at the log, I saw that there was a camera reconnection event that occurred at 16:47:59.648168, which was around the time I guessed the camera control panel went blank (I didn't see it the moment it happened).

I have attached the zipped log here. Hope this enough to track it down.

[admin]

Hi,

thanks for the log - there was a problem at that particular point - in the minute or so up to that point, the camera had stopped providing frames, with each attempt to get a new exposure failing. This is a pattern that we have seen before with ZWO cameras, and when this happens the camera seems to stay stuck in 'not producing frames' mode until closed and re-opened. SharpCap tries to automatically do the close/reopen for you when it detects this situation (more than 60s worth of dropped frames in a row), and it looks like the loss of the UI is related to this attempt to close/reopen.

I will have a try at reproducing the same problem myself - it's a bit of a black art getting the camera to close/reopen successfully without the rest of SharpCap (that is presumably happily doing something like capturing or stacking) noticing that anything bad has happened.

cheers,

Robin

[lowenthalm]

I have been capturing darks using a sequencer script for the last couple of days, and its happened during both runs within the first couple of hours of capturing dark data.

Let me know if you need another log example. I have at least two more logs I can send you now!

[admin]

Hi,

I think I will need those extra logs - I tried to see if I could make the issue happen here and nothing went wrong, both from unplug/replug a ZWO camera and from deliberately setting up the code to force a reconnect in the way that happened in your log. In fact, in my testing it didn't even go through a code path that could cause the controls shown to reload in those tests

If you could give me an idea of what time the problem happened for each log then I will at least be able to narrow down the search to a portion of the log and see if I can spot any common pattern happening.

cheers,

Robin

[lowenthalm]

OK, I am uploading the three darks sessions capture session logs, and named/numbered them Dark capture session 1 through 3 and retained the original log file name as the start of the file name. The original log I sent you is the same as Dark capture session 1 I have attached to this message, but I thought you might prefer to use the new copy of that session log as its file naming has some consistency with the naming of the 2 new logs I am including.

The comparison of the three is revealing, and may explain why you couldn't reproduce the issue by inducing a USB fault. Although there was a ZWO camera reconnection event in log 1 and log 3, there appears to be now no such event in log 2. However, I am (95%) certain all three of these sessions had a camera panel disappearance act within the first hour or two of starting to run the dark capture sequencer script that managed the majority of each sessions operations. Its remotely possible that I am misremembering session 2 having the camera panel problem, of course. I was just starting to watch with an eagle eye

So, it appears it was a coincidence that there was a camera reconnection event in log 1 around the time the camera control panel went blank. I did notice another camera error message in sessions 3. So, to summarize my obervations in the scripts:

Session 1:

Code: Select all

Warning 16:47:07.166630 #37 Fetching still frame from ZWO camera failed with ExpWorking, exposure is 30000, timeout is 51500                        in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, double startingExposure, BufferFrame frame, CancellationToken cancellationToken)

and then

Code: Select all

Debug   16:47:59.650562 #1  Notification (Status=Warning): SharpCap is trying to restart your ZWO ASI2400MC Pro as it seems to have stopped responding properly                 in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)

Session 2:
No camera failure errors that I can find... maybe you can spot something within the first couple of hours of the dark capture script running starting here:

Code: Select all

Info   	20:51:12.792264	#1 	The sequence being run is :
SEQUENCE
    IMPORT SUBS FROM "\\Mac\Home\Desktop\SharpCap Captures\__Sharpcap Sequences\Cooler Set Subroutines.scs"
    IMPORT SUBS FROM "\\Mac\Home\Desktop\SharpCap Captures\__Sharpcap Sequences\Frame Size Subroutines.scs"
    DEF SUB SetGainNearUnity
        SET GAIN TO 150
    END SUB
    DEF SUB SetAutoGain3s
...

Session 3:

Code: Select all

Warning	18:52:42.865598	#3 	Fetching still frame from ZWO camera failed with ExpWorking, exposure is 30000, timeout is 51500						in bool SharpCap.Cameras.ASI.ASICameraProxy.GetFrameData(int timeout, double startingExposure, BufferFrame frame, CancellationToken cancellationToken)

and then

Code: Select all

Debug  	18:53:35.613808	#1 	Notification (Status=Warning): SharpCap is trying to restart your ZWO ASI2400MC Pro as it seems to have stopped responding properly					in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)

[lowenthalm]

One additional wrinkle.

I use a Triplite 49 foot active USB 3.0 cable. They work great, usually lasting a couple of years until the weather cycles wear them out. Things went really sideways last night with a lot of frames corrupted, and lots of reconnections occurring, without the camera panel didn't disappear! Testing this afternoon seems to prove my current cable died last night - now it can barely stay connected more than 30 seconds after SharpCap Startup.

So this week the USB cable might have been on the way out, causing zero or one camera reconnection event per night in SharpCap and possibly some of the camera panel weirdness. However, I wasn't seeing any corrupted frames until last night, which has always been the dying USB cable symptom in the past.

This afternoon, I switched back to my previous Triplite cable that had grown slightly unreliable - one in every several hundred frames transferred would have some corruption. And am back up and running, for now, until my new cable arrives. I will report here if I see further camera panel disappearances.

Its still strange that SharpCap could be put in a state where everything worked as it should for many hours with the camera panel blank.

[lowenthalm]

And another camera panel disappearance tonight. A imaging script (for NGC 5466) completed at 00:20 and I switched filters at the scope and manually selected the new filter in the camera control panel, which was definitely visible between 00:20:00 and 00:25:17, at which time I started running a sequencer script to slew and start imaging a new target (DQ Her). Given all this, It must have disappeared between 00:25 and 00:34 in the middle of the focus scan when I noticed the camera panel was blank.

Interestingly, there was one camera disconnection-reconnection event at 23:52:43, during or right after a dither between sub capture in my NGC5466 sequencer script. But the camera control panel didn't disappear until over a half hour later.

[admin]

Hi,

thanks for continuing to provide feedback on this. I have concentrated on the last log file, since that has the narrowest window of only a few minutes for when the problem happened.

I am most suspicious about the period between about 00:29:53 and 00:30:32 - in that period the camera capture area, binning, live mode, etc are all changed by sequencer and/or script code, and in each case that triggers a refresh of what is shown in the panel on the right. I can't see anything going wrong during that process, but it is hitting the right part of the code to be able to change the contents of the right hand panel. I can't see why anything *should* go wrong if the resolution is changed from a script in a sequence, but it's certainly unusual enough that it is not something that gets tried out very often, so the sort of place that weird and unusual bugs might lurk...

As we explore this more, I am tweaking the logging in the relevant parts of the code to provide some more feedback on what is going on and allowing me to track this sort of thing in more detail from future logs. Most of those changes are going into SharpCap 4.2 at the moment (as I am really only fixing clear bugs in 4.1 now). I will be putting out a public beta of SharpCap 4.2 very soon now, so it would be interesting to see if that has the problem and if you can catch a log of it happening if it does. Beyond that future updates will have more logging that I have been adding today in response to looking at the most recent info above.

cheers,

Robin

[lowenthalm]

That is very interesting. Throughts follow...

Thought 1) The only time changing binning and ROI occurs in my capture scripts is when the script when a refocus scan occurs in order to maximize star count and minimize noise as focus scans always have to be done with guiding off (SCT mirror flop stuff!). This always happens wien the script starts, and then occasionally during the capture run. I will watch for this.

Thought 2) Now, the dark capture script is changing binning, ROI and exposure/gain a lot! So it totally makes sense that that the dark capture scripts would immediately run afoul of this.