Missing return movements after focuser overshoot

[thierrytsch]

Hi

I am working with a PrimaluceLab Sesto Senso 3 focuser and i figured out that the ASCOM driver (from the Sesto Senso 3 download package 1.0) might be buggy (The problem was that the focuser randmoly didn't move when the tool was initiating a movement but the driver thougth that the move was done and updated the focuser position to the target position). I had these problems with SharpCap and NINA using the ASCOM driver directly but could bypass most problems by introducing the ASCOM Device Hub. So this is probably a driver problem and not a SharpCap bug!

However in SharpCap i still have the problem that sometimes the focuser is no moving back to the target position after it was doing an overshoot movement. As far as I can tell, while there is a “settle time” setting for the focuser, it doesn't seem to wait for this time to elapse before initiating the reverse movement. I suspect this is why I sometimes don't get a reverse movement after an overshoot!

My recommendation would be to ensure that the settle time is also applied before the reverse movement during overshoot.
If this causes a too large performance degradation for users of focusers that do not experience these issues, an checkbox to enable the settle time before the reverse overshoot movement could potentially be introduced as an alternative.

Regards
Thierry

[admin]

Hi Thierry,

thanks for the feedback on the movement issues with overshoot handling. It does sound like the ASCOM driver is maybe ignoring the request if it is still 'busy' in some sense and the request comes in too quickly after a previous move finished.

The settle time is really meant to be about letting any vibrations from the movement die away before trusting the image, so it feels unrelated to the issue of the ASCOM driver here. However a small delay before sending the second stage of the overshoot movement seems appropriate and wouldn't adversely affect anyone (at least not noticeably). I'm going to try a 1/2 second delay and see how that goes - currently the delay before the second move could be between 0 and 0.5s after the end of the first one (SharpCap polls the movement status of the focuser twice per second). My guess is that maybe you have issues when the poll happens just after the movement finishes, but when the poll happens maybe 100 to 500ms after the move finishes then it may be working. Anyway, let's try it and see

cheers,

Robin

[thierrytsch]

Hi Robin

Thanks for the quick reply. I’ve already opened a ticket with the manufacturer, PrimaluceLab, regarding the general communication issue between NINA and the driver. There might be problems with concurrent requests to the driver. If they fix the issue, that might also resolve the overshoot behavior.
I think the suggestion to add a short pause before retracting is a good one. Hopefully, this will make SharpCap more robust against this or similar communication issues with ASCOM focusers.

Cheers
Thierry