×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

ScopeDome - impossible ISState error

  • Posts: 4
  • Thank you received: 0
Hello,

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>

Full log (-vv) (updated 24.08) in an attachment.

Thanks for help and best wishes
Last edit: 2 years 7 months ago by Jakub Suchecki.
2 years 7 months ago #74782
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
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?
2 years 7 months ago #74817

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 0
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.
2 years 7 months ago #74819

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 0
Ok, I'm sending logs from KStar and from server (-vvv). It's the same session.
2 years 7 months ago #74846
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
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.

<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[DEBUG] read response: 8056"/>

2021-08-25T18:02:32: Driver ./indi_scopedome_dome: stderr EOF
<delProperty device="ScopeDome Dome"/>
2021-08-25T18:02:32: Client 0: queuing <delProperty device='ScopeDome Dome' name=''>
2021-08-25T18:02:32: Driver ./indi_scopedome_dome: restart #1

This shows the driver has crashed and indiserver restarts it.

2021-08-25T18:02:32: Driver ./indi_scopedome_dome: pid=6114 rfd=3 wfd=7 efd=8
2021-08-25T18:02:32: Client 0: sending msg copy 1 nq 9:
<message device="ScopeDome Dome" timestamp="2021-08-25T18:02:32" message="[INFO] Steps per revolution read as 8056"/>

If you can run the indiserver under gdb, that would show where the driver crashes and would help fix the issue.

The command line for gdb needs a few flags, something like: gdb --eval-command=set follow-fork-mode child --args indiserver -v ./indi_scopedome_dome

then type "run" and connect normally to indiserver and if/when the driver crashes, "where" would show the place and stack trace.
2 years 7 months ago #74855

Please Log in or Create an account to join the conversation.

  • Posts: 4
  • Thank you received: 0
Hello,

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.
2 years 7 months ago #74900

Please Log in or Create an account to join the conversation.

  • Posts: 472
  • Thank you received: 165
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.
2 years 7 months ago #74906

Please Log in or Create an account to join the conversation.

Time to create page: 3.292 seconds