Question after fw update: strange movements at the end of a goto

Hi,

I first stumbled upon this behaviour when imaging with N.I.N.A. The images for plate solving were already taken while the mount was still slewing. You can imagine the outcome...

So I wrote a simple ASCOM test app and saw that both calls SlewToCoordinates and SlewToCoordinatesAsync were behaving exactly the same, which is unexpected. According to the ASCOM specification the call SlewToCoordinates should only return when the slew is fully done.

Fortunately, the property Slewing is true while the mount is slewing, so that can be used as a check, of course. But still, this is only expected for the Async version of the slew calls.

I then installed the ASCOM conformance app from ascom-standards.org/Downloads/DevTools.htm and saw it failing as well.
Although it fails with slightly different errors, my impression is, that it would pass most of the tests, if the slew call would behave as expected.

This is an excerpt from the test run:
You can see that the mount is (still) way off when the test program expects that it is already on target - just because the call returns immediately.

Are there any plans to fix this behavior and make the driver ASCOM compliant?

Please let me know if I can support you in testing or providing the full conformance log.

BTW: I really appreciated that the new StarGO driver does not need administrator rights anymore. I only saw it accidentally on the download page, may be you should announce this more prominently, as it will dramatically improve the situation on any Windows obseravtory laptop...

Best regards,
Stephan

Hi Stefano,

thanks for working on that issue! Unfortunately there are new problems now...

First: I can confirm that the synchronous SlewToCoordinates now only returns after the slew is done. So I think that is fixed.

Meanhwile I also talked to the NINA developers and they changed their code to always use SlewToCoordinatesAsync now. Unfortunately, that is kind of broken now with the latest release of your driver.
I also adapted my test program to investigate and the problem is that immediately after performing SlewToCoordinatesAsync the Slewing property is false. So any code that checks that property in order to wait until slewing is done will now just continue. In the NINA nightlies, this now occurs as well.

I also started the ASCOM conformance tool and it failed with strange errors right at the beginning which I didn't see with the old driver. Could you successfully run it?

Besides the software issues I also noticed, that the mount does a lot of minor forward/backward corrections now at the end of each slew. This seems to be new behavior.

I will attach my simple test program which shows that Slewing is false after SlewToCoordinatesAsync despite the mount is still slewing.

You can start it with:
cscript slewtest.js
(Note that you have to rename it to slewtest.js which I had to change to .txt for uploading.)



Best regards,
Stephan

Hi Stefano,

I now reverted back to the previous version:
StarGo 6.5.11
Firmware 6.2.0
Ascom Driver 6.8.4.3

But I'm still having those strange movements short before the slew finishes. Both axis seem to overshoot and then go a few times back and forth until they settle on the final position.

I never had that before and I think it was introduced with the beta version, which I now fully reverted. But it is still there.

Regards,
Stephan

Just a quick update: after restoring the mount settings using the provided mcf file, the strange movement was gone. In my first attempt I saved and restored the mount settings into my own settings file, somehow that seems to have failed.
However, the problem with the Beta version and the wrong Slewing state is independent from this issue and still exists.