Ok good. The slaving issue is a bit harder to figure out as the movement state should now be correct. Could you take logs of both the dome and scope for this sequence:

- starting both from park state
- unpark dome
- unpark scope, dome might move to match the scope azimuth, wait until it reaches target
- slew to somewhere south-west-ish
- wait until scope is idle and if dome doesn't move with the scope, hit abort if that helps
- wait until both scope and dome are idle
- slew to somewhere south-east-ish (scope should flip, dome shouldn't go around but use the shorter route)
- again wait until scope is idle and hopefully dome has followed
- park scope first, wait until it has parked and then park dome

The KStars log would be nicest as it has both device logs in the same file and in correct order, but separate logs work too.

Thanks!

Basically no change.

After opening the shutter, I aborted the dome. When I connected and unparked the tel-sim, the dome went to the scope az. After that, I had to abort the dome before moving the scope if I wanted the dome to follow automatically.

The dome log is partial. For some reason, the log Enable gets reset by I don't know what. I have to remember to go back and check on it every once in a while.

If you run KStars/Ekos, it overrides the logging settings done via INDI panel, which is a bit confusing, but you should enable them from the Ekos logging panel:

Did you want me to make another test run using the combined Ekos logs before you made a code update?

Yes please, it seems you forgot to attach the log earlier. The combined log is more useful as it helps to see both sides of the snooping and what they were doing at what time.

Here you go.

Ekos complained at first that it needed a CCD in order to function. I added an SX camera that crashed the system (more on that later), then did the obvious and added a Simulated Cam.

Dome was unparked when it started. When I unparked the Tel Sim the dome went immediately to its position.

After syncing the dome with the Tel Sim, had to Abort the dome if I wanted the dome to automatically track the Tel Sim on its next move. Dome took the short way around when scope did a meridian flip.

When I parked the Tel Sim, the dome did not follow.

I was wondering if you could help me with the following: I want to do some autofocusing tests using an SX-CCD camera. However, when I add the camera, or an SX filter wheel, or a Celestron mount, the INDI control panel or Ekos crashes. I had erased the Projects directory in my home partition, did a reload of the INDI software from the repository, and no luck. I created another user and have the same problem.

Somehow I've "corrupted" the system doing the dome tests. Any idea on how to proceed?

Thanks

Thanks I'll have a look and try to figure out why the dome doesn't want to move more than once without abort. Dome not following when parking the mount is a feature, it only follows the mount when it's unparked, not while parking or being parked.

As for the SX and other 3rd-party drivers crashing the issue most probably is that they have been compiled against an older INDI base library version and it has changed quite a bit in the recent weeks. So they would have to be recompiled against the same version you have compiled with the DDW driver. Fortunately that is also quite straight forward CMake project though the repository is now separate from the main one. Instructions you can follow are on the same page indilib.org/forum/general/210-howto-buil...st-libindi-ekos.html but it's similar to how you have compiled this driver, just create a separate build directory and point cmake to either the indi-3rdparty repo root to build all drivers (or disable the ones you don't want with cmake-gui for example) or you can create a separate build directory for each and point cmake to indi-3rdparty/indi-sx for example.

I think the reason the dome moved the first time is that it was already idle. The dome was sitting there waiting for the scope to move; there was no dome motion to abort.

I'll give the software solution a try. There is another computer with INDI / Ekos / KStars loaded where selecting an SX CCD does not cause a problem. I never used that computer for the code debug.

Found a stupid mistake I made in the previous version when I cleaned the state transition handling when controller completes the move command (and shutter operation too) that I accidentally overwrote the previous state too early. So here goes, hoping this finally fixes the slaving issue. Again pushed to github.com/jpaana/indi/tree/ddw_state_fix_again and github.com/indilib/indi/pull/1351

Looks good to me. Dome followed without any prompting.

The one thing I remembered to do is, after the dome synced with the scope, I watched long enough for the dome to start making small movements as the scope tracked.

Excellent, thank you! I think the driver is now in complete enough state to be useful to people. If there are things you notice that would be nice to have or fix, feel free to ask. There is some functionality I didn't expose like weather information (which in your data seemed to be missing anyway) and rotating the dome CW/CCW like the hand controller does or emulating relative moves, but probably not important enough to bother at this point. Hopefully I'll get to our club observatory at some point to use this as well

Jarno,

A little over 6 months ago I helped you debug a driver for Digital Dome Works. In the interim I've had a lot of trouble with my dome. Nothing to do with the driver.

The dome is working again, for now. I've been doing some observations with the dome synched to the scope and it would seem that the variable OTA offset is not being processed when positioning the slit. OTA offset is the distance in German mounts from the axes center to the center of the OTA. When running Ekos/INDI I can put in crazy numbers for this variable and it has no effect on the dome azimuth.

Do you know if OTA offset is being processed by the DDW driver?

Thanks,
Bob