Celestron Focus Motor problems
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.
Comments (30)
-
-
reporter That's super helpful, thank you I'll give it a try tonight.
-
reporter
-
repo owner The position value is taken directly from the ASCOM focuser driver. Looks like somehow this is reported very wrong in the driver.
-
reporter 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.
-
reporter Note that at the next polling update, the above screen shot reverted to the correct number.
-
repo owner Yea it looks like the driver can’t handle polling it too often unfortunately.
-
reporter How can I diagnose the ASCOM driver communications? In my attached .txt file I show the successful run of the ASCOM compatibility tool.
-
reporter Polling is currently set for 10s.
-
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.
-
reporter 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.
-
reporter
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!
-
reporter I believe it’s driver related, but SGP does handle it well.
-
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
-
reporter Yes, I’m running 1.3 and installed it in August.
-
reporter 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.
-
repo owner 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.
-
reporter Great! Thanks, I found it.
-
reporter 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?
-
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.
-
reporter 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.
-
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 asnull
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. -
reporter 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.
-
repo owner 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?
-
reporter You can see a number of examples of the different errors I get in the txt file I attached (way) above.
-
reporter 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()
-
repo owner Yea so there is a null reference exception deep inside the ascom code, which must not happen. Celestron should really fix this issue.
-
reporter 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.
-
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.
-
repo owner - changed status to closed
driver issue
- Log in to comment
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.