Hello Jasem,
I have looked everywhere but I can't see anyone else having this issue.
I automated my Pulsar dome last year using the same Stepper motors/drivers and Arduino Leonardo/Xbee arrangement as NexDome explicitly in order to use the INDI NexDome drivers. I have had the dome hardware working and slaving well with indi/Kstars using the original v1 firmware developed by Grozzie. My mount is an AZ-EQ6GT using the eqmod mount driver.
Now INDI has moved on to the official NexDome hexfile firmware, I flashed the new v3.2.0 firmware on the rotator and shutter and both are working very well using the latest V1.4 NexDome driver , with the exception of the dome slaving to the mount.
The dome will move to slave one time after unparking the mount but not after that. Also the manual CCW and CW buttons in the driver will work once only. Until, that is, the abort button is pressed, where the dome will then move to the correct mount azimuth. Similarly the CW & CCW buttons will again move the dome once, after each abort button press. in the NexDome driver tab the following warning appears:
"2020-01-11T21:03:19: [WARNING] Please stop dome before issuing any further motion commands."
Examining the log files it appears that when the dome reaches it's target azimuth and stops moving it issues a STOP but it is interpreted as a status request instead as the response given apears to be for a @SRS command as in <:SER,7935,0,53900,0,300#> with value <7935,0,53900,0,300> " shown below. The INDI driver thinks the dome is still moving. The abort button issues a "hard stop" using the @SWR command and afterwards INDI is free to move the dome again.
An example from the log, edited for brevity, shows the mount has been slewed to azimuth 45 degrees and, following an abort button press, the dome immediately begins slaving:
[2020-01-11T15:50:36.924 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@SWR> "
[2020-01-11T15:50:36.929 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <STOPHstop 0:SER,149,0,53900,0,300> "
[2020-01-11T15:50:36.930 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is idle."
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] JD: 2.45886e+06 - MSD: 23.2189 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] MC.x: 0.03 - MC.y: 0.18 MC.z: 0.07 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] HA: -7.56305 Lng: 0.404272 RA: 102.133 "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Active Snoop, driver: EQMod Mount, property: TELESCOPE_PIER_SIDE "
[2020-01-11T15:50:36.934 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OTA_SIDE: 1 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OTA_OFFSET: 0.53 Lat: 51.5228 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OC.x: 0.240877 - OC.y: -0.200657 OC.z: -0.232541 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Mount Az: 45.452 Alt: 21.1014 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OV.x: 0.664875 - OV.y: 0.654467 OV.z: 0.360019 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Mount Az: 45.452 Alt: 21.1014 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] OV.x: 0.664875 - OV.y: 0.654467 OV.z: 0.360019 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Calculated target azimuth is 53.8915. MinAz: 45.7782, MaxAz: 62.0048 "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] CMD <@GAR,53> "
[2020-01-11T15:50:36.935 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] RES <Phase 0:right> "
[2020-01-11T15:50:36.937 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome is moving to position 53.8915 degrees... "
[2020-01-11T15:50:36.938 GMT INFO ][org.kde.kstars.ekos.observatory] - "Dome is moving clockwise..."
[2020-01-11T15:50:36.942 GMT INFO ][ org.kde.kstars.indi] - NexDome : "[INFO] Dome is syncing to position 53.8915 degrees... "
[2020-01-11T15:50:37.427 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P165> with value <165> "
[2020-01-11T15:50:37.678 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P202> with value <202> "
[2020-01-11T15:50:37.929 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P260> with value <260> "
In between steps removed
[2020-01-11T15:50:54.293 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7840> with value <7840> "
[2020-01-11T15:50:54.545 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7893> with value <7893> "
[2020-01-11T15:50:54.796 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <P7925> with value <7925> "
[2020-01-11T15:50:55.048 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <STOP> with value <TOP> "
[2020-01-11T15:50:55.550 GMT DEBG ][ org.kde.kstars.indi] - NexDome : "[DEBUG] Processing event <:SER,7935,0,53900,0,300#> with value <7935,0,53900,0,300> "
This happens repeatably after the first dome move.
I looked at the source code for the driver and in <nex_dome_constants.h> part of the file is shown below the static constants for the commands have "S" assigned to both REPORT and EMERGENCY_STOP. Since they cannot both be "S" I assume REPORT, the first assigned, will be allocated to it. I am not a programmer, and I may well be wrong, but to me this might explain logically why the stop command is interpreted as a status report request and INDI thinks the dome is still moving.
From nex_dome_constants.h :
// Command Strings
static const std::map<Commands, std::string> CommandsMap =
{
{ACCELERATION_RAMP, "A"},
{DEAD_ZONE, "D"},
{SEMANTIC_VERSION, "F"},
{GOTO_AZ, "GA"},
{GOTO_HOME, "GH"},
{HOME_POSITION, "H"},
{POSITION, "P"},
{RANGE, "R"},
{REPORT, "S"},
{EMERGENCY_STOP, "S"},
{VELOCITY, "V"},
{EEPROM, "Z"},
{OPEN_SHUTTER, "OP"},
{CLOSE_SHUTTER, "CL"},
};
I hope this helps, I have the full logs available if necessary.
Many thanks
Mark
Read More...