Celestron Focus Motor problems

[Jim McPherson]

The Celestron Focus Motor isn’t working well. I often will find it disconnected in the “Equipment” tab, and have to manually reconnect it.

This regularly happens, but I haven’t been able to tell how often. Several times per night is the best I can do.

Additionally, while autofocusing, it will often report an incorrect position far from the focus point causing N.I.N.A to ask it to move a large amount. For instance if the focusing position is centered at 10000 and N.I.N.A. is set to use 4 points on both sides and have a step size of 50. It will start at 10200, take an exposure, go to 10150 take and exposure, and then the focuser will report it’s location as -65 (when it’s really at 10100). This confuses the entire system and the Focuser tries to move +10000 steps and the auto focus routine puts a focus dot way down below 100 and the graph goes nuts.

This doesn’t always happen, but happens at some point every night such that I can’t complete an imaging run.

‌

The attachment shows a sample of the trace-debug files from various nights of this happening.

I reluctantly switched back to SGP and have now run 4 nights with SGP without a single error from the focuser.

I’m currently running 1.10 nightly 13, but this has persisted through all versions I’ve used.

[Dale Ghent]

Generally speaking, focusers with ASCOM drivers perform nominally in NINA so long as their ASCOM driver conforms to the ASCOM Focuser API. When one particular make/model fails, it’s generally due to a reason with the driver, or the connection between the driver and the hardware.

In NINA, we update the status of all hardware every 2 second (by default). This means that NINA’s core queries the properties of all connected hardware that often. This in turn can cause drivers to relay the request for updated information to the hardware. On rare occasion, we see hardware that just cannot deal well with being queried in such a way so often, and this manifests in the hardware disconnecting or otherwise dropping out unexpectedly. We have noted this with Celestron focusers in the past; I can’t recall the model names off the top of my head, though.

One thing in this vein to try is to increase the device polling interval from its 2 second default to something higher such as 10 or 15. If the situation is improved at the larger intervals, you can try decrementing that value until things become unreliable/unhappy again, and you’ve found the break point. You can find the Device Polling setting under Options → General settings.

[Jim McPherson]

That's super helpful, thank you I'll give it a try tonight.

[Jim McPherson]

‌

[Stefan B]

The position value is taken directly from the ASCOM focuser driver. Looks like somehow this is reported very wrong in the driver.

[Jim McPherson]

So far it has stayed connected, however when I use the arrows to move it, it will often get confused. The second time I pushed the “>” it reported it’s position as -1, then started to try to move the focuser +10341 steps. I disconnected the focuser and reconnected to try and stop it from hitting the end stop. When I reconnected, the above screenshot appeared even though the focuser was spinning toward +20000 at the time. When I reconnected a 2nd time, the true position of ~16000 was displayed, and I commanded it to 10340 and it went back to it’s original position.

[Jim McPherson]

Note that at the next polling update, the above screen shot reverted to the correct number.

[Stefan B]

Yea it looks like the driver can’t handle polling it too often unfortunately.

[Jim McPherson]

How can I diagnose the ASCOM driver communications? In my attached .txt file I show the successful run of the ASCOM compatibility tool.

[Jim McPherson]

Polling is currently set for 10s.

‌

[Dale Ghent]

By default, the Conform tool tests for straight ASCOM compatibility, ie, function. Performance of the device is something it does not test by default, but can if the option is enabled in is Options → Conformance Options → Conformance test scope settings. “Test Performance” is off by default. This will stress test the hardware. It seems that the focuser driver performance test issues a lot of read queries for focuser position, isMoving, and temperature statuses but does not try to issue move commands in rapid succession.

‌

[Jim McPherson]

Is there a way to slow down calls to the driver? Like a settle timer between commands / polls even while actively interfacing with the focuser?

‌

Edit: I’ll run the performance test now.

‌

[Jim McPherson]

‌

ConformanceCheck ASCOM Device Conformance Checker Version 6.4.64.0, Build time: 6/7/2019 2:06:44 PM
ConformanceCheck Running on: ASCOM Platform 6.4 SP1 6.4.1.2695

ConformanceCheck Driver ProgID: ASCOM.CelestronUsbMotorFocuser.Focuser

Error handling 
Error number for "Not Implemented" is: 80040400
Error number for "Invalid Value 1" is: 80040404
Error number for "Value Not Set 1" is: 80040402
Error number for "Value Not Set 2" is: 80040403
Error messages will not be interpreted to infer state.

15:09:24.443 Driver Access Checks              OK       
15:09:24.474 AccessChecks                               About to create instance using Activator.CreateInstance
15:09:24.584 AccessChecks                      DEBUG    Successfully created driver using Activator.CreateInstance
15:09:24.599 WaitForAbsolute                   DEBUG    500 Waiting for driver initialisation
15:09:25.271 AccessChecks                      OK       Successfully created driver using late binding
15:09:25.271 AccessChecks                               About to set Link property true
15:09:25.287 AccessChecks                               About to set Link property false
15:09:25.302 AccessChecks                      OK       Successfully connected using late binding
15:09:25.334 AccessChecks                      INFO     The driver is a .NET object
15:09:25.334 AccessChecks                      INFO     The AssemblyQualifiedName is: ASCOM.CelestronUsbMotorFocuser.Focuser, ASCOM.CelestronUsbFocuser.Focuser, V
15:09:25.349 AccessChecks                      INFO     The driver implements interface: ASCOM.DeviceInterface.IFocuserV2
15:09:25.381 ReleaseCOMObjects                 DEBUG      Start of ReleaseCOMObject
15:09:25.381 AccessChecks                               About to release driver instance
15:09:25.412 ReleaseCOMObjects                 DEBUG      Unmarshalling Focuser
15:09:25.427 ReleaseCOMObjects                 DEBUG      Releasing COM object
15:09:25.443 ReleaseCOMObjects                 DEBUG      ReleaseComObject Exception: The object's type must be __ComObject or derived from __ComObject.
                                                    Parameter name: o
15:09:25.459 ReleaseCOMObjects                 DEBUG      End of ReleaseCOMObject
15:09:25.474 AccessChecks                      DEBUG    Collecting garbage
15:09:25.490 AccessChecks                      DEBUG    Collecting garbage complete
15:09:25.521 AccessChecks                      DEBUG    Finished waiting for pending finalisers
15:09:25.521 WaitForAbsolute                   DEBUG    500 Waiting for device driver to be cleaned up by operating system
15:09:26.224 AccessChecks                      INFO     Device does not expose IFocuser interface
15:09:26.365 AccessChecks                      DEBUG    Successfully created driver with IFocuserV2 interface
15:09:26.380 AccessChecks                      INFO     Device exposes IFocuserV2 interface
15:09:26.474 AccessChecks                      INFO     Device does not expose IFocuserV3 interface
15:09:26.568 AccessChecks                      OK       Successfully created driver using driver access toolkit
15:09:26.584 AccessChecks                      OK       Successfully connected using driver access toolkit
15:09:26.600 AccessChecks                      OK       Successfully disconnected using driver access toolkit

Conform is using ASCOM.DriverAccess.Focuser to get a Focuser object
15:09:26.724 CreateDevice                      DEBUG    Successfully created driver
15:09:26.756 ConformanceCheck                  OK       Driver instance created successfully
15:09:26.849 Connected                         DEBUG    Setting connected state to: True
15:09:26.865 AccessChecks                      DEBUG    Successfully changed connected state
15:09:26.865 ConformanceCheck                  OK       Connected OK

Common Driver Methods 
15:09:26.959 InterfaceVersion                           About to get property InterfaceVersion
15:09:26.974 InterfaceVersion                  OK       2
15:09:27.037 Connected                                  About to get property Connected
15:09:27.053 Connected                         OK       True
15:09:27.099 Description                                About to get property Description
15:09:27.115 Description                       OK       Celestron USB Focuser
15:09:27.177 DriverInfo                                 About to get property DriverInfo
15:09:27.193 DriverInfo                        OK       Information about the driver itself. Version: 6.2
15:09:27.240 DriverVersion                              About to get property DriverVersion
15:09:27.255 DriverVersion                     OK       6.2
15:09:27.318 Name                                       About to get property Name
15:09:27.318 Name                              OK       Celestron Aux Motor Focuser
15:09:27.380 CommandString                     INFO     Conform cannot test the CommandString method
15:09:27.380 CommandBlind                      INFO     Conform cannot test the CommandBlind method
15:09:27.396 CommandBool                       INFO     Conform cannot test the CommandBool method
15:09:27.412 Action                            INFO     Conform cannot test the Action method
15:09:27.427 SupportedActions                           About to call method SupportedActions
15:09:27.459 SupportedActions                  OK       Driver returned an empty action list

Properties 
15:09:27.646 Absolute                          OK       True
15:09:27.677 IsMoving                          OK       False
15:09:27.709 MaxStep                           OK       60000
15:09:27.740 MaxIncrement                      OK       60000
15:09:28.755 Position                          OK       10400
15:09:28.771 StepSize                          OK       Optional member threw a PropertyNotImplementedException exception.
15:09:28.787 StepSize                          DEBUG    Exception: ASCOM.PropertyNotImplementedException: Property read StepSize is not implemented in this driver. ---> ASCOM.PropertyNotImplementedException: Property read StepSize is not implemented in this driver.
                                                       at ASCOM.CelestronUsbMotorFocuser.Focuser.get_StepSize()
                                                       --- End of inner exception stack trace ---
                                                       at Microsoft.VisualBasic.CompilerServices.Symbols.Container.InvokeMethod(Method TargetProcedure, Object[] Arguments, Boolean[] CopyBack, BindingFlags Flags)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.ObjectLateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
                                                       at Conform.FocuserTester.CheckProperties() in J:\Conform\Conform\Devices\FocuserTester.vb:line 301
15:09:28.802 TempCompAvailable                 OK       False
15:09:28.850 TempComp Read                     OK       False
15:09:28.881 TempComp Write                    OK       Temperature compensation is not available and a PropertyNotImplementedException exception was generated as expected
15:09:28.912 TempComp Write                    DEBUG    Exception: ASCOM.PropertyNotImplementedException: Property read TempComp is not implemented in this driver. ---> ASCOM.PropertyNotImplementedException: Property read TempComp is not implemented in this driver.
                                                       at ASCOM.CelestronUsbMotorFocuser.Focuser.set_TempComp(Boolean value)
                                                       --- End of inner exception stack trace ---
                                                       at Microsoft.VisualBasic.CompilerServices.Symbols.Container.InvokeMethod(Method TargetProcedure, Object[] Arguments, Boolean[] CopyBack, BindingFlags Flags)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateSet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean OptimisticSet, Boolean RValueBase, CallType CallType)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateSet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments)
                                                       at Conform.FocuserTester.CheckProperties() in J:\Conform\Conform\Devices\FocuserTester.vb:line 350
15:09:28.927 Temperature                       OK       Optional member threw a PropertyNotImplementedException exception.
15:09:28.943 Temperature                       DEBUG    Exception: ASCOM.PropertyNotImplementedException: Property read Temperature is not implemented in this driver. ---> ASCOM.PropertyNotImplementedException: Property read Temperature is not implemented in this driver.
                                                       at ASCOM.CelestronUsbMotorFocuser.Focuser.get_Temperature()
                                                       --- End of inner exception stack trace ---
                                                       at Microsoft.VisualBasic.CompilerServices.Symbols.Container.InvokeMethod(Method TargetProcedure, Object[] Arguments, Boolean[] CopyBack, BindingFlags Flags)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.ObjectLateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
                                                       at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack)
                                                       at Conform.FocuserTester.CheckProperties() in J:\Conform\Conform\Devices\FocuserTester.vb:line 362

Methods 
15:09:29.084 Halt                              OK       Focuser halted OK
15:09:29.146 Move - TempComp False                      Moving to position: 16400
15:09:47.349 Move - TempComp False                      Asynchronous move found
15:09:47.380 Move - TempComp False             OK       Absolute move OK
15:09:47.412 Move - TempComp False             INFO     Returning to original position: 10400

Performance 
15:10:11.209 Position                          INFO     Transaction rate: 96.7 per second
15:10:16.271 IsMoving                          INFO     Transaction rate: 96.7 per second
15:10:16.287 Temperature                       INFO     Unable to complete test: Property read Temperature is not implemented in this driver.

Conformance test complete 

No errors, warnings or issues found: your driver passes ASCOM validation!

‌

[Jim McPherson]

I believe it’s driver related, but SGP does handle it well.

[Dale Ghent]

Just to be sure, there was an update to the driver in March of this year. Do you have 1.3 installed? http://software.celestron.com/installers/?dir=Focuser/USB_ASCOM_Driver

[Jim McPherson]

Yes, I’m running 1.3 and installed it in August.

[Jim McPherson]

Any recommendations on troubleshooting techniques? I’ve got the build environment setup and have cloned the code, I’m ready to try and fix it myself but it would be useful to have at least a little nudge in the right direction.

[Stefan B]

Hey,

the focuser related classes are inside ViewModel->Equipment->Focuser->FocuserVM and Model->MyFocuser->AscomFocuser where you might want to look in detail into the AscomFocuser class.

There you have the method “Move” and the Property “Position” where you might put some breakpoints or debugger statemetns.

[Jim McPherson]

Great! Thanks, I found it.

[Jim McPherson]

One thing I see frequently when I’m autofocusing and when I’m simply moving the focuser via the buttons is that the position is reported as -1. When autofocusing this terribly confuses the parabola fitting equations. I can’t help but notice that the default for position is -1 in FocuserVM “int pos -1”. What would be a good way to reject all positions that are negative?

[Dale Ghent]

A proper response from the Celestron driver would change that -1 to the actual position number. It is apparent that the Celestron driver is not doing this. I’m not 100% convinced that this is our bug to fix as many other focuser drivers from a wide range of manufacturers work fine.

[Jim McPherson]

In the txt file above with my logged errors, I think the error it’s throwing is really saying that it received a null when requesting the position. That’s consistent with -1 staying populated.

It seems to me that -1 should never be actually sent to the autofocus routine. Better to error out than send -1.

I tried SGP, Sharpcap, Firecapture, and the native Celestron GUI, and I cant get any of them to miss-read the position even after much “twiddling”. They all have fast refresh rates on the position and the ASCOM performance tests reports 96/second so I don’t think it’s an issue of a slow response from the driver/device.

[Dale Ghent]

That still doesn’t mean that those apps don’t work around an issue that is in the driver, and I’ll emphasize that chances are it is likely one as plenty of other drivers act fine, and Celestron's have been known to be problematic in the past. It has also been my experience that the SGP seems to prefer implementing work-arounds for driver and SDK bugs they encounter rather than working with the original developers to correct the deficiency. It’s going to require some really solid evidence to convince me that NINA’s logic is at fault here.

-1 is our default, initialization value when it comes to signed integers when a positive value is expected in practice. With doubles and floats we can set the value to NaN but we cannot do that with integers, so -1 is the analog to that. If we get a -1 for a property that is a signed integer, and a negative value is not expected, we know that something is wrong (or in some cases, that the property in question is unused.)

If we are receiving null from the driver, that’s clearly not conforming to the ASCOM spec as null is not a valid value for any of the properties in question. The question now is what is happening that induces the driver to emit that instead of a valid value. It could be that both SGP and NINA are both doing everything right, but in different ways, and NINA’s method or the order it goes about things tickles a driver bug that isn’t seen under other conditions. That’s still would not be a bug in NINA, though.

[Jim McPherson]

Agree it certainly could be an edge case and SGP developers will make custom work arounds. That’s why I also tried sharpcap and FireCapture.

Regardless of who’s “issue” it is, my point about -1 is that it should never be passed to the autofocus routine. Indeed no negative number should be passed to the autofocus routine.

in this case -1 has been wisely chosen as a value that should never happen, yet it’s clearly able to be passed outside of the focuser reading class.

if -1 does make it out, then the autofocus routine should reject it instead of using it as a valid position point.

‌

[Stefan B]

It would be beneficial to analyse the root cause for the -1.

-1 is only produced when a) the focuser is reported as not connected (but then a whole lot of other things won’t work) or b) one of the exceptions is thrown.

Which case happens for your focuser?

[Jim McPherson]

You can see a number of examples of the different errors I get in the txt file I attached (way) above.

[Jim McPherson]

Here is an excerpt:

[2019-09-20T22:32:04]    [ERROR]     [MemberName] Position
[2019-09-20T22:32:04]    [ERROR]     [FileName] D:\Projects\nina\NINA\Model\MyFocuser\AscomFocuser.cs
[2019-09-20T22:32:04]    [ERROR]     [Message] Object reference not set to an instance of an object.       at ASCOM.DriverAccess.MemberFactory.CheckDotNetExceptions(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 512
   at ASCOM.DriverAccess.MemberFactory.GetTargetInvocationExceptionHandler(String memberName, Exception e) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 664
   at ASCOM.DriverAccess.MemberFactory.CallMember(Int32 memberCode, String memberName, Type[] parameterTypes, Object[] parms) in C:\ASCOM Build\Export\ASCOM.DriverAccess\MemberFactory.cs:line 231
   at ASCOM.DriverAccess.Focuser.get_Position() in C:\ASCOM Build\Export\ASCOM.DriverAccess\Focuser.cs:line 159
   at NINA.Model.MyFocuser.AscomFocuser.get_Position()

‌

[Stefan B]

Yea so there is a null reference exception deep inside the ascom code, which must not happen. Celestron should really fix this issue.

[Jim McPherson]

Is there a way for me to watch the communications between an ASCOM driver and an application? I’d like to watch to see what the difference is between Sharpcap, Firecapture, SGP, and N.I.N.A. to determine where the ASCOM driver is having a problem.

[Dale Ghent]

The ASCOM driver itself would have to emit logs of this nature. Most driver do have an option to switch on logging to varying degrees and the ASCOM framework provides facilities to implement logging, but it’s up to the driver maker whether or not they do so. Outside of that, I know of no way unless there is a way to snoop COM port traffic in Windows using a 3rd party tool that I’m unaware of.

[Stefan B]

driver issue