SGPro+AAG Cloudwatcher (Semi OT)

Another worthwhile feature should it be added - I think that so far the inability of SGP to open up and start a sequence after it has closed everything up is a bit odd and pointless… after all so many people want to use it as a total automation piece of software, this makes perfect sense.

1 Like

Thanks Jared - I think it would also require a little more work on the abort/resume routines to start up PHD2 correctly. I’m pulling together some log files that demonstrate how SGP can lose PHD2 on resume and wait for something that will never happen, either because it is not connected, or that it is not guiding.

What would be nice if clouds (no rain) CLOSE the shutter and pause. Upon sky clearing - resume. Once rained… I’d feel better if it didn’t restart.

Yep that could simply be a small set of options in SGPro that the user can select under the Safety options and configure it. I personally would like both scenario to happen. I have no issue with reopening the dome & to resume the sequence if all conditions define as SAFE are back for the last 30-45 Min. (Same as in CCD Commander). SAFE conditions can be user define in AAG so you can make them pretty SAFE if you want :slight_smile:

Would a simple solution be to use a second ASCOM Safety Monitor to determine when it is OK to image?

Keep the existing Safety Monitor implementation to force the end of sequence, mount parking and slaved observatory closing when conditions dictate.

Add an additional ASCOM Safety Monitor instance to control imaging. When this monitor transitions to Unsafe, stop the current image, stop autoguiding and stop the mount tracking. When it transitions back to Safe, select a target based on time etc, slew & centre on the target, start guiding, run autofocus, and start imaging. This looks very like at least part of the start of sequence logic.

These actions could be repeated many times through the night without the need to terminate the sequence.

I have an AAG CloudWatcher/Solo. I would use Chris Roland’s Boltwood Safety Monitor as the existing SGP Safety Monitor, allowing the dome to remain open when cloudy, windy, wet etc, but close it whenever overcast, very windy, rain was detected.
I would use the AAG CloudWatcher Safety Monitor driver to allow imaging when dark and clear.

Equipment would be safe based on the current SGP use of the ASCOM Safety Monitor, and the fact that tracking would be stopped whenever imaging was paused. No complexity in meridian flips while paused, etc.

3 Likes

Other things first? First I’d REALLY LIKE to see the shutter close when the SGP safety button (lower right of window) is red. And not open if red. Mine did not close when bad weather came in. Someone told me on here that it only closes if in a sequence? (That’s bad).

I often am in SGP and not in a sequence. I might be just programming in targets or tracking the sun for solar work - or moon for lunar work and I just shoot either frame and focus (saving to disc) or I might call up Sharpcap for video acquisition for solar. (SGP doesn’t really do solar).

SGP is always up as it syncs my dome with my mount with my goto (worldwide telescope) pointing program. More often than not - I’m not in a sequence… and if it rains, the dome stays open.

Since the button in the lower right is green or red - It KNOWS outside the sequence! PLEASE make this change to control the shutter when the safety button is RED.

Another senserio is (I’ve done this several times already this spring) I’m doing solar, I got off to process and I forget to close the shutter. HOURS later I find it’s open… if rain had moved in it would have been open. PLEASE PRETTY PLEASE make this change.

1 Like

I’m pretty sure you’re right about SGP only closing the shutter if a sequence is running. I don’t know what unit (if any) you use for switching. I use a Lunatico Dragonfly. I can wire the relay cables from the CW straight into one of the Dragonfly sensors. When it becomes unsafe, the relay in the CW closes and this is sensed by the Dragonfly. I have a short script that runs when this happens. The script waits a couple of minutes to allow SGP to close everything down if I am running a sequence. If SGP hasn’t shut things down (I have roof amd mount park sensors) the the Dragonfly script will park the mount and then shut the roof.

1 Like

This feels like the Polar alignment thread from a few days ago. People may be expecting SGP to do something it’s not really designed to do.

Observatory safety monitoring feels to me rather like something that should be controlled independently.

This would look more like the current ASCOM scope and dome hubs, with the addition of safety and weather. It might only expose a telescope interface, possibly a safety interface as well. It would manage safety and syncing, parking the scope and closing the dome as required and reporting the Park and Safe states to the application as required.

This could be an opportunity for profit. There’s a lot of useful functionality here that could be sold independently of SGP.

I did consider doing something like this, the current ASCOM hubs need leading gently by the hand into the 21st century and I had a go. But ended up adding a 3D scope and dome mimic diagram, plus safety and weather interfaces. Not so much feature creep but feature gallop. The work involved to develop and support this was more than I was prepared to publish for free and I don’t have the enthusiasm to do it as a commercial offering.

1 Like

You guys ask for feature requests and seems every time something is asked for you have excuses as to why you won’t or can’t. I don’t get it. Why not delete this area then?

  1. interface color/brightness. So so easy to have a option for the interface brightness. Slide up for light gray, down for dark gray. Or even just a toggle “light or Dark”. When looking at a sub which is mostly black and trying to decern nebulousity in the darkness… it’s not so easy when the pupils are dilated because the interface is so bright. But you say you can’t.

  2. SGP already knows if it’s safe or unsafe. There is a RED/GREEN button lower right showing it knows the current state. (if in sequence it shuts the dome if unsafe). So it’s now not SGP’s job to shut the dome outside a sequence? That makes no sense. Throw the close shutter command code next to the red/green indicator code and I can then trust my shutter will close when unsafe.

I have no wish that if it becomes safe again that it opens and continues to shoot subs. That’s asking for a lot and that gets complicated. Simply closing the shutter if clouds roll in will keep my obsy dry if rain moves in.
Stay closed! Rather be safe than sorry.

Observatory safety monitoring feels to me rather like something that should be controlled independently.


Someone has - it’s cloudwatcher/solo.
It saves a file if safe or unsafe… SGP looks at that file and lights a button green or red.
This does nothing for safety. Why not at least send a “C#” close shutter command.
Better safe than sorry. Since the button is already showing safe or unsafe, it seems so simple to send
a close the shutter command string.

“Note: The safety monitor will not truly be active until the first frame from the first target begins. If there is a period where SGPro is idle prior to sequence start, SGPro will ignore any unsafe events until the first target’s start time passes._”

This isn’t really SAFE. operating remotely - it could be raining. There are lots of things we can be doing in SGP and not running a sequence. The functionality IS ALREADY THERE. In the form of a green or red button which does nothing but show it’s capable of knowing it’s safe or unsafe.

No. That’s monitoring not control.

SGP is designed to automate the process of acquiring image data. It is not a general purpose observatory control system.

In my opinion SGP already does too many things that are outside it’s core functionality and it is running the risk of becoming a bloated unreliable buggy monster because of it.

I’m not saying that people don’t need observatory safety control, I’m saying that I don’t think this should be a function of the imaging application.

What’s needed is a separate Observatory Control Application. This manages the Observatory, opening and closing the observatory as the conditions change and maybe managing the dome to scope slaving. SGP operates through this, sending slew and sync commands to the mount and relying on this to keep the dome synchronised. It provides a safety interface that SGP can use to keep it’s own house in order so it doesn’t keep imaging when the dome is closed.

Why don’t you do this? You are saying how easy this is so you shouldn’t have a problem.

2 Likes

Ron, there are too many logic options here. Each user will want something different, as a result of unique hardware or sensibilities. It requires careful consideration of the failure modes in each case and is more likely to be closely related to the observatory hardware/software rather than an imaging program.
As an example, I open the roof on my ROR to let the equipment cool down before imaging. My particular mount has to be homed before it can slew anywhere, I cannot home it with the roof closed. I have to manually open the roof, often in daylight, home the mount and then park it again and leave the roof open. I will do this from a separate application, regardless of whether SGP is running or not. Cumulus convection clouds often disperse around twilight. If SGP were to react to the safety monitor when I set it going to cool down and wait for the start time, it would be forever getting confused and thinking the cloud and light levels were a concern. With my mount parked and waiting to be woken up again, an independent controller monitors for rain and closes the roof automatically, providing it is OK to do so, using a unique array of position sensors, independent of the Win PC. That is in addition to an observatory control application I wrote, which interfaces through ASCOM to do the same thing. The redundancy is necessary, since Windows now has a habit of rebooting itself at will, when MS think an update is important.
For someone else, say with a dome that does not interfere with the telescope, the logic changes and they may be happy with a simple shutter close - but, if the PC reboots, what then?

There is one element that one might argue is missing in SGP - whereas SGP can terminate a running sequence if the safety monitor (or lack of guide star) say the situation is unsafe, there is no automatic feature to resume when safe conditions return, say for a passing shower. In defence of SGP, the recovery logic can be extended for a considerable time and its logic assumes that if things didn’t improve after an hour or so, bad luck.

The point is, that sending a close roof / park command is trivial. The logic for when to do it is not so obvious and is likely to be different for each customer and even thenm since all this discussion is in the Windows domain, an independent controller is a sensible precaution.

If there is no foul condition, a simple Hydreon HG-11 rain monitor, linked to a close shutter relay input may be all you require. At worse, SGP takes pictures of the inside of the dome.

The only person from MSS that has responded was me and I literally said that this is something we’re looking into. So I’m not sure where this is coming from. Maybe you’re mistaking others comments and coming from MSS?

Tell you what. You tell me how to do this with a WinForm application so that it doesn’t look like crap and I’ll gladly implement it tomorrow. As it is you don’t know enough about our application or underlying architecture to know what is easy or difficult. To make this happen would honestly mean a complete rewite of SGP. And that is something we’re considering. But it’s not happening tomorrow. So as it stands we can’t do this. I’ve already mentioned that WinForms was a decision we regret. But there weren’t a lot of options when SGP started.

Correct. You’re manually fiddling with things at this point and working outside of the automation. So it’s you’re job. If you open the gate, close it. If you put the horse out. Put her back in.

Jared

@Jared As a developer using the same tools you are, I understand the issues you are facing. There is no “themes” you can easily use. However, I think you may be able to accomplish what you want easier than you describe. Suppose rather than having every form derive from the Form object you create an intermediate form that is responsible for themes? This new form object could know about the global theme state and apply it as needed. When the theme is changed, you could iterate through the open forms and send an event to this intermediate form object. I understand I may be oversimplifying depending how far one wants to get into themes. From what people have been describing, it may take more than just changing the font and background color.

It is certainly your and Ken’s call as to the priority of implementing features but I don’t think it takes a WPF rewrite to get something similar to themes.

Sadly no. There are a LOT of controls that you don’t actually get to define background colors for. I attempted exactly this a few weeks ago and it was somewhat successful but extremely ugly. The gradient around buttons cannot be defined and lots of other things just stay at the default colors. I’ve honestly put in about 20 hours attempting to make this work. And of something seemed possible (without GDI) then I would certainly make this happen.

I’ll see if I can find the screenshot of the attempt.

Thanks,
Jared

Jared, if you will PM me on this I’ll play around with it - I don’t want to duplicate what you have already done.

We did what you described at work many years ago by having a GraphicsPolice object that was attached to each form. It had brutal methods to force our personal scheme onto forms. This all ran in a special framework developed for us by a specialist company which cost something of the order of 100,000 sometime in the 90s.

What I’ve tended to find is that doing this at an application level may work, more or less, for most things but then some control pops up which isn’t that isn’t dimmed. AARH!! And another application may also not be dimmed.

A better way may be by changing the colour scheme for the entire system, I believe that there are apps that will do that independently of SGP.

The fact that this is being discussed by experienced developers shows that this is not trivial. Certainly not as trivial as getting a sheet of coloured plastic.

My personal modus operandi is to keep the laptop indoors, in the light, with a cable running to the scope outside in the dark.

One of the reasons I rejected APT was that it only had very dim screen views with no option to set anything usable in ambient light.

For anyone interested in changing the look of Windows at night, check out WindowsBlinds
Download/Purchase WindowBlinds 11 : Software from Stardock You can make your own theme or try one of the dark themes. https://skins17.wincustomize.com/13/95/1395545/1/8837/preview-1-8837.jpg or https://skins14.wincustomize.com/13/95/1395545/1/8824/preview-1-8824.jpg

I have no idea how SGP will work with them.

SGP will (generally) respect themes. Here’s a modified high contrast theme in windows 10:

I too would retire SGP as a push for software that works as needed.
I have spent the last couple days looking for alternatives. I asked the driver authors (drivers aren’t really DO software). I then applied CloudWatcher windows software and a script. Here’s the problem. WORKS GREAT without SGP. But once SGP connects to the dome (REQUIRED TO IMAGE). The com port is busy and the other script isn’t allowed by the com port. I started playing with a app in VB and same issue. I feel I’m trying to re-invent the wheel - as ITS ALREADY DONE AND IN SGP. SGP shows a RED or GREEN button for unsafe or safe.
The safety driver and dome drivers are connected. Add to the paragraph about the safety status button… If red(safety) send com3(dome) C#.(close) I mean really. It’s nothing. Have obsey settings allow user entered “close string”. Heck - the obsy settings are entered in the driver. The driver and close (any dome, roof) simply tell the osby driver to “close”.

SGP is suppose to allow unattended automation. As in - no driver at the wheel. We set it and forget it and go to bed. So how does a RED or GREEN light help us? Send my phone a alarm to wake me or simply ask for a “close roof/shutter command string in settings” And send the damn string when the light turns red. My string is simply… C# Others may have other commands to close the roof, they’re then able to enter their command string in settings for the observatory. IF things become safe I don’t need it to OPEN, though that’s possible too. If I miss a night of imaging because of one passing cloud so be it. I only want to be sure in the case of rain (which comes from clouds) that my shutter is closed. I don’t care if I shoot the inside of the dome all night. I’ve been trying to solve this with Jamie from https://www.lunaticastronomical.com/
His sensor set determines the conditions. Chris’s safety monitor looks and aquires that info. SGP
shows a red button. So why another app (aren’t we running enough apps to image already? I think I run 8)
Jamie replied to my problem with this. Only other solution is for the driver to allow concurrent connections.


Hi Ron,

I really think if SGPro is connected to the dome, it should be it who closes the shutter, even if the session is paused or stopped or whatever. That’s something the users have to ask / press them to add, I believe that’ll be understood and supported by others in the SGPro support forum.

Besides, every dome has a different way to accept commands, some is a serial command such as yours others something totally different (our equipment for that uses network messages, for instance).

Your dome has an ASCOM driver, true? Do you what what it’s ASCOM name is? Something like megadome.dome

Maybe it allows concurrent connections and, instead of sending the COM command, your script can command the driver to close.

Best regards,

I mean it’s ALREADY THERE! What good is a safety monitor that does nothing by button color?

![closeatdriver|639x600]

SIMPLY send close to the driver, doesn’t matter if we have different close string, the driver translates.