David's Astronomy Pages
|
 Computer Control |
 Home Page |
 Image Gallery |
|
Introduction I've been writing and using Visual Basic script programs for Image Acquisition and Analysis since 2002 and these have proved to be a significant enabler for my astronomical work. Several programs have been written during this time, each building upon the foundation of the previous program and reusing main code components and introducing improved functionality. My program's access and utilise CCDSOFT and THESKY software programs using method/property calls.
The current program (AIS) is written in VB.Net and using it I have functionality which pretty well matches any of the commercially available telescope/imaging control programs which have sprung onto the market place in recent years.
Scripting/programming is not for everyone, but for me it provides me with the flexibility to add almost any new functionality/feature just as quick as I come up with a need or new idea and then write/adapt and test the necessary new subroutines.
This page summarises the various phases of program/script development over the period 2002 to 2018.
CCD Imaging Script Program (2002-2003) VMA Program (2003) Telescope and CCD Imaging Scripts (2004) Telescope and CCD Imaging Scripts (2005) Astronomical Imaging Support (AIS) Program - 2006 Astronomical Imaging Support (AIS) Program - 2012 Observatory Control System & Imaging Support (AIS) - 2018 Code Notes >>
In October 2002 I began a project to record the variations of about 15 variable stars in the constellations Andromeda, Lacerta and Pegasus. The stars were some that were suggested in David Levy's book "Observing Variable Stars - a guide for the beginner". Most of the stars were long period variables which appeared to suite my observing environment where nights can be clouded out for 2 weeks at a time, which would ruin attempts at observing shorter range variables which need to followed every night or two.
I commenced by "manually" aligning on about 15 variable stars. "Manually" acquiring each star in turn and waiting for images to be taken is quite time consuming and a promised to be a little monotonous if repeated regularly for the same set of stars, even with the aid of software aids such as TheSky and CCDSoft. I therefore looked at methods for automating the process. I was also very much interested in developing a quicker methods to manage and analyse the megabytes of image data that I was beginning to shoot each observing session.
The Software Bisque product Orchstrate was considered, and although purchased and initially used for automating the acquisition of Mosaic Images via links with TheSky, it did not offer sufficient flexibility for the tasks that I had in mind.
With the benefit of previous programming experience and the useful .VBS script examples provided with CCDSoft vn 5.00.072 onwards and on Tom's Corner at Software Bisque web site, I quickly adapted or knocked together some scripts that began to perform some of the tasks that I required. However managing them together during further development became difficult and I therefore chose the route of combining them into a single menu driven script, with sections/subroutines for each specific task.
By November 2002 I had pulled together an integrated script control program named "CCD Imaging Scripts & Utilities". This was operated from late 2002 to the end of 2003.
During 2004 I began developing a new front-end using HTML Application (HTA) interface, which reused major code sections from the 2002-2003 program. Two programs were initially developed - "VMA Program" (for performing rapid batch photometric analysis of images of variable stars) and "Telescope and CCD Imaging Scripts" (for automating image acquisition and image analysis). The VMA program was developed to assist an observing programme being conducted by Dale Mais (USA) examining potential flare-up in Mira type variables In early 2005 the two programs were combined into a single program "Telescope and CCD Imaging Scripts" version 2.5.
Two particular factors held back further development of the HTA based program despite the introduction of specific workarounds. These factors were the inability to have multiple program threads (preventing the ability to control refresh of status information and preventing easy program pause/interrupt) and the practical difficulties in managing the growing code which by this stage had reached some 17300 lines in length.
In late 2005 I began porting the code into VB.Net. This took some time to perform as several new programming techniques and workarounds had to be mastered. However by beginning of 2006 the new program, "Astronomical Imaging Support (AIS)" was ready to take over duties in the observatory. Further development has occurred through 2006, including a Job Control screen which now lies at the heart of my image acquisition workflow. Further developments have occurred in the years since. The current version dates to 2012.
The following sections summarizes the main phases of program development in chronological order.
Back to Top
In November 2002 I wrote an integrated script control program named "CCD Imaging Scripts & Utilities". The program was written in VBScript and operated via Windows Script Host (VSH) . It was used from late 2002 to end of 2003. The following screen captures show the Welcome Screen and Main Menu.
Further details on the program, including further screen shots and information
on specific scripts/utilities is contained at the following link : "CCD
Imaging Scripts & Utilities" program (2002-2003)
Back to Top
In 2003 I began collaborating with Dale Mais (USA) who was embarking on an observing programme to look for potential flare-up in Mira-type variables stars and required assistance to develop a tool that would perform rapid batch photometric analysis of images. This led to the development of the "VMA Program" (Variable star Magnitude Analysis).
This software program comprised a set of visual basic (VBS) scripts that were accessed through a HTML Application (HTA) user interface. The picture below shows the VMA program (version 1.5) in operation.
The main program scripts were "1.2 Analysis" for performing differential photometry and "1.3 Analysis" for performing absolute (all sky) photometry.
The tool is referred to in publications
describing the status and results of the mira variable star monitoring programme.
Monitoring of Mira Variable Stars,
Mais, D. E.; Stencel, R. E.; Richards, D., JAAVSO. Vol 33, No 1, 2004
http://www.aavso.org/publications/ejaavso/v33n1/48.pdf
Back to Top
During late 2003 / early 2004 I incorporated my previous VBS script within a new program that was operated through a HTML Application (HTA) user interface. The picture above shows the main menu screen from the ' program version ('2.3') as it appeared in July-August 2004.
Although the VB/HTA programming methods did not provide any threading capability a workaround was developed to allow the program to be paused or gracefully aborted. The following screen shot shows the Script Controller tool that was used to provide this functionality. The script controller would write a small file to disk in a location monitored by the main program and used to signal whether a pause, resume or abort was required..
In around October 2004 I began working on a program version (2.4) which incorporated the "VMA program" within the "Telescope and CCD Imaging Scripts" program. The VMA interface was updated to allow separate reference and results files for the two VMA analysis scripts (1.2 & 1.3). The following shows the VMA Screen from this time.
Back to Top
2005 saw the continued development of scripts written in VBScript and operated through a HTML Application (HTA) user interface. Two parallel products of my Telescope and CCD Imaging Scripts program were maintained (a "Released' program" and a "Private Program").
The picture above shows the main menu screen from the 'Released' program version ('2.5.4') as it appeared in May 2005.
The "released version" was operated by Dale Mais as part of a Observing Programme looking at potential flare-up in Mira-type variables. It includes an upgraded version of the 2004 VMA Analysis sub-program for doing rapid batch photometric analysis of images of variable stars. Upgrades in 2005 included ability to use PinPoint Engine as alternative means of obtaining a plate solution besides the CCDSOFT method. A user guide was written - User Guide for 2.5.4 version.
A second version of the program was used for development and use in my own observatory. It incorporated additional scripts related to my own workflow. The following picture shows the main menu screen from the script in its final form in October 2005
The following screen shot shows the Image Targets sub program in action
Back to Top
In late 2005 I began porting the code into VB.Net. This took some time to perform as several new programming techniques and workarounds had to be mastered. However by beginning of 2006 the new program, "Astronomical Imaging Support (AIS)" was ready to take over duties in the observatory. The following picture shows the main menu screen :
All the previous program components from 2002-2005 where incorporated included Observatory/Target Imaging, Image Analysis and VMA Analysis. The VMA sub-program screen is shown below :
Extra features and enhancements have been added throughout 2006. These have included a Job Control screen which now lies at the heart of my image acquisition workflow.
a new facility to allow selection of object from TheSky's virtual sky to permit target compilation/planning,
and a new script for automating the astrometric analysis of specific stars
Back to Top
Between 2005 and 2011 there were a number of gradual improvements and enhancements to the AIS program and the code was ported first to VB express 2008 and then to VB Express 2010. The following picture shows the main menu screen in program in 2012.
A description of the various AIS programs is given below, with emphasis on new features added since 2006.
Session Planner Program (or Target List
Editor)
This is a new program section which was added since 2006.
The Reference List tab allows access to user defined reference lists and
previous session target lists to use/reuse imaging plans for specific objects or
add new ones/edit existing ones. Lists can be saved by same name or saved
as a new list. Individual Targets or All Targets can be moved to the
Observing Plan.
The Observing Plan tab allows use to build up a list of targets for observation/imaging along with their imaging details. Targets can either be moved into the plan from reference list tab or added as a new item. Rows can be added, duplicated , edited, deleted, moved up, moved down, sent to top of list, sent to bottom of list. The plan can be either saved or sent to Live List in the Observatory Program.
Observatory Program
The observatory program is used to run the observatory and execute an automated target acquisition and imaging job queue.
The Observatory Tab provides a visualisation of the observatory and its equipment along with a series of Connect/Disconnect buttons. Traffic lights and text show the status of various items of equipment such as the telescope, CCD camera, focuser and laptop.
The software has been written to allow the future control and visualisation of an observatory dome. Control is via an Arduino board & dome controller.
The Session Tab sets up a new Session.
The Scope Tab deals with alignment of the scope , with tools to aid polar alignment, T Point mapping , and other things.
The Camera Tab deals with adjustments of the focuser to provide optimal focus for the CCD images (including taking a focus profile and setting best focus position) and the acquisition of Dark, Bias and Flat Frames.
The Observing Tab deals with acquisition of image and images set under direct control of the user. It is also used to build Mosaic Imaging Plan and either execute it or sent it to job queue for later imaging.
The Job Queue Tab shows the current target/imaging plan and has many of the functions of Observing Plan tab in Session Planner. Targets can either be moved into the plan from the Session Planner or added as new items. Rows can be added, duplicated , edited, deleted, moved up, moved down, sent to top of list, sent to bottom of list. Control Buttons allow the Job Queue to be started, pause or stopped.
The Controller Tab has functions and options to adjust the run-time behaviour of an active Job, such as initiating or stopping guiding, or the building of a real-time light series.
The Sky Tab shows the quality of the images being taken. using traffic light coloured bars for Sky Transparency, Sky Brightness, FWHM, and either Star Elongation or Telescope temperature. This can be useful for showing when sky quality is degrading (from cloud in the sky, or from dew on the telescope), for spotting when scope needs refocussing or when seeing is deteriorating/improving or how wind shake is affecting the scope.
Image Reduction Program
This is a new program section which has been added since 2006 and is used to facilitate the reduction of raw images (by applying appropriate dark and flat frames)
The Session Tab selects the Session to be reduced.
The Reduction Workflow Tab provides a series of controls to facilitate my workflow for rapid handling and reduction of files from an observing session. Other buttons allow rapid access to specific folders or specific items of software.
The Reduction Tab provides a means to reduce a series of folders containing raw images of the same binning, exposure & filter. The 'Employ Masters'/'Employ Next' buttons will copy in the raw images into a processing folder, automatically finds and copies the associated Master Dark and Master Flat frames to Master Reduction Frames and then call CCDSoft Image Reduction/Reduce Folder button to perform the actual Reduction. These facility greater reduces the time and effort involved in reducing raw images, cutting down greatly the number of keyboard inputs and mouse actions.
The Sky Tab shows the quality of the C filter images that have been taken, using traffic light coloured bars for Sky Transparency, Sky Brightness, FWHM, and either Star Elongation. (This is the same tab that is used by the Observatory program for real-time image quality monitoring).
Image Analysis Program
This program section faciliates processing and analysis of reduced image sets and images files.
The Session Tab selects the Session to be analysed.
The Processing Tab lists the Target Image Sets collected during the session and provides various options for processing and manipulation of the image set.
The Analysis Tab provides a means to analyse the image currently open in CCDSoft (e.g perform an image link) and to perform certain other manipulations. The following picture shows a image that has been analysed to find and show Variable Star (V) and its associated Comparison (C) and Check (K) star.
VMA Program (Variable Magnitude Analysis)
The VMA program is used for performing rapid batch photometric analysis of images containing variable stars. The program is controlled and run from the VMA Tab. The program is based on versions first created in 2003-2005, but has been upgraded / enhanced.
After a number of incremental improvements and addition to the CCDApp2 (AIS) program between 2013 and 2017, including moving the code to VS 2012 / VS 2S 2015 , and the spawning of a separate program in 2014 for AllSKy Imaging (using Starlight XPress Oculus Camera) a major revision was made in 2018 with the inclusion of routines to control Pulsar Dome Observatory (via ASCOM Poth.Hub), and run in a fully automated mode, .with routines to access target details from SQLite database and acquire an observing plan and a move to VS 2017.
A description of the various new features is
described below
Observatory Manager
Observatory Manager is a service that runs as a threaded task in one of 3
modes
- Manual (the user controls observing operations, with
manager watching to ensure that observatory is kept safe by closing the dome
shutter if rain, high wind , heavily cloud or daylight is detected).
Option exists to override daylight checking to allow the observatory to be used
for solar observations.
- Semi-Automated (after the user starts
the observing session & initialises a target/imaging queue, the manager keeps
watch intervening to close the dome shutter in the event of advserse weather
conditions and later closing the observatory at the end of the night including
closing the dome shutter and parking the dome & telescope)
-
Fully-Automated (the manager runs the entire show; unparking the
dome & telescope, connecting the camera, selecting an observing plan for
the night, opening the dome shutter at appropriate time time subject
to acceptable weather conidtion, executing the target/imaging queue whilst
keep watch for Rain, High Wind and Cloud that would require closing the dome
shutter, and closing the observatory at the end of the night. Waits until the
next night to repeat the process.)
A key aspect of Semi-Automated and Fully-Automated operation is the monitoring of a night session through a sequence of 'session states'.
Session States
Pending : Session has not yet started
Session remains in
this state until Dusk is reached and weather conditions & forecast are
favourable for observing and the observatory is not 'Locked Down' (State moves
to Starting). Alternativley if midday is reached the Session
is deemed as finished (State moves to 'Finished')
Initiating: The session
is initiating
Session enters this state when Dusk is reached and weather
conditions & forecast are favourable for observing
- Observatory Plan is
loaded (this may be a completely auto-generated plan if no plan has been created
by the user beforehand)
Session remains waiting in this state until around 20-30 minutes before
the scheduled Start Time of the Observing Plan and weather conditions are
favourable for opening the observatory dome (state moves to 'Starting').
Opening: The session is
opening
Session enters this state around 30 minutes before the Observing
Plan's scheduled Start Time
- Telescope is unparked
- Telescope and Dome are
connected
- Camera is connected and temperature regulation commenced
If weather conditions & forecast are favourable the shutter is
opened in order to allow observatory equipment to equilibrate with the outside
air temperature prior to observing (State moves to 'Equilibrating'). If
weather condition and/or forecast deteriorate the shutter will remain shut.
At a certain point the session will be deemed null & void (State moved to
'Closing')
Equilibrating: Observatory is equilibrating with
shutter open, and potentially headed into the wind.
Session enters this
state in order to allow temperature of observatory and equipment to equilibrate
with the outside temperature.
Session remains in this state until the
Observing Plan's scheduled start time (state moves to 'Running')
(the
equilibration step may be very short if weather conditions are initially
unfavouable and the Observing Plan's scheduled start time is passed).
Running: Observing plan is actively
running
Session remains in this state conducting observing plan until it
has either completed or end of night is reached (State moves to 'Closing') or
Weather Conditions require the Dome Shutter to be closed (State moves to
'Suspended')
Suspended: Observing Plan is
suspended (usually due to Weather Conditions)
Session enters this state if
Weather Conditions become unfavorable during the execution of an Observing Plan
and the Dome Shutter needs to be closed or there is passing cloud
Closing: Session is closing
(dome shutter closing, dome parking, telescope parking, cameras closing)
Session enters this state after completing an Observing Plan, the end of the Night is
reached or Observatory is placed in 'Lock Down'
Session remains in this state
until all equipment has been safely parked and/or closed down (state moves to
'Housekeeping')
Housekeeping: Conducting housekeeping
& administration at end of session
Session enters this state after
observatory equipment has been made safe following execution of an observing
plan.
Session remains in this state until housekeeping & other administration
are completed (state moves to 'Finished')
Finished: Session has finished.
Session enters this state following an actual observing session or session
attempt, or directly if the session hasn't been started but the time expires
Under Fully-Automated Operation the session remains in this state until the next
Night Date is reached (state moves to 'Not Started')
Under Semi-Automated
Operation the session remains in this state until the human observatory operator
(user) intervenes.
Automated Observatory
Main Hazards
- Rain
- Snow
- Wind
- Sunlight
- Camera running into Mount
- Telescope cables getting
wrapped around Pier
- People / Animals
- Self
(Human Error)
Risks to the Safe Operation of the Observatory
| Risk | Risk Description | Rating | Control | Control Implemented | 'Must Close' Trigger | Tested ? | |
| Rain |
Dome shutter is open whilst it is Raining or Snowing leading to damage to observatory contents (telescope, equipment, computer, electrics, shelving etc.) |
H / H | a) Cloud Sensor measurements used to identify heavy cloud overhead capable of producing rain or snow | Yes | Clarity values < 20 or (Data Outage > 5 mins and Mode<>"Manual") |
Yes | |
| b) Local Rainfall Radar data used to identify potential imminent precipitation at or near to observatory site | Yes | DarkSky Net Forecast forecast of rain (any) at observatory location in the next 15 minutes | Yes | ||||
| c) Rain Detector measurements used to identify the actual occurrence of rain or other precipitation | Yes | Rain values > 1 (or >0.1 for 5 mins) or (Data Outage > 5 mins and Mode<>"Manual") |
Yes | ||||
| d) Software Dome Lock available to prevent Observatory Manager from opening dome (regardless of current conditions) and to enable a re-closure command if dome is otherwise opened | Yes | Software Lock = On | Yes | ||||
| e) Observatory Manager running and monitoring conditions continuously. Robust logic / robust command chain to Close Dome if any of the Rain Triggers are raised. | Yes | ||||||
| f) AstroGuard Program (a separate program) is running and intervenes to Close Shutter if AstroMains's Observatory Manager stops running or is otherwise unresponsive. | Partly | Observatory Manager unresponsive for 15 mins or Rain values > 1 and Shutter Open > 1 min |
No | ||||
| Residual Risks involving Rain in the presence of other factors | |||||||
| Rain (residual) |
Failure of POTH.Hub and/or USB Connection leaving Observatory Manager unable to command the Dome Controller to close the Shutter in the event of rain | H / H | Possibility of building an automatic restart /reconnection program to make things safe | No | No response from POTH.Dome after say 10 or20 mins | ||
| Rain (residual) |
Failure of Main Computer meaning that there is no process running to command the closure of the Dome Shutter in the event of Rain | H / M | Possibility of having the AllSky Computer monitor the Main Computer in someway and send an email in the event of it going offline unexpectedly with another follow-up email in the event of actual or imminent rain. | No | Observatory Manager unresponsive for 15 mins or Rain values > 1 and Shutter Open > 1 min |
No | |
| Rain (residual) |
Observatory Computer unexpectedly crashes meaning that the primary control programs (AstroMain & AstroGuard are no longer running to command the closure of the Dome Shutter in the event of Rain) | H / M | AstroProtect. In cases where Computer restarts (normal response to Computer crash) the AstroProtect program executes during Windows start-up to automatically check and if necessary closer the shutter and park the Dome. | Yes | Dome Open when Computer boots | Yes | |
| Relay. In cases where Computer hangs and or otherwise doesn't automatically restart following a crash a direct relay connection between Cloud/Rain Sensor and Dome Controller closes the Shutter in event of Rain, Cloud or Light | No | Values as set up using Cloud Sensor III | No | ||||
| Rain (residual) |
Failure of Main Computer A/C Adapter or Power Supply meaning that its battery becomes drained down, forcing the computer into sleep or hibernation and leaving it unable to command closure of Dome Shutter in the event of Rain | H / M | Observatory Manager monitoring is used to detect A/C power outage and low battery strength, and command Dome to close as a precaution against computer going into hibernation. | No | On Battery and battery < 20% | No | |
| Rain (residual) |
Power Cut whilst Shutter is open leaving the Dome Controller unable to respond to commands to Close the shutter. | H / M | AutoClose feature. After a set period of time with no Bluetooth messages from the Dome Controller the Shutter Drive unit will automatically close the Shutter (provided shutter wasn't opened with the manual button in the first place) and AutoClose has been enabled & a Close Time has been set. | Yes | No response from Dome Controller 5 mins (minimum time setting) |
Yes | |
| Rain (residual) |
Depleted Battery on Shutter Drive leaves it unable to close. | H / L | a) Dome to always be parked at end of each session allowing it to always be induction charged and ready for next session. | Yes | n/a | ||
| b) Battery strength used to identify whether system is entering risky territory (not sure if value is available in ASCOM !) | No. |
Battery Strength < 25% | No | ||||
| c) Manually monitor battery condition in order to spot any problems with the battery performance and risk of failure. | No | n/a | |||||
| d) Limit the number of open/close events during each session to preserve battery, drive chain, drive motor. | No. (but events are measured) |
||||||
| Snow (residual) |
Snow blows into the observatory via the gap between roof and closed shutter leading to water damage damage to observatory interior and/or contents | M / M | a) Manually Monitoring of weather forecast and if there is a probability of snow to manually place temporary wadding in gap between roof and closed shutter. (combine this with using Software Dome Lock to ensure observatory is not used in this state) | Yes | n /a | ||
| b) Rotate Dome into Wind Direction, in order to place the gap at top of the dome into the lee of the wind. | No | Manual Option at present |
|||||
| Wind |
Dome shutter is open during Strong Wind / Wind Gusts leading to damage to observatory dome or contents |
H / M | a) Wind Measurements used to identify current/recent strong wind | Yes | Wind values > 20 | Yes | |
| b) Weather Forecast Data used to identify potentially strong winds | No | DarkSky Net Forecast of strong wind at observatory location in the next 2 hours | No | ||||
| c) Software Dome Lock available to prevent Observatory Manager from opening dome (regardless of current conditions) and to enable a re-closure command if dome is otherwise opened | Yes | Software Lock = On (set by User) |
Yes | ||||
| d) Observatory Manager running and monitoring conditions continuously. Robust logic / robust command chain to Close Dome if any of the Wind Triggers are raised. | Yes | ||||||
| Wind (residual) | Problem with Observatory PC or connection with Dome Controller prevents the closure of the Dome in conditions of high wind | Metal Dome Clamps present to prevent wind lifting the entire fibreglass roof at all times | Yes | n/a | Yes | ||
| Light | Dome shutter is open whilst it is daylight leading to damage to telescopes & cameras due to sunlight entering their optics | H / M | a) Light Sensor measurements used to identify approaching daylight | Yes | Light values > 10 (and Operating Mode <> 'Manual') |
Yes | |
| b) Sun Altitude from TheSky6 used to provide the current Sun Altitude to identify approaching daylight | Yes | Sun Alt > -2 deg (and Operating Mode <> 'Manual') |
Yes | ||||
| c) Observatory Manager running and monitoring conditions continuously. Robust logic / robust command chain to Close Dome if any Light or Sun AltitudeTriggers are raised. | Yes | ||||||
| Light (residual) |
Problem with Observatory PC or connection with Dome Controller prevents the closure of the Dome at day-light. | Relay. In cases where Dome Closure can't be commanded from the Observatory PC a direct relay connection between Cloud/Rain/Light Sensor and Dome Controller closes the Shutter in event of excessive (day time) Light | No (in action) |
Values as set up using Cloud Sensor III | No | ||
| Equipment | Camera runs into Mount Base leading to damage to camera, telescope mount and other equipment | H / M | a) Declination Limit set in TheSky6 to prevent slew to declinations above a certain figure | Yes | Dec > disalllowed | Yes | |
| b) Declination Limit in CCDApp2 to prevent to slews to declinations above a certain figure | Yes | Dec > disallowed | Yes | ||||
| c) Anomaly Checking. Anomalies in telescope position vs camera pointing are diagnosed / self tested before continuing | (Yes) | Any unexplained Issue | |||||
| Cables to Telescope get wrapped around pier leading to damage to cables, connections, cameras, telescopes and other equipment. | M / M | a) Telescope Tracking is turned off whilst waiting to commence the session or whilst session is suspended | Yes | n/a | Yes | ||
| b) Anomalies in telescope position are diagnosed / self tested before continuing | No | Any unexplained Issue | |||||
| c) Special Azimuth Exclusion Zone to prevent slewing to targets with Azimuth 340 deg+ | Yes | Target Az > 340deg disallowed | No | ||||
| d) Observatory Manager running and monitoring scope position
continuously with possible forecast of potential position if scope has
disconnected or can't be reconnected. Possible Option of Last Resort to turn-off 12V Power to the Scope |
No | No | |||||
| Problem with Observatory PC or scope connections issues prevents the 'over' rotation of the scope | Control Needed | ||||||
| This Web Page: | Scripting |
| Last Updated : | 2018-12-28 |
| Site Owner : | David Richards |
| Home Page : | David's Astronomy Web Site |
