I just wanted to reach out and say thanks for all of the hard work you guys are doing. It is much appreciated.

Jim

I just ran some more tests on what I think jpaana was wanting involving the dome and mount locks. It turns out that, if I set a lock, like the dome can't park while the scope is unparked, the dome won't park regardless of whether the scope is parked or not. Ditto for the scope. If the lock is set so the scope can't move if the dome is parked, the scope won't move regardless of whether the dome is parked or unparked.

Ok thanks, that does point to some issue with snooping. There is also a small user interface gaffe that you can mix the options in such away that neither can park/unpark (setting dome to be mount locked and mount to be dome locked...). Thanks for the logs, I'll check them next.

Hm, yes it seems both drivers have snooping settings correct, but they don't seem to see each other as there aren't any lines related to snooped messages in either log. Are the drivers running under the same INDI server instance? From the logs they seemed to be two different once or was that just some testing related thing? If you run the server via command line "indiserver -v indi_ddw_dome indi_simulator_telescope" instead of starting via FIFO, does that make any difference?

I usually check the KStars logs as they have all driver debug messages nicely combined so they are shown in correct chronological order. When slaving is working you should get messages something like this (using my EQ8 and ScopeDome dome):

[2021-02-02T22:47:43.848 EET INFO ][ org.kde.kstars.indi] - EQMod Mount : "[INFO] Slewing to RA: 3:48:15 - DEC: 24:10:52 "
[2021-02-02T22:47:43.850 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Snooped Target RA-DEC: 3.8040899999999999714 "
[2021-02-02T22:47:43.850 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Snooped Target RA-DEC: 24.181100000000000705 "
[2021-02-02T22:47:43.851 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Calling Update mount to anticipate goto target: 57.0613 - DEC: 24.1811 "
[2021-02-02T22:47:43.851 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Updated telescope Az: 246.624 - Alt: 39.0706 "
[2021-02-02T22:47:43.851 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] JD: 2.45925e+06 - MSD: 5.67975 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] MC.x: -0.05 - MC.y: -0.05 MC.z: 0.2 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] HA: 3.42464 Lng: 23.2347 RA: 57.0613 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] OTA_SIDE: 1 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] OTA_OFFSET: 0.4 Lat: 61.7719 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] OC.x: -0.299718 - OC.y: 0.225313 OC.z: 0.347796 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Mount Az: 246.624 Alt: 39.0706 "
[2021-02-02T22:47:43.852 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] OV.x: -0.712644 - OV.y: -0.30804 OV.z: 0.630278 "
[2021-02-02T22:47:43.853 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] Calculated target azimuth is 274.04. MinAz: 248.95, MaxAz: 299.13 "
[2021-02-02T22:47:43.853 EET DEBG ][ org.kde.kstars.indi] - ScopeDome Dome : "[DEBUG] MoveAbs (274.040954) "

Both of these messages come from the base classes so they should work with any driver using those classes.

Well that certainly made a big difference. I was starting each one with a separate service.

I'll attach the log files but maybe a summary will provide some insight.

The "lock out flags" worked as they should. When I started the Tel Sim I forgot to tell it to snoop on DDW Dome (the default is Dome Sim), but once I set the snoop to DDW Dome all the interlocks worked as they should.

As for the pointing, once I got the hang of what was going on it fell into 3 categories.

The dome usually complained about not being able to sync with the scope. You'll see endless messages of that sort. Let's assume, as a starting point, the dome has synced with the scope.

On one occasion, as I remember, when I moved the scope to a new target, the dome followed.

For the remaining scope moves, about 40% of the time the dome would complain about not being able to sync-up and, if I hit the dome abort button, the dome would then move to the scope position.

The remaining times, after I hit abort, with no response, I would go to the Slaving page, disable slaving, then enable slaving. The dome would then move to the Tel Sim position.

An oddity is that the dome would often times not move to the exact scope az position. I know because of equatorial mounts there can be some difference when the scope is hanging off the side but I don't think that's the case here. When I pointed the scope to Polaris, the dome az moved to 354.

Scope Dome
298 298
0 354
18 13
93 97

I'll also attach my dome config numbers to see if that helps any.

Bob

Great to hear you got it to work. The issue with spamming during slaving is that the controller only allows one command to be in progress at a time and slaving code tries to send more move commands during the initial move. Currently the driver just ignores it and prints the warning and would end up in the right place eventually, but I'll add some code to keep the latest move command and queue it after the current command finishes so it should then move to the final coordinate. During normal tracking this shouldn't be an issue but slewing around would trigger it.

As for the slaving parameters, they look reasonable to me, there is a thread somewhere in this forum about finding accurate values by moving the scope to certain orientations and fine tuning the slaving parameters one by one. Pointing at the Polaris not ending up at azimuth ~0 is known, my dome does the same, I think the code calculating scope orientation assumes the scope is on either side of the pier but not on top like it would be in parking position. Hasn't bothered me so far fortunately

Great. A couple of things.

1. On the Main Control page for Tel Sim, there are three choices for the parameter On Set: Track, Slew and Sync. I've enabled Track. Hope that's right.
2. In the software provided by the makers of DDW, there is an option that basically says "Don't start moving the dome until the scope has started tracking / stopped slewing." That prevents the dome from chasing the scope nearly full circle when doing a meridian flip. I was wondering how your software handles that case.

We're getting there!

1. Yes, track is the default, it slews to the coordinates set and tracks after that, slew would only do the slew and sync would sync the mount to that point without moving at all.
2. The INDI dome slaving code only calculates the dome move from the telescope destination coordinates when starting a slew so it would only move a bit (from west side of pier to east or vice versa), not go around. At least that's how it behaves with my dome and I don't have any specific code there either, it's all in the generic code.

Let me know when you make your next drop and where to pull it.

Thanks.

It's waiting for Jasem at github.com/indilib/indi/pull/1344 but you can get it from my repo at github.com/jpaana/indi/tree/ddw_latch_move

Well, in a case of why didn't I think of this earlier ...

I downloaded you new version. When I moved the scope, there was the same hangup as before. I waited thinking the error might finally clear, but usually had to enable / disable slaving.

Then it occurred to me: why don't I abort the dome motion before moving the scope. Then all worked well. Abort the dome, move the scope, and the dome follows along.

There is still, I think, a problem with the pointing offset between the dome and tel sim azimuths. I've attached a file for pointing around the sky, plus the logs.

Cheers,
Bob