Oh, that's cool! The only parameter which is absent in MaximDL is shutter width (I don't see it there). All the rest is the same, so theoretically it should be right. About calibration... In pseudo-code I think it looks something like this:

dome_position_2 = dome_position_1
dome_position_1 = dome_position_1 + 179 degrees
move_dome(dome_position_1)
dome_position_1 = dome_position_1 + 2 degrees
move_dome(dome_position_1)
move_dome(dome_position_2)

I hope you understand the trick, I thought it in this way because dome can move in both directions, but we want it to move all 360 degrees only in one direction

Ok, here we go

1) Relative Position and Absolute Position are not working as expected - I give a value, but from log I can see that a very strange value is sent instead (difference between current and new one is very small). Basically, right now it's nearly not moving, just few centidegrees. Several times I saw that the last number in d#azi**** command was missing. As far as I can understand the strange values can be related to correction algorithm
2) Autosync threshold is the level of acceptable positioning error, yes?
3) There is an interesting moment with sync... After powering up the dome it replies on the d#getazim requests with d#azi****, and not d#azr****. I found the explanation - sync. After syncing ithe dome, it switches to d#azr**** format. The pseudo-code I described btw is working as expected
4) Measurements tab. As I could see it's impossible to put negative numbers for displacements (in MaximDL it is possible), but actually I need to set negative numbers in my configuration

Regarding the procedure, why can't we do:

dome_position_1 = dome_position_1 + 185 degrees

Doesn't that guarantee it will hit the south sensor?

For a simple reason - it will do 175 degrees move The dome is capable to move in CW and CCW directions, but it's not the user who decides in which direction to move, the dome decides by itself (smart bastard! )

Hmmm ok, well, test the updated driver when you can

I got today a whole bunch of terrible paper work, so most probably I will be back at testing only next week, in the second half

I am back! I can see you added calibration, which is cool! But I still have problems with movement - it is nearly stuck at one point And another thing - it is by design or it is bug that after Start / Stop service I am loosing everything at the Measurements tab? That's annoying if honestly

Stuck how? I need more details with the details log of the driver with full debug turned on. Also, I'm not sure what do you mean regarding the measurement tab values? If you connect, you can go to Options and "Load Configuration" and it will load whatever saved previously. The loading is not done automatically unless you are using Ekos and selected the load "on connection" option.

Ok, now it is clear with configuration, thank you! About getting stuck I will show you tomorrow, ok?

Sorry, I got again lot of paper work Are you now free? I got clear sky and time

Shame on me! Baader actually gave all the command set in its documentation, on the last pages... Post #2275 from page 4 is updated!

Again updated the previously mentioned post (added d#encsave command) But it is an important update - we can't be sure if we really need calibration or not. So please make it non-mandatory and add a LED which will tell the current state (calibrated/uncalibrated) based on the type of the reply to the d#getazim command (d#azr****/d#azi****)