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

Hi Stefano,

I now installed the Beta version (together with the firmware update) for the third time.
The problem I reported after trying the Beta for the first time still exists. It had nothing to do with updating the mount configuration.
The conformance test could be run after I correctly initialized the mount settings. But I also see results in the test that are reported as INFO but still make me a little bit nervous.
Those inaccuracies (expected vs. actual) seem pretty large to me:
Anyway, the test program I uploaded earlier and the current nightlies of NINA show the same behaviour, which I already explained. The problem is that the SlewToCoordinatesAsync command returns WITHOUT having set the Slewing property to True.
So any program that queries that property as the next command (which is very likely!) will fail, because the mount is still slewing!
I added a small delay (500ms) before checking the Slewing property and then it works. That clearly shows, that the driver updates the Slewing property too late. It must definitely set it to True BEFORE returning from the SlewToCoordinatesAsync call.

So, again: the latest Beta (656_B2) version fixes the original problem for the SlewToCoordinates call but introduces a similar error for the SlewToCoordinatesAsync command.

Regards,
Stephan

Hello,
I also experience the same strange movements as Stephan wrote (...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...)
As I wrote in
www.avalon-instruments.com/forum/install...b2-656-18-fw-656#601
I could not open my old mount configuration files. As Stefano recommended I opened and modified the standard mcf but the back and forth movements still remain, even when parking the mount.
Tomorrow I´ll redo = start from scratch again with an "empty" mcf and´ll update.
Peter

update:
I deinstalled StarGo and deleted the MCF folder (c:/ProgramData/...). After a clean reinstall (as Administrator) there is no MCF folder created anymore. StarGo is NOT running as Admin, as recommended.
After activating "run as Admin." (StarGo) the MCF folder is now created.
So it still makes a difference in the behaviour if you run StarGo as Admin or not.
opening the default MCF (as mentioned above) stopped finally the strange movements at the end of a Goto; but only after several trials.
Confusing.
...
update:
I had to go back to 6.2.0 SP6. Some of the problems I had are listed here:
- it does make a difference if one checks "Run as Admin." or not
- the ASCOM "window" is always present; the display concerning tracking and keypad enable/disable is inconsistent with that of the StarGo
- one cannot minimize the StarGo window
- even if all previous settings and mount config. files are deleted (..ProgramData/Avalon) and even after a firmware reload the old settings remain stored in the StarGo, there is no clean re-install - in my case
- guiding was impossible (MGEN II, ST4) without the keypad installed even if checked "disable keypad" - this took me a long time to realize
@ Avalon: can you please fix that bug? In some cases it is better to work without the keypad (cable....)

thanks Peter

Hi Stefano,
thank you very much for your detailed answer!
- see my answers after the quotes:

The latest Windows update changed the Operative System folder privileges managment, this was the reason why we had to change as well the MCF folder path, and why we now recommend to install the software without administrator privileges.
- that´s what I did
- I´ll redo that: install without admin. privileges AND run without admin. privileges
(we had a few of those rare clear nights here so I needed a stable system and didnt have the time to experiment)

We are making some test on the latest StarGo Software/Firmware version to check the behaviour noticed.
- great!

From our test, even installing the software without administrator privileges, the folder is created.
- not in my case, this is strange. The folder was created only AFTER running StarGo with admin privileges in my case

If this folder is not visible, should be activated as explained at the following link
answers.microsoft.com/en-us/windows/foru...c9-97d1-39e0a36de0b4
- clear, yes, I know

Opening the Standard Mount Configuration file stopped the strange movements because, in the latest software release, some motor ramp values has been modified, so, the mount, in order to work properly, should be controlled by a MCF file with the motor ramp value updated.
That’s why, after the upgrade, must be uploaded the standard MCF of the corresponding mount, and then, adjusted the user parameter on depending on his needs.
- yes; I loaded the default new M Uno MCF and modified it

It is also true that after a software/firmware update, some parameters, as, for example, the OBSERVATORY LOCATION, remain stored.
- okay, thanks.

However, why did you have to go back to the 6.2.0 SP6 version?
- I was looking for a stable system and thought going back was the solution; maybe I made I mistake during installation or loading the MCF

In the latest 656 B, the ASCOM panel and the StarGo window can be minimized.
- not in may case; it is not possible to minimize them; (they only disappear when one activates a different app / program)
- It´s a W10 64bit MiniX PC controlled remotely by a ThinkPad 13" with only 1366 x 768 resolution; but I dont think the small screen is the reason.

Furthermore, we performed a test with the StarGo 6.2.0 SP6 version and with the cable directly connected from the guide camera to the StarGo ST4 port, by using a PC and PHD2 Software, in order to check the ST4 behaviour. Even when the keypad cable is not plugged and without the “disable keypad” option enabled, the system correctly receive the pulse guide.
So, in order to better understand the behaviour noticed, please let us know more precisely how are you working: are you using the MGENII as a stand alone solution, without the use of a PC?
- I am using APT and the MGEN II as a standalone solution but connected to the PC; APT can control the MGEN (start / stop guiding; showing the guiding graph etc.); the MGEN´s ST4 output is connected to the M Uno´s ST4 port. I double checked all cables and checked the MGEN also with a M Zero - I do remember a similar behaviour in the past when the keypad was not installed on the M Zero but actually did not test guiding or calibration with that mount. I checked the MGEn in manual mode with the M Zero (one hears the changing sound of the motor drives) - with the M Uno I was not really shure to hear a difference when I had the issue. ( I´ll do that after the rain stops here)

At the beginning of a session I do a star search and calibration and do start guiding manually either on the MGEN itself or via the MGEN App. When guiding is started I let APT take over the control of the MGEN and then I start imaging with APT.
There were sessions without any problem when the keypad was disabled and not installed. But when that issue comes I have to connect the keypad, that is my experience.

Thanks in advance for your support!
Peter