For the summer months, when there is no true darkness and having done some C# and ASCOM programming- I fancy a go at scripting SGP - .
There seems to be a wide range of possibilities. In particular I was thinking of trying to instruct SGP to start a sequence when the safety monitor goes green, or at least not start the recovery process if a start of sequence hits cloud. Any suggestions on approach, language, resources?
A lot of that doesn’t really exist from our API which is more geared towards exposing the equipment externally, not providing access into the sequence.
http://mainsequencesoftware.com/Content/SGPHelp/APIDocumentation.html
So given current state I’m not exactly sure how you’d go about that.
Thanks,
Jared
Fair enough - it was just a thought. I was just intrigued by the possibilities.
Buzz, I too have thought about doing some scripting to control SGP externally. My goal is to have a script that, given all the appropriate inputs, can automatically run an entire night’s imaging from start to finish on a remote observatory.
Specific things that for me would be important are:
(1) Power up and connect to all equipment at the appropriate time, then power down and disconnect when done.
(2) Load 1 or more copies of SGP and open the assigned sequences.
(3) Open the dome at optimum time after sunset if conditions safe, close the dome when conditions unsafe, with just doing a Pause on any running sequences when either cloudy or unsafe. When safe conditions return, Resume each sequence. Close dome when all sequences are finished. I prefer the dome control to be done independently of SGP so that I have complete control of the dome.
(4) Start all sequences.
(5) Continuously monitor all sequences to make sure they are all running correctly. If a sequence fails, take appropriate corrective action. This could apply to a single process, such as restarting PHD2, or could be as extensive as a complete shutdown, followed by a complete restart of the system.
Implementing (5) would clearly be the biggest challenge, but should be doable. I have had occasional issues that this would solve. These include general dome control and hardware failures such as with my SBIG camera or filter wheel or PHD2. Solving these problems usually requires powering down then powering up and reconnecting the device and software, perhaps needing a restart of SGP, all of which can be done with a script engine.
There are many scripting engines to choose from. The two I have seriously looked at are PERL and particularly AutoIT Scripting.
AutoIT appeals to me a lot. It supports the following essential elements for us:
—Simulate keystrokes and mouse movements
—Manipulate windows and processes
—Interact with all standard windows controls
This allows us to do anything we want with SGP without requiring anything of the SQP API.
Obviously this approach is far more challenging (and fragile) than a complete API based approach, but I don’t think we have a choice. Just a choice in which scripting engine to use. We would want to use API calls where available.
Six other topics on this forum mentioned using AutoIT to do various things with SGP.
I would be happy to collaborate with you on this project and any others that might want to lend a hand.
jmacon - thanks for the offer but I think I will leave it for now - mine was just a casual inquiry. I’m in danger of taking on too many projects mysel and I need to crack on with some more chapters and image processing tasks.
I guess I was on a high after doing my observatory roof controller and app and thought…what next? It looks like the SGP API is not intended for manipulating sequences so I think I’m more inclined to design my own observing conditions module sometime - one module that not only supplies ASCOM safety status but full observing conditions too. The AAG one is OK but its ASCOM output is simply a go/no go status.
Hi,
In the process of setting up my remote observatory, I selected SGP for a proof-of-concept and I must say that I was impressed by the quality and functionalities. But I face the same need as jmacon : when my PC starts (programmed by the intellignet power switch), I’d like it to connect to the cloudwatcher and lauch SGP for a certain sequence when / if OK.
But the API can’t help me and I even haven"t found info on command line options just to automatically lauch a given sequence with SGP… I also found as only possibility to scipt it with AutoIt or similar thing, but as you pointed, it’s more risky, less efficient and sensible to upgrades of SGP…
Have you got any other possibility ? To me, having a command line argument to automatically launch a sequence would be sufficient, since the sequence can then manage all aspects…
Thx in advance for any help !
Clear skies
Mike
You can certainly load a sequence with the command line. We can look into adding a switch to automatically start it running.
Thanks,
Jared
Hello Jared,
oh, I hadn’t seen in documentation I could load a given sequence with command line ! Great, it’s half the solution ! It would be really great if you could add a switch to start it automatically because I think it would potentially solve all needs to integrate with scripts which could verify preconditions such as clear sky (or decide which sequence to launch based on external configuration).
I would really appreciate it and it would definitely validate SGP as a good solution for my observatory !
If you decide to do it, have you got an idea of the timing / release ? Just to know how I can plan my own setup…
Thx in advance,
Mike
Any news about this possibility to launch a specific sequence via command line switch?
Is there any documentation available?
Would it make sense to have a separate forum category for scripting? We could share scripts etc too.
Not at this time.
Probably a good idea. I’ll create one.
Thanks,
Jared
Here it is a year later, and I have in fact written a script in the scripting engine AutoIT to control my observatory for a single night. Extension to multiple nights would be straight forward.
I create the target sequence for the night in 2 different SGP sequences, one for my RASA 11" main scope which does the targeting/plate solving/PHD2 control, the other for the piggybacked SV100 which has the same target list and end times for each target and just takes images all night. With this setup I take images all night long on both scopes. This works because I do not dither, since there is no coordination between the 2 cameras. Not really a problem. One image on the second instance of SGP is ruined at the transition between targets. If the timings were coordinated, you would still lose some imaging time on one of the cameras. Dithering is not necessary if you use the Cosmetic Correction feature of the Batch Preprocessing Script in PixInsight.
I can start the script at any time during the day and it will automatically control the dome and both copies of SGP for the entire night without any intervention. It keeps track of the weather, powers on all devices and opens the dome an hour before astro dark, opens the 2 Sequences and connects the cameras a half hour later, and starts the control Sequence running 15 minutes before astro dark. Only if the weather is clear. If not clear, it starts this sequence when it does clear. If overcast occurs during the imaging session, it closes the dome, and when it later clears it opens the dome. Shutdown in reverse order is fully automatic.
The script in its current state is functional when I don’t have hardware failures. Some nights it has run perfectly. Other nights it has failed due to inadequate control of error conditions related to my hardware. The most frequent of these is my SBIG 8300M has a bad habit of hanging with the filter wheel stuck in the moving status, so no addition images can be taken on that camera. However, the large scope and camera, which is using the control copy of SGP is continuing to run all night. I believe I now have code to detect this particular failure with the script so it can automatically recover from this hardware error. Other hardware irregularities with the dome control have successful recovery routines.
The script writes a log summarizing all significant events during the run, like startup and shutdown processes, dome opens/closes, and weather changes.
There are many enhancements that I will be adding as time permits.
Anyone who would like to check out/use the script, as is, is welcome to.
That is pretty awesome @jmacon. We will be extending the API beyond direct control of equipment to allow for control of and execution of sequences. Scripting in AutoIT is not awesome and hopefully you will be able to get cleaner results using an API to achieve the same results. Each version of SGPro would run its own API server instance on its own port.
I"m really looking forward to those enhancements Ken. Scripting with AutoIT can be made to work, but is very tricky. API control is ideal.
This could be really interesting…
I hope will be implemented soon…