×

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

Bi-monthly release with minor bug fixes and improvements

Cannot connect to 2m Scopedome / Arduino

  • Posts: 35
  • Thank you received: 0
HI

just checked , in fact configuration is correctly saved in the file "~/.indi/ScopeDome Dome_config.xml"
(i did the test with "close on park" and "open on unpark"
but when i restart i need to manually load it, it is not automatically done, looks like the default config is loaded instead.

for the slaving i have an issue the dome is trying to find the position but turn in an endless loop, the same with absolute position
(this is working with network and scopdome windows drivers) .

Eric
2 years 10 months ago #70794

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

  • Posts: 12
  • Thank you received: 0
Hi,

I have the same behavior when trying to enable slaving or moving to an absolute position. Jarno is working on it already.

Sometimes (not every time) after updating the INDI server I had the same with saving the config. Once I got the message that there was no config even though saving the config was reported to be successful.
What worked for me in these cases:
- disconnect everything and stop the server
- delete (or rename) the config (not the default config) from .indi folder
- start the INDI server, the driver config file is created from the default config.
- connect and repeat the settings, save the config file

Next time the driver is connecting the settings should be applied correctly.

Cheers.

Gorden
2 years 10 months ago #70798

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

  • Posts: 472
  • Thank you received: 165
I found possible reason for the problem with absolute position by reading the Windows driver source and there was a mysterious negation of the azimuth encoder delta value, which would explain the symptoms. The sequence would have been such that for example when you start from the home sensor position (let's say at azimuth 0) and set absolute position target as azimuth 30. The driver would calculate that "ok, need to move 30 degrees clock-wise" and would send appropriate command and dome would move to roughly the right place. However the missing negation of the encoder delta value would mean that the driver would think that the dome actually moved 30 degrees counter clockwise to azimuth 330 and would then conclude that it needed to do a refining move (it does that to correct for over/undershooting the wanted position, which happens sometimes even with the inertia table) of 60 degrees clockwise. Then the dome would move to azimuth 90 degrees but the counter value would still go the opposite direction and the driver would think the dome is at 270 degrees and so on...

I pushed the fix which does this negation which hopefully finally would fix this. If possible, please test that if you start by homing (after which the encoder delta is 0 and position should show correctly in any case) and then moving for example 10 degrees clock-wise and check if the absolute position reported by the driver behaves correctly or exactly the wrong way.
2 years 10 months ago #70808

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

  • Posts: 35
  • Thank you received: 0
Hi Gorden
thanks for the info
did the test to remove the config files, but still the same , config file contains the right info but is not loaded
i also tried to modify the default file and when i load default config or saved config this is fine but at starting this is wrong

on my side i got no message that they were no config.

Eric
2 years 10 months ago #70829

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

  • Posts: 35
  • Thank you received: 0
HI JPANNA

did a fast test: home is well find( north direction)
when i ask absolute position 30° dome is going CW (right direction)
but after reaching 30° restart to go CCW to search around 310° and then continue to oscillate in endless loop around home

Regard
Eric
2 years 10 months ago #70831

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

  • Posts: 472
  • Thank you received: 165
Thanks for testing, I pushed some more debug prints that might help with this so you if you can do some simple testing with full debug logging on, that might help in locating the issue. Gorden also did some testing before I added the missing prints and it seems to have something to do with the refining move the driver does if the initial move over/undershoots the target and goes haywire doing that endlessly. Hopefully the added prints will tell me why.
2 years 10 months ago #70833

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

  • Posts: 472
  • Thank you received: 165
Good news is that I finally found the regression that prevented me from using this new driver version with my own USB Card 2.1 controller so at least now I can actually run the same code I'm developing :)
2 years 10 months ago #70834

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

  • Posts: 35
  • Thank you received: 0
Here is the log file

i first send command 'find home' (dome was already at home)
then set absolute position to 30°, dome went to 30°, (CW, right direction), when reach 30°, then restart CCW.
Around this position (30°) , the absolute position read was around 110° instead of 30° so probably here is the issue explaining that is restart CCW.

Eric

File Attachment:

File Name: indi_scope...3_16.log
File Size:180 KB


 
2 years 10 months ago #70841
Attachments:

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

  • Posts: 12
  • Thank you received: 0
I had the same behavior yesterday. But when I wanted to repeat the tests with the improved log capability from Jarno's latest push I found everything working okay today. Nobody could could have been more surprised than me.

Gorden
2 years 10 months ago #70842

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

  • Posts: 12
  • Thank you received: 0
This afternoon I tested the version Jarno pushed on Friday. To cut a long story short: Everything works perfectly now. Parking, slaving, finding home, shutter control...everything works.

Jarno, you did an awesome job. Thank you so much!

Eric, how does it look for you now?

Cheers,
Gorden
2 years 10 months ago #70930

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

  • Posts: 472
  • Thank you received: 165
The code is now headed for merging at github.com/indilib/indi/pull/1447 so hopefully soon you don't need to use my special branch anymore (and I don't have to keep it up with the main repo :). It's by no means "final" but I think it's suitable for merging and also I'm not aware of any regressions so it's also an improvement for us older USB Card owners.
2 years 10 months ago #71012

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

  • Posts: 472
  • Thank you received: 165
And it's now in, yay!
2 years 10 months ago #71047

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

Time to create page: 1.783 seconds