There are many features of Scheduler that apply to specialized or advanced usage. This page briefly describes each of them.
Post-Run (Dawn) Dark and Bias Frames
Rising Plan Delay
Monitor Mode
Close-If-Idle
Custom Image/Log Folder and File Naming
Redirecting Scheduler Engine Logs to Custom Folder (e.g. for Web-Visibility)
Email Alerts
Operator Intervention Program
Command Line Switches
Run Detail Analyzer
Best Efforts Plans
Fixed Time Plans
Periodic Autofocus
Sun Down Altitude
Moon Down Altitude
Strict Auto Guiding
Aggregated Auto Guiding
Image Compression (zipping)
Subframe Support
Defocusing Support
Readout Mode Support
Suppress Web Previews
Suppress Data Image Plate Solving
Test Project Generators
Utility Menu Test Functions
Efficiency Function Weights
Custom User-Written Constraints
VOEvent Receiver
Sky Condition Input
Alternative Observing Logic
The scheduler has an option to delay the start of plans to let them rise higher in the sky. Without this feature, a plan will start (if possible) when its constraints are first met. This means that some of the data will be acquired as low (in the east) as possible. If the scheduler is under-subscribed, it may be advantageous to let the plan "rise" so that its observations will be acquired around the meridian. By default, this "rising plan delay" feature is enabled. To disable it, open the Configuration window (Scheduler menu) and change the rising plan delay value (engine section) to false.
Often, particularly for photometric work, you'll want an observing plan to be repeated every night (or every few nights) for some period of time. Monitor Mode makes this easy. Set the "Monitor Interval" for the Plan to the number of days you want between automatic re-runs of the Plan. Set the "Must run before" time to the date/time after which you no longer want the Plan to be re-run periodically. If you leave this blank, the plan will be re-run periodically forever.
RTML 2.3 does not support Monitor Mode. However you can use the feature by putting the text Monitor=n in the Reason attribute of the RTML Request (where n is the resubmission interval in days).
It is possible to tell the scheduler to close the dome or roof if it appears that there will be nothing to do for more than n hours, where n is a configuration option. Note that if there is nothing at all to do on a night, the observatory will start up, open if the weather is safe, then close at the beginning of observing time (but still be left running in standby). If new work is added, it will open at the time for that work to be done. This feature can be disabled by setting n to 0 (the default setting). If the dispatcher is started after astronomical twilight and the dome/roof is closed, then it will not open until there is work to do. Therefore, if you must have thermal stabilization at the beginning of the evening, be sure to start the dispatcher around local sunset!
You can override the standard image folder and file naming used by Scheduler. Open the file Sample-ImageFileConfig.txt with Notepad and read the instructions there. This file can contain a template for the complete path/name for image files. There are over 15 dynamic substitution tokens that you can put into your template line. These will be replaced by the current values of the tokens each time a file path/name is constructed.
Once you have made your edits, save the file as ImageFileConfig.txt (without the Sample-) to make your changes active.
Keep in mind that you can alter both folder paths as well as image file names. Folders are automatically created as needed.
Similarly, you can override the standard ACP run log folder and file naming used by the Scheduler. Open the file Sample-LogFileConfig.txt with Notepad and read the instructions there. This file can contain a template for the complete path/name for image files. These will be replaced by the current values of the tokens each time a file path/name is constructed.
Once you have made your edits, save the file as LogFileConfig.txt (without the Sample-) to make your changes active.
The custom folder and file name template applies to all images acquired by the scheduler. You can also specify overriding folder names for entire projects, plans, observations, and image sets while working with the Schedule Browser. Right click on a tree node and select Folder for ImageSets. You can then browse folders (and create new folders). When you complete the folder selection it will be applied to all image sets under the tree node you selected. The same option can be used to remove/clear previous folder overrides.
The Folder field in the ImageSet window can be used to override the default folder for a single image set.
You can change the location into which the Scheduler writes its log files (as opposed to the logs of ACP observing activity). This feature was added so that Scheduler logs could be made web-visible or mapped to a DropBox folder. To do this, redirect the logs to ACP's web document root, in its files subfolder. This folder is visible to all ACP web users. Or you may want to have the logs written elsewhere like to a network share. Be careful, though - if the network share goes down, the Scheduler will die. The setting is located in the Dispatcher section of Scheduler's configuration window.
The scheduler can be configured to send email to one or more addresses when any of the following events occur:
In addition to the above alerts, if the Plan Notices option is set to True, emails will be sent to Project owners or Observers upon completion or failure of an entire Plan. A Plan completion email will be sent if:
The search for a possible Plan completion email is in the above order. The only requirements for a field to contain an email address is for the field to have an '@' in it, and for it not to be "your@email.here" (which is added by the RTML importer).
If either of these fields have an '@' in them, the field must contain a valid email address.
The settings for email alerts are in the Configure window (Scheduler menu, Configure..., section 3). Before enabling email alerts, you'll need to set up the email address(es) to which alerts should be sent, and the domain name or IP address of the outgoing email (SMTP) server that will deliver the alerts. Most email (SMTP) servers require transport security, most often this is TLS. Some older servers use SSL3, and even more rarely, you may encounter an SMTP server that does not support any transport security. These three possibilities can be selected in the configuration form. If your email server is on a non-standard TCP port, you can include the port number after the IP address or domain name, separated by a colon, for example, smtp.someserver:8025. In addition, if your SMTP server requires authentication, fill in the username and password needed. If not, be sure to leave the username blank to suppress the sending of authentication info. Finally, you can customize the From: address that appears in the generated emails. Note that both the address and "display name" can be specified (comma separated). If you don't need a display name, leave the comma out. Note that some email providers will limit what can appear in the From: address in order to help prevent SPAM.
GMail has recently instituted enhanced security requirements, where its clients either must do OAuth2 authentication or 2-Step Authentication. Scheduler does not implement OAuth2 authentication (yet) so to get email alerting with GMail's mail sender, you will need to enable 2-Step Verification on your Google account. If you don't want to do this for your day to day Google/GMail account, just create a separate GMail account for Scheduler and set up 2-Step Verification on that account. Once you have that working, generate an App Password for Scheduler. This will be a 12 character code. Let's say your scheduler's GMail address is acps49108@gmail.com, then the settings would be something like this:
Note that you can still tailor from visible From address so it looks nicer.
Once you have configured email alerting, run a test to make sure it's set up correctly. In the Scheduler's Utility menu, there is a Test Email Alert item. Select it. If the message is sent successfully, you'll see nothing. Check your email or phone to make sure the message got to you. If there is an error in your setup, you'll see a balloon popup on the system tray indicating an error. Note that if the "to" address is wrong, you won't see any errors! The message will go somewhere (wrong!). Scheduler is unaware of bounce-backs.
Finally, if you want the plan completion/failure notices to be sent, turn on "Plan Notices".
When the scheduler encounters a serious error (which may come from all sorts of places) at the observatory, it can be configured to execute a specified program with a specified command line. See the Configure window in the Dispatcher section. It will look for the executable in the Scheduler installation directory and then in Windows\System32. You can specify cscript.exe here and then the command line will be used as the name of a Windows script (.js or .vbs). The program (whatever it is) will be executed with the Scheduler installation directory as its "working" directory. Thus you can simply specify the name of a script file if it's in the Scheduler installation directory. Of course you can use any sort of program you want here. If the program is not in one of the previously mentioned places, you have to specify the entire path and name.
The scheduler program Scheduler.exe has two command line options:
In addition to the engine log file, Scheduler produces a file called RunDetail-xxxx.txt (where xxxx is a date-time string) at the same time the engine log is saved (when the scheduler exits or mid-day local time). It also goes into the My Documents\ACP Observing\Scheduler Engine Logs folder. This file contains data about all observations since Scheduler was started (perhaps several nights).
The run detail file is intended to be used as input to the analysis spreadsheet RunDetailPlotter.xls. This spreadsheet requires Office 2000 or later. It is accessible from the Start menu. The Excel security level (Tools/Macros/Security) must be set to medium or low. Once it is open, switch to the Control tab (if needed) then click the button. You'll be asked to specify the Run Detail file you want to analyze. Open it and the plots will be updated. Look at the various plots to see how the scheduler did.
This is mainly useful for long time series with many linked Observations. If a Plan is marked Best Efforts, several restrictions are removed. The idea is to start the plan even though it might extend past daylight or some linked Observation would clash in time with another in an already running Plan. If a linked Observation misses its time slot, it is failed but the Plan continues to run. If you have one or more of these, you should mark them all Best Efforts! If there are any time series that are not marked Best Efforts mixed in with ones that are, you can almost be guaranteed that one of their Observations will miss its time slot, and that series will immediately fail. This behavior is a compromise, and not perfect. Be careful when using Best Efforts!
Best Efforts Plans will not fail if an Observation encounters an autoguiding failure. Instead, the Observation will proceed unguided. This feature is yet another compromise. The idea is to work through passing clouds, allowing an Observation to be "bad" (due to lack of guiding), yet allowing the Plan to continue. If the Observation were terminated for guiding failure, the next one might run right away, etc., causing a cascade of Observation failures, effectively ending the Plan anyway!
It is sometimes required that some observations be done at a specific time. Since Scheduler is a dispatching scheduler, it normally doesn't know when a particular Plan will be started. You can override this behavior and specify that a Plan be run at a specific time. When the scheduler is started, all of these fixed-time Plans are dispatched, thereby occupying their time-slots and preventing dispatched Plans from overlapping them.
To make a Plan run at a fixed time, fill in the start and end times then check the Fixed-Time option. If you do this while the scheduler is running, the fixed-time Plan will be dispatched at the next scheduler cycle.
Don't use fixed-time plans unless you absolutely must. Clearly, if all of your plans are fixed-time, there is no need for the scheduler at all!
You can set up Scheduler to automatically do an auto-focus on a periodic basis. Open the Configuration window (Scheduler menu) and change the periodic auto focus interval value (engine section) to the number of hours (can be fractional) between auto-focus tasks. If any Observations specify auto-focus, those tasks will restart the interval. Thus, the periodic auto-focus interval is the maximum time between auto-focus tasks. Set this to zero to disable periodic autofocus.
NOTE: Periodic auto focus will not be done within an Observation! Also note that if ACP is set for FocusMax (as opposed to PWI), Scheduler's autofocus will move the scope to a point 70 degrees up to focus. Finally if periodic autofocus is enabled, the autofocus checkbox will be hidden in the web submission forms and the web schedule browser.
Normally, Scheduler assumes that observing should start and end at astronomical twilight, when the Sun is 18 degrees below the horizon. ACP Scheduler instead defaults to 12 degrees below (-12 deg altitude). You can change this behavior. Open the Configuration window (Scheduler menu) and change the Sun Down Altitude value (engine section) to suit your needs. You can use the Utility menu, SkyMath Display to show the selected values and the effects of changes.
Normally, the Moon Down constraint considers the Moon to be down when it is 2 degrees below the horizon (-2 deg altitude). You can change this value. Open the Configuration window (Scheduler menu) and change the Moon Down Altitude value (engine section) to suit your needs. You can use the Utility menu, SkyMath Display to show the selected values and the effects of changes.
Unless the Plan is marked BestEfforts, if the guider fails to start the image acquisition fails, ending the entire Plan with failure. You can change this so it continues unguided instead. Typically you'd do this in an attempt to handle the "passing clouds" problem. To make guiding failures non-fatal, you need to edit AcquireScheduler.vbs. Locate the statement Const STRICT_AUTOGUIDING = True and change the True to False.
Normally, if the sum of exposure times within a single ImageSet exceeds ACP's Maximum Unguided Exposure interval, the guider will be started. If guiding fails, but the individual exposures in the ImageSet are short enough to be unguided, the exposures will be completed ungiuided and barring other problems the ImageSet will complete normally. If the individual exposures are longer than ACP's Maximum Unguided Exposure interval, guiding failures will be handled as described in the preceding section.
NOTE: Aggregation of exposure times for guiding decisions can be disabled with the aggregation setting in ACP Preferences, Guiding tab.
You can have all of the images taken by Scheduler be compressed (zipped). Compression is done using the 7-Zip program, and the compressed images are compatible with most Windows and Linux programs. This is controlled by the ACP web user's compression setting. Local observers don't get compression.
When you use the Generate Test Project feature of the Scheduler, the projects that are generated are controlled by a set of configuration characteristics. Each of the plan type generators (single, asteroid, LRGB, etc.) have some parameters that you can adjust. In addition, you can change the low horizon and the load factors for Light, Moderate, and Overbooked selections in the test plan generator window. You can use test projects with the Simulator or for live work with your observatory. Open the Configuration window (Scheduler menu) and look for the test plan generator common section as well as the individual test plan generator sections. Change them to suit your needs.
The Utility menu has test functions for dusk and dawn autoflats, dawn cal frames, autofocus, startup and shutdown. The intention is for these to be used with the Scheduler in the Day/Night ACP mode, and with ACP set to Simulated Images. Use these to test your special scripts and flat/cal frame plans during the day, so you can be sure they'll run properly when live. There is also an email test function. If you have Scheduler set to send email, you can have it send a test message so you can be sure that you have set email up correctly.
You can adjust the weighting given to the various factors that determine the "best plan" to start at dispatch time. For information on how this works, be sure to read the paper Dispatch Scheduling of Automated Telescopes. The user (custom) efficiency weights are located in the "custom efficiency weights" section of the configuration window. Be sure to switch the dispatcher to Custom mode. While experimenting with your own efficiency weights, it is strongly suggested that you use the Run Detail Plotter spreadsheet to analyze the behavior of the scheduler. Changes to Efficiency Function weights can cause unexpected (and sometimes undesirable!) behavior.
The set of constraints supported by the scheduler are provided by plug-ins. Custom user-written plug-ins are supported. Scheduler includes a Constraint Software Development Kit (SDK) for Microsoft .NET 2005 and 2008. Plug-ins are Microsoft.NET assemblies that implement a standard interface. Simply dropping the plug-in into a directory is all that's needed to activate it in both the Browser and the Scheduler.
See Customizing the Receiver in the VOEvent Receiver info. Please note that this extensive project has not realized its potential. It is sort of a "white dwarf" system at present; people are still having meetings about it, and it is supposed to be a big deal when LSST comes online.
See Constraints, Sky Condition. Besides manually selecting the sky condition on the Scheduler main window, the Scheduler can have its sky condition fed from an external server. The sky condition server must be an Automation/ActiveX object and have just two properties:
To enable the external sky condition server, fill its object ID ("progid") into the Scheduler's configuration form, Dispatcher section, Sky Condition Server ID field. A sample sky condition server is provided as a Windows Script Component. Have a look at the file SkyServer.wsc that is shipped with Scheduler.