×

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

Bi-monthly release with minor bug fixes and improvements

"Dome parking / Telescope parking" policy

  • Posts: 2247
  • Thank you received: 223
I believe that the 'parking the scope' function isn't working while in the following situation:

EQmod: Dome parking policy set to: Both
Dome: Telescope parking policy set to: Telescope locks

Dome is open, scope is unparked. I issue a park for the dome, in theory it should park the scope then park the dome. However this does not work as intended.

Dome: "2020-02-16T13:51:31: [WARNING] Cannot close dome when mount is locking. See: Telescope parkng policy, in options tab "
EQmod: "2020-02-16T13:51:21: [INFO] Mount is unparked. " <-- mount hasn't parked despite the policy set to Both
"2020-02-16T13:53:25: [INFO] Warning: Dome parking policy set to: Both. This disallows the scope from unparking when dome is parked, and tells scope to park if dome is parking. This will disable the locking for dome parking, EVEN IF MOUNT PARKING FAILS. "

Also tried with the simulators, it's not working.

ekos 3.4.0
indi 1.8.3
4 years 1 month ago #49578

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

  • Posts: 2247
  • Thank you received: 223
I thought it was my roof driver so I have tried with the simulators and the desired action is not working.
The mount does not park automatically, stoping the roof/dome from parking.





4 years 1 month ago #49672
Attachments:

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

Ok I can confirm this... do we have a matrix of the different combination of the policies between the two devices and what they can lead do? If not, it would be greatly appreciated if you can draft the the table for this to clarify it for us and end users.
The following user(s) said Thank You: Craig
4 years 3 weeks ago #49992

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

  • Posts: 2247
  • Thank you received: 223
4 years 3 weeks ago #49997

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

So this has been broken for over 2 years now :(
4 years 3 weeks ago #49998

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

  • Posts: 2247
  • Thank you received: 223
4 years 3 weeks ago #50000

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

  • Posts: 294
  • Thank you received: 54
As a late follow-up on this topic, I am about to complete my clamshell KStars/EKOS/INDI controlled observatory (based on Gonzothegreat), and wanted to test the appropriate mount and dome policies to make sure that no mount and dome collision would happen. I used the Dome Scripting Gateway driver.

As the mount unpark was working correctly when both mount and dome were parked, I only tested dome park when mount was not parked. I positionned the mount close but not at its park position such as if the dome was closed (parked) no collision would occur.

I tested the following 2 conditions:

1. Mount Locks - Dome Both

After issuing a dome park command, the dome parked first and the mount parked after the dome was closed. So, unless your mount is in a position that would avoid collision, there will likely be damage to mount and scope, as mentionned in Gonzo's case study.

2. Mount Locks - Dome Locks

After issuing a dome park command, the dome parked first and the mount did not park after the dome was closed, it was still tracking. as in the previous case, unless your mount is in a position that would avoid collision, there will likely be damage to mount and scope, but furthermore, as the mount is still tracking, damage will ultimately occur.

I understand the mount should explicitely be parked before the dome is but I assume the safest sequence should be that if a dome park command is issued, it should make sure that the mount is parked first before parking the dome, and if not, it should tell the mount driver to park the mount before it parks the dome. I realize the the python scripts may need to do the appropriate checking but I thought that INDI was taking care of that.

Hope this helps.
The following user(s) said Thank You: Jasem Mutlaq
3 years 10 months ago #52584

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

INDI drivers should take care of that. I figured someone would take a look at the code and propose a fix for this but this hasn't happened yet. I added this to my TODO list so we'll see.
3 years 10 months ago #52585

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

  • Posts: 294
  • Thank you received: 54
Is the code related to parking policy in the specific mount and dome drivers (i.e. lx200_OnStep and Dome Scripting Gateway in my case) or somewhere else in the indiserver? Had a look in dome_script.cpp and lx200_OnStep.cpp but did not find anything obvious regarding parking policy.
3 years 10 months ago #52603

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

No, it's in the parent classes INDI::Telescope and INDI::Dome
The following user(s) said Thank You: Gilles Gagnon
3 years 10 months ago #52654

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

Ok, I think we need to come up with a matrix of all possible actions and what needs to be done between the dome/mount so that it can be coded safely to handle all possible conditions . Maybe a google sheet?
3 years 10 months ago #52665

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

  • Posts: 294
  • Thank you received: 54
I think that if we want to come up with a matrix of all permitted combinations, we need to also specify a dome/roof type as, depending of the type, parking will either likely cause damage (roof, ROR or clamshell) or not (hemispherical dome, where there is no mount movement restriction) and as such parking policy combinations may be allowed or not (e.g. for a roof the combination "Dome Locks - Ignore Telescope" shall not be allowed). That also means that the DOME driver will need to have a DOME type option added. Does that make sense to you?
3 years 10 months ago #52668

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

Time to create page: 0.494 seconds