Hi Jasem,

I have recompiled the driver as you have suggested, but unfortunately the dome still will not slave beyond the first movement after unparking the mount. It does move to slave after pressing abort as before.
I have attached the full log file of a short test.

However, the STOP command is now recognised as the snip from the log below shows.

[2020-01-12T14:56:44.707 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P304> with value <304> "
[2020-01-12T14:56:44.962 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P234> with value <234> "
[2020-01-12T14:56:45.218 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P184> with value <184> "
[2020-01-12T14:56:45.476 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P156> with value <156> "
[2020-01-12T14:56:45.733 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <STOP> with value <STOP> "
[2020-01-12T14:56:45.734 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome reached target position. "
[2020-01-12T14:56:45.734 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is tracking."

After the abort button is pressed, ekos reports the "Dome is idle" and it then immediately moves to target, as in the snip below.

[2020-01-12T14:59:38.099 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@SWR> "
[2020-01-12T14:59:38.102 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <STOPHstop 0:SER,14523,0,53900,0,300> "
[2020-01-12T14:59:38.102 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is idle."

I also note I have about 25 lines of this error on starting up before the GPS driver is detected, and this may, or may not, be relevant:

[2020-01-12T14:54:30.792 GMT INFO ][ org.kde.kstars.ekos] - "EQMod Mount is online."
[2020-01-12T14:54:30.947 GMT WARN ][ default] - qrc:/qml/mount/mountbox.qml:274: ReferenceError: xi18n is not defined
Several lines removed
[2020-01-12T14:54:30.948 GMT WARN ][ default] - qrc:/qml/mount/mountbox.qml:695: ReferenceError: xi18n is not defined
[2020-01-12T14:54:30.963 GMT INFO ][ org.kde.kstars.ekos.mount] - "GPS driver detected. KStars and mount time and location settings are now synced to the GPS driver."

Happy to try anything else.

Many thanks

Mark

I experienced the same issue (or a very similar one) with my MaxDome II. So, seems the problem may be is in the Dome base class.

My ScopeDome slaved fine last night with current git head versions so the base class isn't totally broken at least.

Did you find a solution? I’m having what seems like a similar problem, but as I’m connected to a Paramount via TCP I am not sure that perhaps it’s a bug there.

I can confirm the problem seems to still be there - I've done a pull of the latest binaries for Raspberry Pi using the native client connected to a Paramount ME via TCP. I'd love to test on my direct connect EQ8-R but it's dead

Did anyone ever figure this out?

I've attached a screen shot - the problem seems to be consistent with the idea that the driver is in a state where it believes the mount to be waiting on the completion of a command.

Did you have a chance to look into that? Can this be replicated with Dome Simulator?

hola Jassem - I was using the simulator up until the dome arrived last week - so that did not appear to be a problem ie: the base class would appear to be healthy

The symptoms appear as the Dome tab showing a static azimuth position angle (ie: the digits in tab do not change) and nor does the shutter track the mount until the Abort button is pressed at which point the angle updates and the dome rotates as expected HOWEVER it remains at the new poison until the Abort command is issued again - and again and again, you get the idea. Otherwise it works great!

I would send the logs, but I am still having the odd behaviour with INDI/EKOS not writing log files to my Stellarmate - go figure.

Sorry to over communicate but I'm doing testing as I am replying. Tonight's a cloudy night so I thought I'd head to bed and just ran the manual shutdown procedure from the Sequence manager and it parked the mount fine, but the dome would not park until I hit Abort in the Observatory tab, so it would appear that a command is not registering as finishing and EKOS goes into a wait state until the Abort clears the last command.

Hi, these are exactly the same symptoms I was experiencing.
I gave up looking at the code in the end, and compiled the grozzie V1.0 driver from source as I knew it worked ok(ish) and th
E slaving works fine. It's still a bit flakey and not as good as Tim Long's V3.x code, but slaving works at least. If the issue really is in the Base class you would think the v1 driver would be affected in the same way. If you do decide to use the old driver don't forget the firmware on both shutter and rotator need to be flashed to match the driver. I also had to clear the eeprom and re-program the xbees as Tim uses a different method to program these from the previous drivers.

If it is ever resolved I would go back to the new drivers though.

Mark

Did you log a defect on Github?

No, but Jasem is aware of the issue. Apparently it has also affected some Baader and Maxdome ii users. Which is why he thinks it is in the Base class I believe.

Thanks Mark - I'll log one just for completeness sake. I had a look at the protocol here github.com/nexdome/ASCOM/wiki/Firmware-Protocol and can't see any reference to a STOP message even being something to expect. From what I can see, STOP would be the equivalent of a "Sdddd" message. I'll have a look at the ASCOM driver ) which is working fine) and see if I can figure it out.