×

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

Bi-monthly release with minor bug fixes and improvements

Indi_asi and indi_xagyl_wheel not playing nice.

  • Posts: 257
  • Thank you received: 22
I've been working on an indi compatable diy motorized filter wheel. My unit uses an arduino nano that emulates the xagyl filter wheel usb protocol. It works well when using the ccd and mount simulator drivers, but when I connected with real hardware I could not change the filter names or move the wheel.

Unrelated: Also appears to be a missing field in the asi driver. Any Ideas?

2018-02-23T16:42:09: Client 0: new arrival from 10.0.0.32:43006 - welcome!
*** stack smashing detected ***: terminated
Child process 3844 died
2018-02-23T16:42:13: Driver indi_xagyl_wheel: stderr EOF
2018-02-23T16:42:13: Driver indi_xagyl_wheel: restart #1
2018-02-23T16:42:13: Driver indi_xagyl_wheel: pid=3864 rfd=3 wfd=14 efd=17
2018-02-23T16:42:44: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI178MM.CCD_CONTROLS
2018-02-23T16:42:48: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI178MM.CCD_CONTROLS
2018-02-23T16:43:12: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI120MC-S.CCD_CONTROLS
2018-02-23T16:43:13: Driver indi_asi_ccd: No INumber 'Gamma' in ZWO CCD ASI120MC-S.CCD_CONTROLS
2018-02-23T16:43:13: Driver indi_asi_ccd: snooping on XAGYL Wheel.FILTER_SLOT
2018-02-23T16:43:13: Driver indi_asi_ccd: snooping on XAGYL Wheel.FILTER_NAME
2018-02-23T16:43:21: Driver indi_xagyl_wheel: indi_xagyl_wheel dispatch error: Property FILTER_NAME is not defined in XAGYL Wheel.

[UPDATE]: The solution to this was to make sure any changes to DIY firmware sending to the driver does not send too long a string. In my case it was a long name I gave the firmware and was sending as response to serial number info request. Too long a string can overrun the buffer and in ARM systems, and I suspect later possibly intel as well, this will trigger a "canary" and produce the above lockout. Search for "stack smashing detection" for more info.
Last edit: 5 years 11 months ago by Ray Wells. Reason: added solution
6 years 1 month ago #23578

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

  • Posts: 298
  • Thank you received: 46
Hi,

I don't know if it has anything to do with the file "~./indi/XAGYL Wheel_config.xml" but you could take a look at my config file, just remove the .txt at the end of the filename.

Br
/Markku

File Attachment:

File Name: XAGYLWheel....xml.txt
File Size:3 KB
6 years 1 month ago #23581
Attachments:

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

  • Posts: 257
  • Thank you received: 22
Yeah I totally forgot about asking you how this went. :P I'll check it out. Thanks!
6 years 1 month ago #23582

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

  • Posts: 257
  • Thank you received: 22
It does appear to be related and that XML file had the info like I saw when I had it on the desk, but the driver on the pi isn't loading it for some reason. I brought it back upstairs and it ran on the first try with the identical XML so it looks like a build problem of some sort on the pi. The stack message is a compiled c error meaning something similar to buffer overrun, something is bigger than the storage set aside for it. I saved the broken config and then read the changes. It shows filter slot 1 but none of the names. They have been removed from the file even though I had just saved a full version minutes before. I tried this several different ways and it looks like the driver is stripping or not reading these fields properly for some reason.
More as I get it.

At least it's raining gain.

</newSwitchVector>
<newNumberVector device='XAGYL Wheel' name='FILTER_SLOT'>
<oneNumber name='FILTER_SLOT_VALUE'>
1
</oneNumber>
</newNumberVector>
<newTextVector device='' name=''> <-this is borked.
</newTextVector>
Last edit: 6 years 1 month ago by Ray Wells.
6 years 1 month ago #23597

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

  • Posts: 298
  • Thank you received: 46
I just checked the ppa and it seems there have been an update for some hours ago, so maybe you could do an update, the xagyl driver was not included in this update but the trick to rolling back to an older version works fine so far.
Looks a bit strange.. but if you edit the xml-file manually using nano from commandline does it work then ?? or does the file get corrupted when you do a "Save" from indi controlpanel ??
6 years 1 month ago #23613

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

  • Posts: 257
  • Thank you received: 22
I did try that and verified the file was intact before load, loaded specifically and then the file gets corrupted on save. It's only on my rpi3 though. I have not updated my pc since I started troubleshooting so I'd have a working model to compare to. I stripped the pi of indi completely and re-cloned git, then ran into build errors...a stupid dynamically attached library again that is installed and "not found". I'll have to hunt down the version it needs before I can continue. Meantime I'll try an updated ppa install. I was THIS close to having it all working. The focus module now has the 1000 limit again..(boggle)
I'm going to excuse myself from "daily" if I ever get it all to go at once.


edit: yep. Clean install from ppa also breaks. I'll see if I can get an older version.
Last edit: 6 years 1 month ago by Ray Wells.
6 years 1 month ago #23618

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

  • Posts: 298
  • Thank you received: 46
I did a check and found that there is a difference on my Rpi3 when I do a Save..
This is what I get now when saving:
<INDIDriver>
<newSwitchVector device="XAGYL Wheel" name="DEBUG">
<oneSwitch name="ENABLE">
Off
</oneSwitch>

And this is what I had before:

<INDIDriver>
<newSwitchVector device='XAGYL Wheel' name='DEBUG'>
<oneSwitch name='ENABLE'>
Off
</oneSwitch>

No big difference and the only thing I could see is 6 spaces before the value or no spaces before a value, but otherwise the xml-file looks the same without any corruption.
I used to compile everything myself but using the ppa is more convenient even if there is some problems caused by the ppa sometimes.
6 years 1 month ago #23621

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

  • Posts: 257
  • Thank you received: 22
I hunted and hunted for something wrong with the driver or xml read and finally even started an issue at git and asked Jasem about it. He agreed it was a crash. I fiddled around trying to get gdb to give up the answer and did some testing on an intel machine which works looking to compare the two to find it. Since it worked on Intel but not Arm processors I started looking into compiler stuff and found the answer.
***I changed -D CMAKE_BUILD_TYPE="Debug" to ..."Release". And poof! Working driver. ***

I got the instructions from INSTALL and never questioned that line. I am now questioning that line. :D My guess is there was a mismatched missing or otherwise doinked debug symbol that wasn't showing up when I compiled. Of course now I'm expecting at least 3 inches of snow. ;)
Thanks for helping!

[edit: or not... it populated the lists but then crashed when I tried to get everything going. ] this is crazy.
Last edit: 6 years 1 week ago by Ray Wells.
6 years 1 week ago #24318

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

  • Posts: 257
  • Thank you received: 22
I finally nailed it down. TLDR - an oversized serial response to a command was being mishandled by the driver, but only in the arm system which compiled with buffer overrun(stack smashing detection) hack protection.

After running round and round and gathering info, researching the weird error message, groveling a bit and even begging for help, I finally had enough info to realize that though it wasn't failing on the Intel system and was on the Odroid, the key clue and common element was that the failure happened consistently on connect. With this in mind I supposed that it must be mishandling the serial command responses somehow so I started commenting them out one by one until I finally found where I had cheekily change the serial number response to be a long name and version of the emulator. So I shortened that and :woohoo: it worked!
Thanks again to everyone who helped along the way! And @knro, you might want to put a parse limit on filter wheel serial responses to prevent actual stack smashing from evil minded telescopes. :evil:
5 years 11 months ago #24859

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

  • Posts: 298
  • Thank you received: 46
Hi,
Hmm, now when I think of that I remember changing the "Firmware version" to 3.1.5 before I got it to work, but I still use my own Serial number and never got a problem with that on RPi3 so maybe the compiler does something different then?

Glad you have it working now!
Clear skies!
5 years 11 months ago #24861

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

  • Posts: 257
  • Thank you received: 22
Thanks! the hard part was that it worked on Intel machines and it wasn't until I installed it on an ARM based system that the problem showed up. Compiler newness I guess.
The indi driver tests for the version as part of handshaking so that has to stay the same, but using the serial# as a way to identify custom firmware version was a great idea, and I used it too. My mistake was making the name too long.
Last edit: 5 years 11 months ago by Ray Wells.
5 years 11 months ago #25288

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

Time to create page: 0.686 seconds