Yes that was my intention. To follow any upcoming EKOS' observatory close down changes and keep it only as a failsafe system for the cases where EKOS does not close down while it should. (I consider this to be a different situation from an EKOS crash where the INDI watchdog driver can kick in.)

That sounds perfect. Where are the parts of the Linguider/PHD2 interfaces that EKOS uses described ?
Ekos Sentinel can now only command the scheduler to start or stop. It cannot ask what the scheduler is doing. The new observatory module should have an API where external programs can query these things, and it would be great if the observatory module could inform sentinel that it is going to do something, and that it expects to take X seconds at max. I propose I add a REST API interface to Sentinel for this.

-- Hans

Which dome driver is this?

What I'm referring to are the standard properties in the developer manual
indilib.org/develop/developer-manual/101...erties.html#h8-domes
It says this:No mention of closing the shutter, that's a separate switch.

And the INDI API here indilib.org/api/classINDI_1_1Dome.html#a...f74fd79dc763a1eb9bc1
It says:Once again all it says that Park does is move the dome to the park azimuth.

Those docuents seem to me to be as close to a standard as it comes.
I don't see how a client or user can cope if it doesn't know what a standard function does.

Sorry for the poor formatting of the quotes,
Chris

That is correct, parking and closing shutter are two separate properties. However, another switch can be added to a dome driver to automatically close the shutter on park. This is per-dome and does not apply to all domes (one 5.5m dome I worked it is impossible to close shutter automatically), and hence it needs to be implemented on case-by-case basis. This is I asked which dome driver to see if it can support "Close Shutter on Park" functionality or not.

The point I'm trying to make is that clients and drivers should not have to rely on undocumented additional features.
There is a perfectly clear specification, why not follow it?

A client wishing to make an observatory safe closes the shutter. That would work both for a dome and a roof. Some domes may require that the dome was parked first so isuing a park first may be neccessary.

As for examples, are you aware of all INDI dome drivers? There's no requirement that a developer contacts you, they could easily follow the specification I quoted above. As the author of the BaaderDome driver did.

Chris, I agree with you 100%, the specs needs to be clear on their own merit. What do you propose?

As they are the specs seem clear enough. Park moves a dome to a park position. Closing the shutter closes the dome shutter or roof.
It might be useful to have some additional text saying that a roll off roof is implemented using the shutter control.
Abstracting this the shutter exposes the telescope to the sky and the dome azimuth specifies the direction which is clear. Some domes need altitude as well. All the detail of what is done to achieve this is managed by the driver.

IMHO the implementation needs changing in some drivers and clients to match the specification,. For example the WDT needs a close shutter adding. Ideally if the dome can only operate the shutter in a specific position then it should do that as part of the shutter operation.

Hope that helps, I could try to do some of this but I'm not in a position to test much other than with simulators.

Chris

Hi Chris,

Great. Any contribution is highly appreciated. I just updated your user permission so you can edit all the manual and specifications pages as you see fit. I've seen quite a bit of variations when it comes to shutter/dome controls. Some can be operated simultaneously, others in specific sequence, some manually..etc

For ScopeDome I originally added the option for park to control shutter as Ekos only (un)parks the dome and doesn't close the shutter so it can work both ways. The same functionality could be in the Dome base class, which might unify different drivers, or then it could be defined to work one way or another and clients accommodated accordingly (having the startup and shutdown procedures more flexible in Ekos would help here so parking and closing shutter could be two different operations is needed). For the most part I let parking control the shutter too but occasionally it's useful to be able to unpark the dome without opening the shutter. Rotating to let snow melt from other side of the dome in the sun comes to mind

As for the scheduler partitioning, untangling observatory startup and shutdown from the scheduler is very welcome as currently I have to run a slightly modified Ekos version that performs the startup and shutdown operations in a different order than default. Currently the structure is very rigid state machine even though it could in essence be just a list of operations that need to complete for the scheduler to proceed, be it running scripts or (un)parking equipment. Optionally the list items could have dependencies to other items that need to complete successfully so that for example roll off roof doesn't close if mount fails to park but for example parking cap could still be completed even if some of the preceding items fail. I suck at designing user interfaces though

This is indeed a great point that emerged from exchanges on several occasions. The observatory startup, shutdown as well as the scheduler job steps should be done in a customizable order.
Let's think of this as a Gantt chart, with ancestors and children as step properties. This architecture should allow very simple customizable sequencing (let's omit parallelism for now).

When we look at those steps this way, it indeed appears they more or less fit each tab of Ekos: alignment step, autofocus step, capture step, dome parking step, mount parking step...
This means we could later on store specifics about these steps, such as characteristics of alignment, or characteristics of autofocus, or sequence jobs descriptions for capture.
We already know that capture steps require sequence files to be described properly. We observe that an autofocus step requires different settings when working on a galaxy and on a cluster. More of these in the future?
Finally, we could decide to store the whole ad-hoc configuration of each tab into a step description, and make Scheduler schedule those steps differently for each of its Scheduler Jobs.
Serializing and reusing those steps is very important. We should for instance fix the path concept in the sequence job so that it may be used independently of the target.

In more object-oriented terms: Procedure objects in the Scheduler and the Observatory aggregating and sequencing Step items, which embed serialized attributes adjusting how those Steps must be processed.

What do you think?

As of today the only two roof drivers (the roll off roof simulator and Talon6) use Park for opening / closing the roof. Shutter is ignored not setting DOME_HAS_SHUTTER .
Changing that behavior would require some review and test of the code.
But I would keep Park for a roll off roof mainly because parking position could not be equal to a fully open / close shutter position.
ferrante

Fully agree, great idea with these Procedure objects! Take the example of focussing. Currently, it is embedded both in the Scheduler and in Capture, none of them is optimal. Should the Capture module really take care of focussing? Why not giving the Focuser module the ability to request a focussing sequence e.g. once an hour instead of having this entire logic inside of Capture?

This way we will create a very powerful - but entirely different - Scheduler (maybe we call it ProcedureEngine?). The only thing we need to consider: it needs to be easily understandable. We might end up in an over-engineered solution. Maybe we need wizards to configure it.

- Wolfgang