×

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

Bi-monthly release with minor bug fixes and improvements

ScopeDome dome controller driver

  • Posts: 472
  • Thank you received: 165
In case there are other ScopeDome users around, my driver has now been added to the main INDI repository and should appear in PPA in due time. It's included in the main tree and not under 3rd-party so no new packages to install. I'd prefer any feedback and feature requests in this one thread so feel welcome to add it here. The driver has so far only been tested with my own 2M dome with controller version 2.1 using two firmware versions (3.52 and 3.70) so any additional testing is good :)

Things that are missing (in semi-random order):
- initial dome calibration (steps per revolution, inertia table generation), need to use the Windows setup utility for that
- firmware update support, also need to use Windows software for that
- support for controller versions prior to 2.1
- roll-of-roof support, currently the driver probably has assumptions that it's driving a dome, though might work to some extent
- support for second shutter
- explicit support for 3M+ domes' requirement for shutter control only at home sensor position, normal parking and unparking should work if parking position is at the home sensor position, otherwise needs manually moving to home first
- support for negative home sensor signaling
- support for automatic closing of shutter directly via the controller, there is some preliminary UI elements for it, but they don't do anything yet, can be done with INDI's autopark mechanism for weather warnings
- support for adjusting heater parameters
- simulator support, there is a stub for that but it doesn't really do anything yet
The following user(s) said Thank You: Kai Roth
Last edit: 5 years 1 month ago by Jarno Paananen.
5 years 2 months ago #34200

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

  • Posts: 4
  • Thank you received: 1
Hello Jarno,

I am writing in response to Danuvium , who had inquired about INDI implementation of the ScopeDome drivers late last year . I am happy to announce, that thanks to your work we have been able to connect our ScopeDome module to our Linux PC with little effort. Thank you very much for your work.
While we can not report on all the functionalities the box provides, all the necessary functions (e.g. dome movement and abort) are well implemented.
There are however still some problems we encounter. Most notably, the dome oftentimes overshoots its target and tries to correct for this by going back and forth until reasonably close, even with the use of an inertia table. But as the improvement is usually minimal for our dome, we would much prefer it, if the ScopeDome module would not try to correct for the overshoot. Do you happen to know, if it is possible to turn this functionality off, or to increase the threshold for the acceptable discrepancy?

With best regards,
Kai R.
The following user(s) said Thank You: Jarno Paananen
4 years 10 months ago #38681

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

  • Posts: 472
  • Thank you received: 165
Thanks, good to know it works for someone else too :)

I haven't had issues with overshoot, probably my 2M dome is light enough that there isn't much variance in inertia so the table works well. It's usually almost spot on after first move and maybe does a small nudge back, but not back and forth. I have to check but it might be that currently it tries to move to exact encoder value which is overkill and could use either the same tolerance as slaving with scope does or I could add a separate value too, maybe that would be better. I'll let you know.

Any other issues you have encountered? One thing I'm not sure if I documented is due to the controller having two encoder counters, one 16 bit and one 32 bit. The 16 bit value resets after passing home sensor and is used for azimuth calculation, but there is also a separate counter that does not reset and limits the dome rotation after a few revolutions. With my dome this later counter can go from -14000 to +14000 and one revolution is around 3400 steps. The dome just doesn't move past that counter value so I added the derotate function which moves the dome back to around value 0. So on case you encounter the situation that the dome doesn't want to rotate more to one direction, this might be the case.
4 years 10 months ago #38694

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

  • Posts: 472
  • Thank you received: 165
I checked and actually the driver already uses the "Autosync threshold (deg)" value on slaving setting page for regular movement too so increasing that should stop it from going back and forth. I have mine set to 1 degree, default is 0.5.
4 years 10 months ago #38697

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

  • Posts: 4
  • Thank you received: 1
Yes, I just tested your suggestion and can confirm that the Autosync Threshold also applies when not slaved. Our telescope would probably need a higher threshold because the amount of slip which the dome experiences seems to vary strongly with temperature.
I can also confirm the limits you spoke of, though I can not give specific numbers. Yours do definitely seem plausible, but the results I found are somewhat mixed. I could throw some numbers around but that would probably not be of much help to anyone else. The main issue here, I believe, is again that our dome slips and needs regular recalibration, depending on weather (or rather temperature) fluctuations.
There was one odd thing we found while testing. We used the INDI starter program to communicate with the module. What we found was that the "Dome CW" and "Dome CCW" buttons seem to crash the program so that one must disconnect the and reconnect in order to regain control over the client. If it helps, the terminal output can be found in the attached file. If I read the documentation correctly, I assume that is because the "DOME_CW" and "DOME_CCW" attributes are not implemented?
And I was also surprised that the dome move in CW direction if you set "DOME_RELATIVE_POSITION" to a value less than -180 deg and in CCW direction for values greater than +180 deg even though the documentation saysI assume that this is something the ScopeDome module does by itself?
I would also be very interested in an implementation of the calibration routine, since it would be a lot of work if we always had to use a Windows machine. Do you think this would be feasible?

Best regards, Kai R.
4 years 10 months ago #38723
Attachments:

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

  • Posts: 472
  • Thank you received: 165
The CW and CCW controls are implemented in the base dome class, my driver only receives relative or absolute movement commands, have to debug that a bit. I don't use the relative controls almost at all, just slaving to telescope and occasionally absolute azimuth like 0 so it's quite possible that there is something weird there.

Dome calibration and inertia table generation is definitely doable and I have source code for the Windows driver (though Visual Basic with comments in Polish :), but my own dome doesn't slip at all (it uses gear and rack to drive the rotation) and I have only calibrated it once during the two years I've used it so that hasn't been very high on my priority list :) But as there seems to be need for it, I'll have a look at that again.
4 years 10 months ago #38728

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

  • Posts: 472
  • Thank you received: 165
DOME_CW and DOME_CCW buttons indeed made the dome base class try to call unimplemented method in the driver class causing call back to the base class instead and infinite recursion. I now implemented the function in driver version 1.1 and the buttons now work as intended. Thanks for the report, I had never tried the buttons it seems :)

The over 180 / under -180 relative motion weirdness is a side effect of the driver actually implementing relative move as (current_position + relative_motion) absolute move and that part does an optimization to go through the shorter route. I could change that to actually issue a relative move if really needed, but that would duplicate some code which I tried to avoid in the first place.
4 years 10 months ago #38741

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

  • Posts: 472
  • Thank you received: 165
Actually it was easier than I thought and better maps to how the controller actually works so I now use relative moves to implement absolute moves and not the other way around. So now relative moves are "dumb" and work the straight forward way. Absolute moves are still optimized to move the shorter way around always. Both these changes are in the same pull request for version 1.1.
4 years 10 months ago #38742

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

  • Posts: 4
  • Thank you received: 1
Nice to hear that you are putting in so much effort and work into making all this working properly. Thank you very much, Jarno.
Just to clarify, the dome we are using is several decades old, if not a century. We only use the ScopeDome USB Card to control our dome motor from the PC. It is therefore not a big surprise that our dome slips. I will discuss adressing this issue with my colleagues on Monday, but my guess is that regular recalibrations will still be required. I will keep you up to date on that if you are interested. Otherwise, I will come back to you if I find some more bugs or inconsistencies.
Again, thank you so much for all the help you have provided.
4 years 10 months ago #38765

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

  • Posts: 472
  • Thank you received: 165
Thanks, yes please, interesting to know where my code is being used. I'll see if I can get the calibration and inertia table generation done during the summer, we don't have astronomical dark at all and almost no nautical dark either at the moment so not much to do except code :)
4 years 10 months ago #38769

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

  • Posts: 472
  • Thank you received: 165
I just added simple calibration (or just command to start it, the controller itself does it) for steps per revolution to the driver on the site management page (it also shows the current steps so you can see how it changes, though I couldn't get it to change as my dome doesn't slip :) ) and made a pull request for version 1.2. Hopefully this helps at least a bit. Inertia table generation is more work and in theory just an optimization so maybe this is already enough for your case.
4 years 10 months ago #38782

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

  • Posts: 4
  • Thank you received: 1
So, to keep you up to date:
I discussed the issues with my colleagues and it was agreed that recalibration before every observation night was not a feasible strategy. We are going to concentrate on optimising the dome and motor mechanics so that it will (hopefully) not slip anymore. Though I believe that it cannot be avoided to recalibrate once in a while, so your implementation to INDI is greatly appreciated.
My supervisor said that they updated INDI just today, so I hope that we can test that and the new functions for relative motion in the coming days. I, for one, am looking forward to it :)
4 years 10 months ago #38949

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

Time to create page: 1.341 seconds