Focuser issue uncovers log "can of worms"

[ChrisR Oz]

Hi Robin,

I occasionally have an issue with the Celestron Focuser, mainly when doing long moves (e.g. focus move of 1000 steps or so). It will apparently do the move. But the Focuser (positive, negative and number field) controls stay grey in SC. If I go into CPWI and move the focus. Then often it comes back to life in SC, but not always. Toggling the connected devices using the "power plug" icon (or the "Connected" checkbox) does not fix it. Closing the camera, and reopening it, often does. All remain operational in CPWI.

So I enabled Focuser and Mount log messages, expecting to see some error with the Focus move. But I'm struggling to even find these, as the log is full of other messages. Seems it's complaining about there being no target RA/DEC (I'm testing in the garage, with no target selected, and tracking off). And the Focuser routines are complaining/throwing Exceptions about a lack of support for GetTemperature from CPWI's Focuser. Somewhere in all this, the Focus controls never get made active again, it seems.

I've attached a log file (edited out middle lines to make it fit size limit), in which I make a few positive and negative small moves (10 steps) followed by a few long moves (1000 steps). The last of these stalls, as described above, with controls never recovering.

Hope this in enough to learn something from ...
Cheers, Chris.

[ChrisR Oz]

I should add that I am using SC 4.1.12946, and the latest CPWI 2.5.6.
Cheers, Chris.

[admin]

Hi Chris,

the errors can mostly be ignored - these are things that SharpCap normally tries to do with the expectation that it might fail, but when you have additional logging switched on you see the failure in the log rather than SharpCap just metaphorically shrugging its shoulders and moving on. As an example, you can ask a focuser ASCOM driver for the temperature measurement, but there's no way to ask if it *has* a temperature sensor, so you have to try to read the temperature and be ready for the fact that you might get a failure from that.

Anyway, the cause of your problem is clear in the log - in the final movement that you tried, the focuser ASCOM driver does report that the focuser has reached the final target position, but it also continues to report that the focuser is moving. SharpCap is waiting for the ASCOM driver to report that the movement has stopped before it will re-enable the buttons and allow you to use them again. I think the theory behind having a separate indicator of 'moving' is that it allows for the focuser to keep the 'moving' status for some extra time after actually reaching the target - a sort of settle time - but here it seems that it may have been stuck completely. In the log it looks like 'Moving' is still set nearly 20s after arriving at the target position

I'm going to rather hopefully suggest that upgrading the ASCOM driver might help, but I suspect you already have the newest anyway. You could also try turning off the backlash handling in SharpCap and doing a further test - I don't think that is playing any part in it (except that every movement can become two movements, so potentially doubling the chance of the problem happening), but it's worth checking. If none of that works then I may need to work around it as a glitch in the Celestron driver - I already have a few workarounds for mount driver issues from various manufacturers...

cheers,

Robin

[ChrisR Oz]

Hi Robin,

I believe that CPWI implements an internal ASCOM driver. That's why we connect SharpCap to "CPWI" for mount and "CPWI Focuser" for Focuser.
I have already installed the latest CPWI 2.5.6.

Not sure what else to try ...

That said. This has been a long standing issue, that only crops up with long distance focus moves. In normal use it seems to function well. So it's not stopping me imaging. I just know if I do something odd (e.g. type in a very wrong absolute focus position by mistake) then it may hang (stay in Moving state), and I'll need to reconnect or restart CPWI at worst (I always save the alignment model, so this is not as bad as it sounds).

It may be that with long moves that CPWI gets distracted and does not come back to clearing the "Moving" status.

I know that SC relies on reading back the "Moving" status. But if the position has not changed for a few seconds, perhaps just assume it's zero (not Moving).

Cheers, Chris.

[ChrisR Oz]

Hi Robin,

Re-reading my notes about CPWI installation, I see that while it may implement an ASCOM driver, it still depends on the ASCOM platform.

I upgraded the ASCOM platform to v6.6 SP2. I have not gone to ASCOM v7 as yet.
Cheers, Chris.

[ChrisR Oz]

I realize that there is an ASCOM log file (short one attached) as well, generated by SC.

It shows clearly (at end) that IsMoving stays true long after the position stops moving, as you say.

Cheers, Chris.

[admin]

Hi Chris,

yes, agreed - it is still showing as moving in the ASCOM log just like the SharpCap one.

Out of interest, while SharpCap thinks the focuser is moving, it should enable the 'Stop' button to allow you to cancel a long move - does that button do anything useful if you press it while stuck? Just wondering if that might kick the Celestron ASCOM driver into getting its status correct.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

Sorry, should have mentioned that. Using “stop” never seems to help. I am guessing that SC passes on Stop to the driver, which ignores it, as it is stopped already, and then SC reads back the IsMoving status, only to find it still “moving”.

The CPWI driver should take “stop” as a queue to clear the IsMoving flag. But it doesn’t. I did pass all this on to Celestron.

Cheers, Chris.

[admin]

Ok Chris, thanks for confirming.

I will look at doing a workaround for this - with a little luck I might get it done by Monday as it looks fairly simple.

cheers,

Robin

[ChrisR Oz]

Very cool.
Thanks Robin.