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) .
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.
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.
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.
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
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.
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
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.
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.
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.