×

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

Bi-monthly release with minor bug fixes and improvements

Digital Dome Works - does this work?

  • Posts: 472
  • Thank you received: 165
Yes please, it seems you forgot to attach the log earlier. The combined log is more useful as it helps to see both sides of the snooping and what they were doing at what time.
3 years 1 month ago #67084

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

  • Posts: 126
  • Thank you received: 2
Here you go.

Ekos complained at first that it needed a CCD in order to function. I added an SX camera that crashed the system (more on that later), then did the obvious and added a Simulated Cam.

Dome was unparked when it started. When I unparked the Tel Sim the dome went immediately to its position.

After syncing the dome with the Tel Sim, had to Abort the dome if I wanted the dome to automatically track the Tel Sim on its next move. Dome took the short way around when scope did a meridian flip.

When I parked the Tel Sim, the dome did not follow.

I was wondering if you could help me with the following: I want to do some autofocusing tests using an SX-CCD camera. However, when I add the camera, or an SX filter wheel, or a Celestron mount, the INDI control panel or Ekos crashes. I had erased the Projects directory in my home partition, did a reload of the INDI software from the repository, and no luck. I created another user and have the same problem.

Somehow I've "corrupted" the system doing the dome tests. Any idea on how to proceed?

Thanks
3 years 1 month ago #67085
Attachments:

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

  • Posts: 472
  • Thank you received: 165
Thanks I'll have a look and try to figure out why the dome doesn't want to move more than once without abort. Dome not following when parking the mount is a feature, it only follows the mount when it's unparked, not while parking or being parked.

As for the SX and other 3rd-party drivers crashing the issue most probably is that they have been compiled against an older INDI base library version and it has changed quite a bit in the recent weeks. So they would have to be recompiled against the same version you have compiled with the DDW driver. Fortunately that is also quite straight forward CMake project though the repository is now separate from the main one. Instructions you can follow are on the same page indilib.org/forum/general/210-howto-buil...st-libindi-ekos.html but it's similar to how you have compiled this driver, just create a separate build directory and point cmake to either the indi-3rdparty repo root to build all drivers (or disable the ones you don't want with cmake-gui for example) or you can create a separate build directory for each and point cmake to indi-3rdparty/indi-sx for example.
3 years 1 month ago #67086

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

  • Posts: 126
  • Thank you received: 2
I think the reason the dome moved the first time is that it was already idle. The dome was sitting there waiting for the scope to move; there was no dome motion to abort.

I'll give the software solution a try. There is another computer with INDI / Ekos / KStars loaded where selecting an SX CCD does not cause a problem. I never used that computer for the code debug.
3 years 1 month ago #67088

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

  • Posts: 472
  • Thank you received: 165
Found a stupid mistake I made in the previous version when I cleaned the state transition handling when controller completes the move command (and shutter operation too) that I accidentally overwrote the previous state too early. So here goes, hoping this finally fixes the slaving issue. Again pushed to github.com/jpaana/indi/tree/ddw_state_fix_again and github.com/indilib/indi/pull/1351
3 years 1 month ago #67089

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

  • Posts: 126
  • Thank you received: 2
Looks good to me. Dome followed without any prompting.

The one thing I remembered to do is, after the dome synced with the scope, I watched long enough for the dome to start making small movements as the scope tracked.
3 years 1 month ago #67094
Attachments:

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

  • Posts: 472
  • Thank you received: 165
Excellent, thank you! I think the driver is now in complete enough state to be useful to people. If there are things you notice that would be nice to have or fix, feel free to ask. There is some functionality I didn't expose like weather information (which in your data seemed to be missing anyway) and rotating the dome CW/CCW like the hand controller does or emulating relative moves, but probably not important enough to bother at this point. Hopefully I'll get to our club observatory at some point to use this as well :)
3 years 1 month ago #67114

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

  • Posts: 126
  • Thank you received: 2
Jarno,

A little over 6 months ago I helped you debug a driver for Digital Dome Works. In the interim I've had a lot of trouble with my dome. Nothing to do with the driver.

The dome is working again, for now. I've been doing some observations with the dome synched to the scope and it would seem that the variable OTA offset is not being processed when positioning the slit. OTA offset is the distance in German mounts from the axes center to the center of the OTA. When running Ekos/INDI I can put in crazy numbers for this variable and it has no effect on the dome azimuth.

Do you know if OTA offset is being processed by the DDW driver?

Thanks,
Bob
2 years 5 months ago #76267

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

  • Posts: 472
  • Thank you received: 165
Syncing dome to the scope is all handled by the base INDI Dome class, the driver only sees commands to move to absolute azimuth angle. With my ScopeDome dome OTA offset definitely does have an effect and is critical for successful syncing. It's easy to see by slewing to near the meridian and near horizon so that the mount is sideways and not upright like in park position towards the pole.
2 years 5 months ago #76326

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

  • Posts: 126
  • Thank you received: 2
Thanks. It's definitely not working for me.

For example, a couple of nights ago, I was pointing at Polaris which was at its east extreme in the loop it makes around the pole. The computed dome azimuth was 0.6 deg but because the scope was hanging off to the east side, the az should have been more like 15. I've adjusted the OTA offset parameter but it has no effect. There have been other instances where I walk out to the dome and I can see that the shutter is aligned with the pier but the scope is hanging off to the side and partially blocked.

I'll give it another shot and see what happens.

CS,
Bob
2 years 5 months ago #76334

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

  • Posts: 126
  • Thank you received: 2
My fault. I've been bitten by this before. In the Dome Slaving tab, I had the Meridian Side set to Ignore which, of course is wrong. When I set it to Mount, then scope and dome aligned.

I can see another yellow sticky on my control room wall. If scope and dome don't sync, check the Meridian setting.

Cheers,
Bob
2 years 5 months ago #76340

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

  • Posts: 472
  • Thank you received: 165
Heh, good that it was solved, yes the ignore setting is for fork mounts and such which don't require any special pier side handling.
2 years 5 months ago #76353

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

Time to create page: 1.026 seconds