I tried to connect with ScopeDome's Arduino controller. It's a new system mounted in June, I use INDI 1.9.1. It includes only engines control system, we have our own dome.
I configured KStars device manager and it opens ScopeDome driver window to set up connection. However when I try to start communication with Arduino, driver crashes. Server prints in log:
<code>
2021-08-23T12:05:25: Driver ./indi_scopedome_dome: Impossible ISState 144
</code>
Hm, unfortunately the log doesn't quite tell me enough to pinpoint the issue, it seems to be sending dome steps per revolution calibration value to the client, but I can't think of a reason why the ISState would be invalid in that case. Enabling driver debug logging from Ekos might show a bit more, but I fear it would need a bit more debug prints or running under debugger to find the issue. Have you compiled the driver (and INDI) yourself or are you using PPA package?
Thank you for reply. I compiled the driver myself on Raspbian (Buster-based). I also launched another server on my notebook with Arch Linux and INDI 1.9.1, to perform independent tests. In both cases results were similar. I'll try to collect more data in log.
Thank you, especially out.log looks interesting, everything seems to go normally, the dome connects and commands seem to get valid data, but then it just dies.
I have amazing news. I compiled binaries with CMAKE_BUILD_TYPE=Debug to join debug symbols. Now connection with dome works (without and with gdb's control)! I'll try to move dome tomorrow (I work remote and have to wait for somebody to observe motion). Anyway debugger didn't detect crash in release case (simply switch directly to new instance) but that's not the most interesting thing. I noted that debug binaries are SMALLER than them release versions, e.g. "indiserver" uses 115KB as debug and 245KB as release. It looks for some global problem with INDI build system.
Thanks, that is useful information, I usually run Debug builds, have to try with Release too. The binary sizes are in line with what I have on x64 and ARM, release version does inline a lot more stuff (it uses -O3 optimization level by default) which causes the size to balloon quite a bit. Optimizing for size (CMAKE_BUILD_TYPE=MinSizeRel) might actually be better in that case.