Hi,
I was imaging with a ZWO ASI1600MM-Cool, and after working well for a few hours SGPro got stuck at the image download step.
I got this notification:
[12/29/19 02:28:45.423][DEBUG][Main Thread][SQ;] Adding sequence level notification: (mono) Failure while integrating ic443; Event 2; Frame 1 for 240s. Image has not downloaded in alloted time period.
Although the log says just before:
[12/29/19 02:25:47.555][DEBUG][Camera Thread][SQ;CC;] ZWO Download Completed in 716 mS
Then SGPro stayed idle for about 3 hours, then out of nowhere the image was saved at 5.26am. I don’t know if that’s an issue with SGPro or ZWO, I’ll link the log below.
Also the fact that the sequence eventually recovered might be useful to design a way to recover faster for this kind of issue.
We are no longer supporting ZWO drivers natively. I am unsure if the problem stems from our attempt at native support, but we are not currently able to investigate issues from ZWO cameras that don’t come from use of the ASCOM driver.
Hi,
Happy new year.
I got the same problem with the ASCOM driver for the ASI1600MM-C.
In the log below, the issue arises at [12/31/19 23:44:53.784]
Based on the previous images, the next log should be:
[12/31/19 23:37:44.057][DEBUG][Sequence Thread][SQ;] Disable driver temp comp. Driver temp comp was on → False
[12/31/19 23:37:44.068][DEBUG][Sequence Thread][SQ;] ASCOM Focuser: Temp comp is avaialble, setting to False
[12/31/19 23:37:44.229][DEBUG][Sequence Thread][SQ;] Collecting FITs headers…
so that may be what is causing the hold.
The following PHD2 errors are because the mount hit the limit.
The image was eventually saved at [01/01/20 00:45:51.872], about 1 hour later.
SGPro then tried to trigger the meridian flip, but it did not work, maybe because the mount was stopped at the limit. I tried to trigger the flip manually but this did not work either.
At the end I closed and restarted SGPro and centered on the target (on the east side of the pier now) which worked.
Yes, it sure does look like SGPro sat and waited for a long while to turn driver temp comp off. I know you were not using driver based temp comp, but it seems as though your focuser driver may hate it when it is asked to turn temp comp off and does not have it on. This is seemingly a bug in the focuser driver… in the meantime, it’s easy enough to skip this command if your focuser reports it wasn’t on in the first place. This will be in 3.1.0.431. Honestly though, I don’t know if this will make any difference to you because it seems to get stuck on the check to see if the driver has temp comp available and not on the command to turn it on or off. You may need to enable focuser logs if this doesn’t help.
Hi,
I updated SGPro, but I encountered this problem again, twice in one sequence. Focuser does not seem to be cause. Issues are around:
[01/18/20 22:51:53.541]
[01/19/20 01:43:14.192]
Each time, about 1 hour of imaging is lost, apparently waiting or writing the FITS header.
I can’t really say, but I expect it is the same thing as last time in that the focuser is just not responding when asking for information. The very next thing the code does after that note about the DATE-LOC is ask the focuser for its current temperature. We never seem to get past this… Focuser logs would help unwind this.
Hey,
I was able to recover the focuser log for that last session, see around these two times stamps (22:51 and 1:43), something is clearly happening with the focuser. Is the issue with SGP or with the focuser, or maybe windows COM port?
We are not qualified to accurately determine exactly what is going on in the focuser driver, but it appears to be in what is called a “deadlock”. This log would be very helpful to the driver’s author.
No issues with communication… all that seems stable
