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

It's a shame that some changes to existing code will be needed but I think that in the long term it will be better to make the code match the specification. The later we leave it the more will need changing.

For roll off roof drivers I would start by implementing the roof as a shutter but leaving the dome park functionality in place. That way clients that are relying on park will continue to work.

For clients I would add the close shutter command to the make the observatory safe process. The dome park command can be left, domes may need it anyway.

I'll look at modifying the specification to make things clearer but if there is much more on this we should start a separate thread. This is only peripheral to partitionng the scheduler.

Chris

Good point, further discussion on how a roll off roof should park / close shutter should be moved to another thread.
Beside the specific topic, this has influence on the overall approach : will the new Observatory orchestrate steps of a 'shutdown' procedure leaving the implementation of shutdown inside individual drivers (like it is happening today) or will the Observatory effectively manage the single steps in detail?

Thinking about using these messages in the drivers I contribute to, I 'm in favor of the first: It helps to segregate duties among clients and devices (and among client and driver developers).
For example, if safety conditions in the Observatory are not met, that should trigger an agnostic 'shutdown' (or 'observatory not safe') message to the individual driver without any required knowledge of the shutdown procedure itself.
On the other hand, adding Close Shutter command to the client when there's already Park, means that part of the shutdown procedure logic would be implemented in the client.

Some domes require the shutter to close after the dome rotates to park position, others don't; roofs have a different behavior etc. And for me it is best to let the developer of the driver manage this procedure because he is the one who knows how the device works.

In the case of domes, until now, this 'shutdown' role was played by Park, even though in the specification Park was meant just to move to AZ park position.
I'd rather update the specification or even change the name Park but leave the park shutdown logic inside the driver.

Domes here are just an example, it would be true also for other devices involved in the Observatory (mounts, cameras, caps).
Ferrante

That feature was implemented this way because it was centered on the procedure taking a capture. The use case was "I want to refocus every N minutes when I capture". If we move the refocus procedure to the Focus tab, the use case becomes "I want to refocus every N minutes". We then have to manage when the refocus happens exactly. You guessed it, that's exactly the same situation as the meridian flip. That probably means that both needing to focus and needing to flip will be statuses of Focus and Mount respectively, and that the actual request to do one or the other will come from Capture.

I don't think Scheduler gets much different than now in its behavior. For sure code is moved around, and the added benefit is that we try to restrict each procedure to its relevant module. The important point is that we must not center all activities in Ekos on the Scheduler. People must still be able to track the target of their choice manually, engage guiding manually, focus manually and start their manually configured capture job, without any interaction with Scheduler.

Let's try to map these thoughts to Ekos, with extensions that are mostly only brain food to see if nothing breaks (I said Scheduler doesn't get much different...):

- Capture gets a SequenceJob (CaptureStep? CaptureJob?) which has exposure/filter/temperature/... parameters all serialized into a XML file. No focus nor meridian flip. Storage path more user-friendly.
- Capture algorithm, however, checks with Focus if a refocus is required, with Mount if a flip is required (why not with Align, see below), and eventually requests executions of these before capturing. Capture only captures. But Capture also can be a event source for safety, for instance when repeatedly overexposing. Capture can also be a client of Observatory to monitor CCD temperature requirements. But Capture should probably not become the only controller of the CCD, to which other modules request frames. We need to think about multiple Capture modules here.

- Mount gets a TrackJob which has coordinates/HA-flip/limits/park-time all serialized into a XML file.
- Mount algorithm executes slews and does notify flip requirement to listeners, like it does now. Capture is responsible for executing the flip if it is running (else Scheduler probably should). If no-one is listening, then maybe the end-user is observing visually, and we should define what a dangerous positioning is. We could decide to stop tracking if the mount is able to, or to move slightly away to a safer position automatically after a delay, but not to engage a large movement without warning.

- Focus gets a FocusJob which has the usual exposure/settle/field/algorithm... parameters all serialized into a XML file, along with the interval between refocus procedures.
- Focus algorithm does its usual activity, and keeps track of the last time it executed. When the refocus delay elapses, Focus notify the focus requirement much like Mount does for flip. If we have multiple CCD, multiple Capture modules, then maybe we should have multiple Focus modules.

- Alignment gets an AlignmentJob which has the usual exposure/settle/precision... parameters all serialized into a XML file.
- Alignment algorithm does its usual activity. We could store the last time it executed in order to provide periodic realignment to unguided setups, in the same way as Focus or Mount. Alignment could automatically expose and solve when no one else is using the CCD. One improvement too for planetary imaging could be to allow sync'ing on a different target than the current observation object before blind-slewing to that object. Furthermore, we could assign Alignment the job of solving incoming frames in parallel to validate positioning during exposures. In terms of multiple modules, Alignment is 1:1 related to Mount.

- Guide gets a GuideJob which has the usual type/exposure/rate... parameters all serialized into a XML file, along with the deviation limit.
- Guide algorithm does its usual activity. When it notifies a deviation peak, Capture is responsible for suspending exposure (all Capture modules). Like Alignment, in terms of multiple modules, Guide is 1:1 related to Mount.

- Observatory gets an ObservatoryJob which has some of the parameters that were in Scheduler before. It's all brand new here.

- Scheduler gets a SchedulerJob which has the usual parameters all serialized into a XML file, plus a link to all the XJob mentioned above.
- Scheduler algorithm is then responsible for sending those XJob requests to each module in a customized order, and execute robustness monitoring to ensure all execute properly.

(I'll try to copy the points we previously agreed on in the first post of the thread)

-Eric

Eric, from a design perspective I fully agree, this is the right way to do it. I would be super happy if somebody owning a dome can join and take over the development. Developing everything with the simulators is not a good idea.

My intention is implementing a very basic version of the Observatory module so that we have a "home" for the entire observatory stuff logic currently living inside the Scheduler. From that starting point, I would prefer a handover.

- Wolfgang