The first maintenance release in the 4.4.X series will deal with switches. Specifically:
Sequencing Delays
You’ll now be able to specify any arbitrary amount of time that SGPro will wait prior to starting the sequence. This can be for any reason but is typically requested in order to allow for initialization cycles for gear in your rig gated by power switches.
For instance, the screenshot below sets sequence start state and then allows your gear a full 30 seconds to initialize before starting the sequence (and attempting to connect to required gear)
You can get to these settings by clicking on the gear icon on the top left of the switch list:
Ordering Delays
For switch states that exist within the same grouping (e.g. start states or end states), you’ll now be able to enforce an ordering for setting the desired states. The unit here that governs the ordering is “seconds” in that the intent is to say: After starting the sequence, this switch will wait some number of seconds prior to attempting to set the desired state.
It is important to note that the “seconds” values used for ordering are approximations and their accuracy depends heavily upon the state setting requests that occur before it. In other words, if you have a request to set state for Switch 1
at Start + 5 sec
and Switch 2
at Start + 10 sec
, but Switch 1
is having some kind of trouble and takes 30 sec
to resolve, Switch 2
state will be set immediately afterward (as close as possible to the requested delay, but completely missing the requested Start + 10 sec
request).
You should interpret orderding delays as timing requests that may or may not be fulfilled. While you cannot depend on the exact time of a switch state, you can depend on the implied ordering to be honored. In other words, using the example above, even if the exact timing for Switch 1
and Switch 2
cannot be honored, you can be rest-assured that SGPro will attempt to set Switch 1
before Switch 2
.
Now, in SGPro 4.4.1, right-clicking on a switch will show the following options:
The areas highlighted in red show how you can define a delay / ordering for an individual switch. If you don’t check the option to use a custom delay / ordering for a sequence state, the switch will default to using the default state delay. The info below each checkbox will tell you more about that. The default values for delay can be found in the new “Switch Properties” dialog:
Global Switch Settings
These default delay values could be useful in any number of ways, but as an example: Say you have 10 switches that are set to specific, user-defined values at sequence start and nine of these 10 switches have a dependency on the state of Switch 1
having been set, you could define a global, default delay of Start + 20 sec
and then, for Switch 1
define a custom delay of Start + 0 sec
. When the sequence runs, it will set state for Switch 1
immediately and then, 20 seconds later, set state for the remaining 9. This custom delay configuration only required that you alter two different settings (and not ten).
You can get to these settings by clicking on the gear icon on the top left of the switch list:
Note: Ordering for switches that have the same delay cannot be guranteed, but you can adjust delays by even as little as a tenth of a second to enforce an ordering between switches. e.g. A switch with a delay of Start + 1.1 sec
will always be set prior to a switch with a delay of Start + 1.2 sec
.
It’s not perfect, but, for most, you’ll be able to tune these delays to the specifics of your rig.
Bugs
A bunch of bugs dealing with how SGPro caches switch data have been addressed. A lot of these bugs may have only been seen with ASCOM DigitalLogger
based on how its name changes based on its own internal status.
SGPro 4.4.1 has completely refactored how it refers to switches internally, but it should definitely be more stable. Sequences and Equipment Profiles will be migrated to the new format automatically.
Specifics:
- A bug where SGPro would lock the UI for long-running connection requests to a Switch Device has been corrected.
- A bug where SGPro would not properly interpret Switch Device state cache for sequence switch states where the parent device is not installed on the current system.
- Fixed a bunch of bugs related to “Orphaned Switches”. You’ll see the notion of orphaned switches if you move to a new system and uninstall the original driver. SGPro does not delete these but instead adds them as read-only orphan switches so you have a reference.