Where to configure weather station safe/unsafe behaviour

Sequence Generator
1

Where can I set the options (Auto park, close observatory, etc) for the weather station safe/unsafe conditions?

2

I’m still not able to find it. Maybe it’s not possible?

3

Park the telescope when the sequence ends checked, slave the observatory to the telescope. Mobile response… can be more explicit later if you need it.

4

So, there isn’t anything to configure especially for the safe/unsafe condition. It just triggers the end of sequence when is becomes unsafe. Will there be in the future more options available like sequence pause when unsafe or start sequence until safe condition?

5

We may but I don’t want to promise anything at the moment. Currently it’s made to shut things down if things go bad and requires manual intervention to get things started again.

Thanks,
Jared

6

I’ll add a vote for “start when safe function” please.

1 Like
7

Hope there will be in the (near) future as i’ve safety (auto dome close) implemented in another way.

8

Maybe you can give us some information about how you’ve implemented it and we can see if we can fit it in?

Thanks,
Jared

9

Well, I’ve simply created a vb.net which connects, among others, to my cloudwatcher and my dome.
When the cloudwatcher is reporting an unsafe condition, the dome will be closed. simple as that.

What I really looking for is imaging behaviour depending on the safe/unsafe condition. This is something which can only be done in de imaging application (SGP). Thinks like start sequence when condition becomes safe or pause when unsafe. Now that I’m thinking about it, maybe its better to connect directly to the cloudwatcher so more variables are available. Pause when cloudy. Abort when rain or light. Start when dark, clear and dry.

10

We’ve discussed pausing/restarting based on a “Safe to Image” monitor but I’m not sure if/when that will happen. There’s a lot to think about there.

Device specific weather support is not something we really want to implement or maintain. We’ll have to see where the weather station support goes before we draw a line in the sand though. But we generally prefer to use standards so that we can talk to multiple things using the same implementation rather than just one thing. Native support for hardware tends to kill progress on features.

Thanks,
Jared

11

I fully understand your thoughts and agree on them. I’m the last one who want to kill progress on features :wink: I assume it’s becoming complex enough and a lot efford to keep up with. But your doing a really good job and when I look at the response times from main sequence on this forum, I think: do they ever sleep?

Anyway, the only thing which would be wise is to extend the ASCOM ISafetyMonitor Members so you can use them. Does anyone has a good relationship with the ASCOM developers? :smile:

12

Chris has actually made a “Is Safe To Image” watcher as part of his Boltwood One-Line implementation. So it is there when we’re ready to use it! We just have to figure out what happens when it’s unsafe to image.

  • Do we completely shut down and wait until it’s safe with the equipment covered?
  • Do we turn off tracking and just wait?
  • Do we abort the current frame or just let it finish?
  • What happens with guiding?
  • Probably about 10 other things that I’m not thinking of!

I really don’t want to expose all of these things as options. That’s just too many things for the average user to want/need to think about. We generally prefer to make things simpler…not more complex! Anyways, it will likely be there eventually. Just not quite yet :slight_smile:

It happens occasionally…but having AP as a hobby and a 3 month baby old means hectic sleep schedules! Plus we’re behind PCs most of the day so the chances of at least one of us being online at any given time is fairly high.

Thanks,
Jared

13

[quote=“tcpip, post:11, topic:721”]
Does anyone has a good relationship with the ASCOM developers?
[/quote] I do.

The SafetyMonitor came out of a lengthy discussion about an ASCOM weather interface where it emerged that including every possible weather parameter and making them all optional was impossibly complex.

Then we realised that from the users perspective all they need to know is “can I do something?” and from that the safety monitor emerged. The decision about what safe means is delegated to the device specific driver. This can be as simple or complex as required.

There can also be more that one safety monitor, I have provided two safety monitors for the Boltwood, safe to open the observatory and safe to image. They could have different criteria and be used by the application for different things. For example an application could monitor safe to image and only start an image if it’s safe. This could go unsafe for thin cloud. Meanwhile the safe to open monitor regards thin cloud as safe and it’s only thick cloud that’s unsafe for that.

As Jared says this will get complex but separating the decisions about what safe means and what you do about it should make things easier to implement and, hopefully, understand.

Chris