Focuser issue uncovers log "can of worms"

[admin]

Ok, so just in case I forget to reply to this on Monday, I added what I hope is a workaround for this to the code.

If the focuser has 'CPWI' in the name then the workaround will activate, and the moving status as far as SharpCap is concerned will be set back to 'not moving' if the position has been constant for at least 3 seconds and at at least 3 successive reads from the ASCOM driver - that will happen even if the ASCOM driver says that it is still moving. You would probably notice this as a few seconds delay after the move completes before the UI reactivates when this is happening - if the ASCOM driver behaves itself then the delay won't be there.

cheers,

Robin

[ChrisR Oz]

Perfect. I'll give it a try.
Cheers, Chris.

[ChrisR Oz]

Hi Robin,

Tried out SC 4.1.13010 and it worked brilliantly.

Checking the logs (attached) did reveal some bogus IsMoving=True from the CPWI Focuser. But SC recovered from that, as planned, and continued working. In the direction where the backlash is handled by SC, there is a strange delay before SC does the final backlash move. This is where the IsMoving=True situation has appeared an SC takes action to ignore the frozen status. As the short backlash move is short, CPWI does not seem to freeze then and the IsMoving status recovers after that.

Thanks Robin!
Cheers, Chris.

[admin]

Hi Chris,

glad that worked as planned - the slight pause while it waits long enough to be convinced that the previous larger move had finished is to be expected with the new workaround. I suppose that I could do something to reduce the amount of time waited if the current position actually matches the target of the last movement sent to the focuser, although that starts to risk overriding any settle time allowance built into the focuser driver itself.

cheers,

Robin

[ChrisR Oz]

Hi Robin,

No, the small delay (perhaps 1-2s) is nothing, and will work well like this.

Thanks again.
Cheers, Chris.