SGP Crash in Frame and Focus with ZWO ASI1600 ASCOM Driver

Sequence Generator SGPro Support
1

Description

Ken,

Here is the log for a crash in Frame and Focus mode using the ASCOM driver for the ZWO ASI 1600MM Pro camera.

Link to Logs

Useful Info

OS: Microsoft Windows 10 Pro
Ver: 3.1.0.433
.NET: 4.8

2

So, the thing that the native and ASCOM crashes have in common is that they both crash in an extremely aggressive way. Decoded, this means that the application is crashing outside of the boundaries of .NET (SGPro) and, as a result, there is no information given. Typically, this means that the crash is happening in the native drivers (usually if the ASCOM driver crashes, it will emit information to SGPro about it). The fact that both logs emit literally nothing seems to point at the native drivers (as it is a thing they have in common). So…

  • Are your native drivers up to date?
  • Did you produce that log without a USB hub?
  • Have you tried a new USB cable?
  • Maybe ZWO emits camera logs that would more information?
3

Ken,

I also have experienced the SGP crash when usinng Frame and Focus with ASI ASCOM driver (ASI071MC Pro). I’m using the latest ASI ASCOM drivers.
Whenever the crash happens the following event is added to the Windows Logs/Application:
Application: Sequence Generator.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
at SequenceGenerator.Astrometry.a(System.Drawing.Imaging.BitmapData ByRef, qn ByRef, Int32)
at SequenceGenerator.Astrometry.b(System.Drawing.Bitmap, Int32, Int32, Int32, Int32, Double, Int32)
at SequenceGenerator.Astrometry.a(qq)
at qz.d(Int32, Boolean)
at qz.d(Boolean, Boolean, Int32, Boolean, Boolean, Int32)
at SequenceGenerator.MDIImageForm.b(System.Object)
at System.Threading.ThreadHelper.ThreadStart_Context(System.Object)
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)
at System.Threading.ThreadHelper.ThreadStart(System.Object)

The event content is always the same.

Hope this helps.

Thanks,
Vitali

4

Can you tell me the version of SGPro that exception came from?

5

Version 3.1.0.432
This is on Windows 10 64 bit.

6

Ken,

Answers:

  • Are your native drivers up to date? Yes.
  • Did you produce that log without a USB hub? Will try this today.
  • Have you tried a new USB cable? Yes, makes no difference.
  • Maybe ZWO emits camera logs that would more information? I’ll look. So far, cannot find any ZWO logs.

One thing it could be is the ASI 1600 camera itself. The on-camera hub does not function and the USB 3 port to the PC is not recognized if the camera is powered before the PC is started. I am making arrangements for camera repair.

The one issue I have with using the ASI ASCOM driver is that the offset is no longer available for being set in SGP for each event. This is problematic when switching between broadband and narrowband filters. Is this an ASCOM limitation or ZWO’s driver implementation?

Mark W

Mark

7

@sunlover @mdwetzel

I am unsure if the issues you are having are related. The issue that @sunlover pointed out will be “resolved” in 3.1.0.434. Resolved is in quotes because it really just means that SGPro won’t crash when it happens… The issue here is that SGPro is attempting to read corrupted memory of some kind when it is calculating HFR. So… what you may see now is either nothing at all and SGPro will function normally or you will see SGPro act mostly normal, but the stats around HFR and number of stars, etc will be 0. If that happens, the logs will contain more information this time.

Unfortunately this is possible. The ASI 1600 is a very popular camera and we have not seen a rash of these reports.

ASCOM. It is the opinion of the ASCOM council that dynamic offset is not necessary and should be resolved by camera manufacturer. I am not taking a stance here… I don’t know a lot about CMOS cameras and it is likely this decision was made for CCDs. It may be applicable to both in that the camera firmware or drivers should be able to determine the best offset for each individual exposure, but I don’t know.

1 Like
8

Ken,

I am embarrassed to say that the USB 3 cable from the ASI 1600 camera to the USB 3 hub indeed have a problem. I tested with a higher quality cable as well as the ribbon cable supplied by ZWO and they worked. It also cleared up the on-camera hub issue.

I guess I will surrender the ASCOM driver offset setting desire and simply set the gain. I will fix the offset in the ASCOM driver settings.

Thanks,

Mark W