Post-MoveAxis set_Tracking behavior

[rwsmythe]

Good afternoon,

Sharpcap v.4.1.12371.0 (X64, 64 bit), Windows 11 - up-to-date with patching, my own mount driver with ASCOM7 RC2 installed.

I've been trying to track down a mount issue that flashes up when using the left/right arrows. The logs are reporting that the mount is throwing an exception that Tracking can not be Set during a slew, but this only impacts the azimuth axis, not the elevation (mount is Alt-Az).

I have a 2 second settling time configured for the mount right now, so I expect my driver to report Slewing as true for 2 seconds beyond the release of the arrows.

To start off with, here is the logged error:

Verbose 11:05:40.757210 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.MoveAxis :: Starting MoveAxis(Primary, 0)
Verbose 11:05:40.797993 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.MoveAxis :: Completed (returned null) MoveAxis(Primary, 0)
Verbose 11:05:40.798016 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Starting get_Tracking()
Verbose 11:05:40.809403 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Completed (returned False) get_Tracking()
Verbose 11:05:40.809704 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.set_Tracking :: Starting set_Tracking(True)
Warning 11:05:40.846065 #13 Exception from SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.set_Tracking(True) : Exception of type 'TargetInvocationException' : Exception has been thrown by the target of an invocation.
Stack Trace: at object System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(object obj, Span<object> copyOfArgs, BindingFlags invokeAttr)
at object System.Reflection.MethodBaseInvoker.InvokeWithOneArg(object obj, BindingFlags invokeAttr, Binder binder, object[] parameters, CultureInfo culture)
at object SharpCap.Base.Utilities.LoggingProxyBase.Invoke(MethodInfo targetMethod, object[] args) in C:/Documents/Source Code/SharpCap/src/SharpCap.Base/Utilities/LoggingProxy.cs:line 25 in void SharpCap.Base.Utilities.LoggingProxyBase.LogException(MethodInfo targetMethod, object[] args, Exception exception)
Warning 11:05:40.846187 #13 Inner Exception : ASCOM.InvalidOperationException: Cannot change tracking state while slewing.
at void ASCOM.Com.DriverAccess.DynamicAccess.CheckDotNetExceptions(string memberName, Exception e)
at bool ASCOM.Com.DriverAccess.DynamicAccess.TrySetMember(SetMemberBinder binder, object value)
at object CallSite.Target(Closure, CallSite, object, bool)
at TRet System.Dynamic.UpdateDelegates.UpdateAndExecute2<T0, T1, TRet>(CallSite site, T0 arg0, T1 arg1)
at void ASCOM.Com.DriverAccess.Telescope.set_Tracking(bool value)
at void SharpCap.MountProxy.ASCOM.MountInterceptionProxy.set_Tracking(bool value) in C:/Documents/Source Code/SharpCap/src/SharpCap.MountProxy.ASCOM/MountInterceptionProxy.cs:line 442
at object RuntimeMethodHandle.InvokeMethod(object target, Void** arguments, Signature sig, bool isConstructor)
at object System.Reflection.MethodBaseInvoker.InvokeDirectByRefWithFewArgs(object obj, Span<object> copyOfArgs, BindingFlags invokeAttr) in void SharpCap.Base.Utilities.LoggingProxyBase.LogException(MethodInfo targetMethod, object[] args, Exception exception)
Debug 11:05:40.849355 #1 Notification (Status=Warning): SharpCap is having problems with your Track The Stars TTS-160. Currently retrying operation. in void SharpCap.UI.NotificationViewModel.DisplayMessage(NotificationMessage message)
Verbose 11:05:40.908528 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Starting get_Tracking()
Verbose 11:05:40.919768 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Completed (returned False) get_Tracking()
Verbose 11:05:40.930518 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Slewing :: Starting get_Slewing()
Verbose 11:05:40.970357 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Slewing :: Completed (returned True) get_Slewing()

Here is the equivalent sequence of orders from Sharpcap for movement about the secondary axis:

Verbose 11:05:34.577746 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.MoveAxis :: Starting MoveAxis(Secondary, 0)
Verbose 11:05:34.605515 #13 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.MoveAxis :: Completed (returned null) MoveAxis(Secondary, 0)
Verbose 11:05:34.638203 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Starting get_Tracking()
Verbose 11:05:34.648812 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Tracking :: Completed (returned False) get_Tracking()
Verbose 11:05:34.659423 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Slewing :: Starting get_Slewing()
Verbose 11:05:34.690619 #16 Mount : SharpCap.MountProxy.ASCOM.IMountInterceptionProxy.get_Slewing :: Completed (returned True) get_Slewing()

You can see that there is no immediate set_Tracking order in the secondary axis after the stop movement order is returned. I believe the immediate set_Tracking is a bug.

ASCOM doesn't appear to proscribe setting a Tracking value during slewing, however in this case I believe the correct answer is for my driver to throw the exception rather than hold the execution of the set_Tracking command until the mount is in a condition to act as that adds some ambiguity from the client perspective, particularly as that is not an asynchronous method so I have no way to acknowledge the order and indicate it is in-process...is that the behavior you would expect?

[admin]

Hi,

an interesting one... I wish I didn't have to send the tracking after stopping the moveaxis, but there are *lots* of drivers out there that don't resume tracking properly in that situation (or sometimes don't). I'm reluctant to make changes in SharpCap here, since I haven't seen any other issues arise from the various mounts out there in regard of this situation, so I would assume that they deal with it differently and do not raise an error.

I think there are two ways to deal with this from the point of view of an ASCOM driver...

1) Decide that the slew settle time doesn't apply to moveaxis movements - the documentation is unclear on this, since SlewSettleTime seems to refer to Slew methods rather than MoveAxis. Also, the expectation of the user who is using a 'virtual handset' movement buttons to move the mount via MoveAxis is to be able to make multiple adjustments (move a bit, move a bit more, back the other way) - having to wait a few seconds between stopping and restarting seems to preclude that working properly

2) Follow the guidelines in SlewSettleTime that synchronous operations should not return until the settle time is complete - apply that to MoveAxis(axis, 0) - ie the stop command on MoveAxis should only return after the additional settle time has elapsed. This maintains the expectation that non-async commands will have completed when they return. I do feel that this would lead to a poor user experience with the movement buttons though.

Do either of those seem acceptable?

cheers,

Robin

[rwsmythe]

I am with you on the conclusion of option 1 that SlewSettleTime kind of breaks MoveAxis when using it in that way.

I had 2 implemented until the ASCOM team shifted to nearly everything being ASYNC, which is what I think caused this in the first place. It also made the Sharpcap buttons so much more responsive.

I'm good with leaving things as-is since it is only a momentary flash of the mount connection error while the logic works itself out. I've been doing a bit more work with the driver and a potential new firmware version for the mount and the issue no longer shows up.

It was just interesting to me that the Primary axis and Secondary axis behaviors were slightly different in the logs and that lead to the momentary warning. But, I'm good with calling this closed. Thanks for checking up on it!