×

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

  • Posts: 311
  • Thank you received: 42
For the weather alerts it obviously needs to work without the scheduler, so having the Observatory first park the mount and then the Dome seems clean.

It looks like the scheduler is already aware of the alert but I don't know how it responds to that.
If logic is to be placed in the Observatory to wait until the mount is parked before parking the Dome, perhaps the scheduler can respond knowing that. It does not seem much different than how it must presently resolve the parking of the Dome knowing that the Observatory is probably already doing that because a weather alert has happened.

Does anyone know what added value the Dome property Auto Park provides over the other Dome/Mount policy combinations. Is it just a if you want to do anything useful do it at your own risk kind of a setting.
3 years 8 months ago #56595

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

  • Posts: 250
  • Thank you received: 3
You mean that if I schedule a photo shoot and there is a weather alert it will end the session and suddenly it will be like a normal end of session with the setting on the park of the frame and then close the roof?
3 years 8 months ago #56596

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

  • Posts: 554
  • Thank you received: 138
I wouldn't involve Ekos at all. what I'd do is:
The Weather driver sets some sort of unsafe property.
The telescope and Dome snoop on this and when it's set:
The Telescope parks. It ignores whatever any application is telling it to do, it parks. No options, no choice.
The Dome continues to snoop on the telescope and when it's parked and the weather status remanis unsafe it makes the observatory safe.
Ekos is no more than a spectator in this. It could do something sensible but it doesn't matter if it doesn't, no one is paying any attention to it.

Actually I would try not to involve Indi either. I'd have an observatory that could close regardless of what the telescope was up to and I'd have a hardware signal that triggered the make everything safe process. It's the only way to be sure.
3 years 8 months ago #56608

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

  • Posts: 294
  • Thank you received: 54
Makes a lot of sense to me.

Would it also make sense to make it an orderly 'shutdown' procedure that could also be used when the scheduler or the user has finished its tasks for the night? Not wanting to overly complicate things though.

Thanks.
3 years 8 months ago #56610

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

Time to create page: 1.054 seconds