ZWO Filter wheel connection reset mid session

Hi - Has anyone seen connection to ZWO Filter wheel get disconnected mid session but SGP continues imaging as if nothing has happened no error at all, in the meanwhile filter wheel has reset filter position to 1. So if you are imaging LRGB by the time you are imaging G and B the filter is in position 1 but images are are for 3 and 4.

SGPPro
this is the screenshot of the filter connection status and session details

below is from the log file

[01/17/24 23:16:27.884][DEBUG][CP Update Thread][SQ;CC;] Caught exception while getting filter wheel position. FW is expecting to be STOPPED! Returning (4) : unspecified (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.Runtime.InteropServices.COMException: unspecified
— End of inner exception stack trace —
at System.RuntimeType.InvokeDispMethod(String name, BindingFlags invokeAttr, Object target, Object[] args, Boolean[] byrefModifiers, Int32 culture, String[] namedParameters)
at System.RuntimeType.InvokeMember(String name, BindingFlags bindingFlags, Binder binder, Object target, Object[] providedArgs, ParameterModifier[] modifiers, CultureInfo culture, String[] namedParams)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 242)
at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 287
at ASCOM.DriverAccess.FilterWheel.get_Position() in C:\ASCOM Build\Export\ASCOM.DriverAccess\FilterWheel.cs:line 115
at us.i3()

I can’t comment on that error you added here as that is issued by the filterwheel and doesn’t contain any kind of useful information. In terms of the SGPro continuing as if nothing is wrong, SGPro is supposed to detect spontaneous disconnect and we’d need to take a peek at the full logs in order to see why SGPro did not detect this and abort the sequence (and issue an alert).

Further guidance on sending us logs is here:
SGPro - Help

Thanks Ken, Will upload the full log here, will take up the issue with ZWO. In the meantime will be great if SGP traps the error and take corrective action like pause the session or throw an error message etc.

This is definitely a bug as I was trouble shooting this over several nights I could repeat it every time.

Certainly we always attempt to do at least this much. As SGPro should have already done this, we’d need to see the logs to understand how this issue slips through.