×

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: 294
  • Thank you received: 54
As, among other things, I needed to implement fail safe features to my observatory (close call), I am (very) late with the testing of the dome and telescope parking policies which I need to finish. Sorry about that.

I can look into adding the issue to the IssueHunt to attract interest into solving the problem, hoping that it can be a rapid fix to what can be an hazardous situation, for the equipment.
3 years 8 months ago #56423

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

  • Posts: 250
  • Thank you received: 3
Sorry I got the wrong post for my answer.
Last edit: 3 years 8 months ago by Porchet.
3 years 8 months ago #56556

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

  • Posts: 2247
  • Thank you received: 223
Someone point me in the right direction of the drivers please, or code responsible for the parking. I am no coder but I can ask a friend and/or see if I can find something odd.
3 years 8 months ago #56569

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

  • Posts: 311
  • Thank you received: 42
Just took a look on the Dome side it seems like the implementation is in indidome.cpp Dome::ISSnoopDevice
Expect there will be something similar on the Telescope side. First glance it might not be so much a bug as a not implemented as assumed. Needs someone familiar enough with the code in depth to be able to make a relatively quick modification. Or time to study the interactions and use cases to not screw up actual Domes expected behavior with side effects.

Looking at it from an external view based on the work with the test cases. Can the desired behavior be described. And are any additional property values or snooping options needed to describe the rules.
3 years 8 months ago #56570

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

  • Posts: 294
  • Thank you received: 54
From what I remember when I looked at the code, there are 2 file sets (.h and .cpp) to look into. As 'wotalota' mentionned, there is "indidome.h and .cpp", as well as "inditelescope.h and .cpp", in the ".../libindi/libs/indibase/" directory, on the mount side. I could not find the way policies are executed in those files or how the park messages are passed to one another, or from another driver (e.g. weather related).

Logically, if a dome/roof park command is issued (from user or weather station), the driver should make sure that the mount is parked before parking and if not, a park command shall be issued to the mount and completed before the dome/roof is closed. From what 'Gonzothegreat' and me have observed, it seems that the order is not respected.

As I mentionned in another related thread, I unfortunately do not have the expertise to dig into the problem efficiently and come up with a solution quickly but I would hope the solution is not too far away.

Thanks for everybody's input and help.
3 years 8 months ago #56573

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

  • Posts: 311
  • Thank you received: 42
Need to test again to see that the roof respects "telescope blocks" and "auto park disable" settings. It might be that the roof could benefit from a "wait to park on the telescope being parked" option. If so that seems doable. I think the next thing to look at is the telescope snoop code. It will probably be getting information from the roof. Does it receive enough information from the roof to determine a weather alert is in effect and/or the roof would really like to close but can not until it gets itself parked. If its rule settings allow why does it not respect the "Dome parks" setting. When that is sorted then go back to the roof and make sure there is a mechanism to determine that the telescope is now parked and it can continue.
The caution comes from this being at a level above the individual mount and dome driver so any changes will possibly impact all telescope and roof characteristics.


Unless something else moves us along, I think I'll investigate along these lines and see how far I can get with this particular use-case.
Last edit: 3 years 8 months ago by wotalota.
3 years 8 months ago #56575

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

Please note that drivers cannot command other drivers. Each driver can snoop the properties of others drivers and act accordingly. So the dome/roof driver cannot tell the mount to park. One way to make this happens would maybe to use the state of the TelescopeClosedLockTP property. The mount driver can be set to listen to the dome TelescopeClosedLockTP property, and if that property is set to IPS_BUSY for example, it should signal the mount driver to begin parking process. That's one way of approaching this. Another would be to use another new property to snoop on. The mount needs to know that parking is required.

However, doesn't Ekos observatory module park mount then parks dome when weather is ALERT?
3 years 8 months ago #56586

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

  • Posts: 294
  • Thank you received: 54
Thanks for the clarification and for correcting my comment re: use of 'command' instead of 'snoop'.

So, if I get it correctly, mount and dome/roof should snoop on one another to make sure no action is taken that could create a dangerous situation. Could we use a "Collision Avoidance" snoop property that could be set for roofs (or domes) that do not have the appropriate clearance to park without problem? This could help set the correct sequence of events when unparking/parking.
3 years 8 months ago #56588

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

  • Posts: 1185
  • Thank you received: 370
Nope, the Observatory does not take care of the mount currently. I already have the UI controls in place, but the functionality is not present yet.

If I remember well, the two of us discussed it whether parking of the telescope make sense to add this to the Observatory. The decision was that we should leave it to the Scheduler. But I might be wrong...

I did the tests for the two scenarios with simulators for dome and telescope. From what I see is that the only option that makes trouble is the scope option "dome parks". It works in principle, but as already mentioned in this thread, the dome does not wait with parking until the scope is parked and is parking in parallel. That is a risky behaviour, I fully agree.

But all the other combinations seem to work as designed, but I fully agree, not all combinations make sense.

We could add two actions to the Observatory:
  • Shutdown Scheduler
  • Park mount
But here we have the old problem, that part of the users use the Scheduler, others don't. For those not using the Scheduler, it would be straight forward that the Observatory parks the mount. But those using the Scheduler I think would prefer if the Scheduler controls the Observatory and not vice versa - which as far as I remember is already working for the weather alerts.

Implementing this behaviour in the Observatory should not be that complicated - as soon as we not how we want to have it.

Wolfgang
p.s.: I've attached a spreadsheet with my test cases I've been talking of.

File Attachment:

File Name: parking_te...xlsx.zip
File Size:8 KB
3 years 8 months ago #56589
Attachments:

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

  • Posts: 250
  • Thank you received: 3
A question about a scheduled session.
How does Kstars do to trigger the action of putting the mount on Park and putting the dome on Park?
Would it be possible to simulate the same action with a weather alert.

Or the Dome driver must set the mount to Park by default before closing the roof.
3 years 8 months ago #56590

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

  • Posts: 311
  • Thank you received: 42
Thanks for the TelescopeClosedLockTP property info.

The initial impression is that the Observatory closes the Dome and depends on the Dome and Telescope policy properties to determine correct behavior.

I am just starting to do some testing of the settings.
After the first few, a weather alert with roof open and mount tracking I have not found one that causes the Dome to wait on the mount.

Dome: telescope locks & auto park
Mount: dome parks
This combination prevents the Dome from parking and it appears that subsequent telescope snoops of the mount do not detect a need to initiate parking.

Dome: ignore telescope
Mount: dome parks
This combination will park both but it is a race. In my install the roof is heavy but moves fast and most likely hits the telescope.

Sorry, having breakfast and reading the paper, got a bit behind on replies.
Last edit: 3 years 8 months ago by wotalota.
3 years 8 months ago #56591

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

  • Posts: 1185
  • Thank you received: 370
When using the Scheduler, a Weather ALERT leads to the sequence park mount --> park dome (if both are selected). Weather WARNING is ignored by the Scheduler.
3 years 8 months ago #56593

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

Time to create page: 0.455 seconds