### Server and Client Setup Steps Source: https://tcpalmer.github.io/nina-scheduler/synchronization To get started with synchronization, create NINA profiles for server and client instances, then create corresponding sequences. Start the server NINA instance first, followed by any client NINA instances. Each instance must use a unique profile. ```text Create NINA profiles appropriate to your server and client instances. Create sequences for your server and client instances. Start NINA using the profile for the server instance. Start NINA using the profile for the client instance. In this case, ‘start NINA’ means to run NINA itself (and select the appropriate profile). The first instance started becomes the server; all others become clients. _Running the sequence_ on any instance doesn’t have any bearing on which is the server or client. Once the server and client instances of NINA are running you can load the sequence appropriate to each and start the sequences. ``` -------------------------------- ### Notes on Target Start Messages Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Provides clarification on the order of operations for target start messages and the definition of a 'new' target. ```APIDOC ## Notes on Target Start Messages ### Order of Operations TS sends target start messages in the following sequence: 1. If the target is _new_, send the `New Target Start` message. 2. Send the `Target Start` message (always sent). 3. Slew/center to the target (if necessary, e.g., for a new target or after an interruption). 4. Execute any instructions in the 'Before New Target' custom event container. 5. Execute the regular plan instructions. ### Definition of a 'New' Target A target plan is considered _new_ under the following conditions: * It is the first target of the night. * It is different from the previous target. * It is the first target after an interruption (e.g., a safety interrupt). ``` -------------------------------- ### New Target Start Message Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Details the message published when the TS planner identifies a 'new' target to start. ```APIDOC ## Starting a New Target When the TS planner returns a target plan and the target is considered 'new', a **_new target start_** message is published. ### Topic `TargetScheduler-NewTargetStart` ### Version `2` ### Content * **(string)**: The name of the target. ### Expiration * The target end time. ### Headers * **ProjectName** (string): The TS project name for the target. * **Coordinates** (NINA.Astrometry.Coordinates): The coordinates of the target. * **Rotation** (double): The rotation angle for the target as entered in the TS UI. * **ExposureFilterName** (string): The name of the filter for the selected exposure. * **ExposureLength** (double): The length of the selected exposure in seconds. * **ExposureGain** (string): The gain setting for the selected exposure (or '(camera)' if defaults to camera setting). * **ExposureOffset** (string): The offset setting for the selected exposure (or '(camera)' if defaults to camera setting). * **ExposureBinning** (string): The binning mode of the selected exposure (e.g., '1x1'). ``` -------------------------------- ### Target Start Message Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Describes the general message published when the TS planner returns any target plan. ```APIDOC ## Starting a Target When the TS planner returns a target plan, a **_target start_** message is published, regardless of whether the target is new or not. ### Topic `TargetScheduler-TargetStart` ### Version `2` ### Content * **(string)**: The name of the target. ### Expiration * The target end time. ### Headers * **ProjectName** (string): The TS project name for the target. * **Coordinates** (NINA.Astrometry.Coordinates): The coordinates of the target. * **Rotation** (double): The rotation angle for the target as entered in the TS UI. * **ExposureFilterName** (string): The name of the filter for the selected exposure. * **ExposureLength** (double): The length of the selected exposure in seconds. * **ExposureGain** (string): The gain setting for the selected exposure (or '(camera)' if defaults to camera setting). * **ExposureOffset** (string): The offset setting for the selected exposure (or '(camera)' if defaults to camera setting). * **ExposureBinning** (string): The binning mode of the selected exposure (e.g., '1x1'). ``` -------------------------------- ### Wait Start Message Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Describes the message published when the TS planner initiates a wait period. ```APIDOC ## Starting a Wait When the TS planner returns a 'wait' period, it publishes a **_wait start_** message. ### Topic `TargetScheduler-WaitStart` ### Version `2` ### Content * **(DateTime)**: The time when the wait period ends. ### Expiration * The wait end time. ### Headers * **SecondsUntilNextTarget** (int): The number of seconds to wait until the next target starts. * **ProjectName** (string): The TS project name for the next target. * **TargetName** (string): The TS name for the next target. * **Coordinates** (NINA.Astrometry.Coordinates): The coordinates of the next target. * **Rotation** (double): The rotation angle for the next target as entered in the TS UI. ``` -------------------------------- ### NINA Sync Server Basic Sequence Example Source: https://tcpalmer.github.io/nina-scheduler/synchronization A minimal sequence structure for a NINA sync server, focusing on synchronization actions. It uses '_Target Scheduler Sync Wait_' instructions to coordinate an initial autofocus operation with clients. Dependencies include equipment connection and camera cooling. ```NINA Sequence Script Sequence Start Area Connect Equipment Cool Camera Sequential Instruction Set: Prep Server Wait For Target Scheduler Sync Wait Slew To Target Scheduler Sync Wait Autofocus Target Scheduler Sync Wait Sequential Instruction Set: Image Server Target Scheduler Container Sequence End Area Warm Camera Park Scope Disconnect Equipment ``` -------------------------------- ### NINA Sync Client Basic Sequence Example Source: https://tcpalmer.github.io/nina-scheduler/synchronization A minimal sequence structure for a NINA sync client, designed to synchronize with a sync server. It includes a matching number of '_Target Scheduler Sync Wait_' instructions and uses '_Target Scheduler Sync Container_' to align with the server's image acquisition. Dependencies include specific equipment connection (camera, focuser, filter wheel) and camera cooling. ```NINA Sequence Script Sequence Start Area Connect Equipment Cool Camera Sequential Instruction Set: Prep Client Target Scheduler Sync Wait Target Scheduler Sync Wait Autofocus Target Scheduler Sync Wait Sequential Instruction Set: Image Client Target Scheduler Sync Container Sequence End Area Warm Camera Disconnect Equipment ``` -------------------------------- ### Example Output of File Pattern with Session Identifier Source: https://tcpalmer.github.io/nina-scheduler/flats Illustrates the resulting filenames after applying the image file pattern that includes the $$TSSESSIONID$$. This shows how the session identifier is embedded, enabling the grouping of related light and flat exposures. ```text M31\2023-12-01\LIGHT\Lum\SESSION_0023\etc M31\2023-12-07\FLAT\Lum\SESSION_0023\etc ``` -------------------------------- ### NINA Synchronization Plugin Overview Source: https://tcpalmer.github.io/nina-scheduler/synchronization The existing NINA Synchronization plugin allows multiple OTAs/cameras on a single mount by enabling communication between NINA instances. It synchronizes activities using custom instructions within sequences, with a primary NINA instance (server) handling mount and guiding, and secondary instances (clients) taking exposures and waiting during primary mount operations. ```text The existing NINA Synchronization plugin provides support for multiple OTAs/cameras on a single mount with a single guider. It does this by setting up communications between two or more running instances of NINA and then synchronizing some activities via custom instructions in each sequence. The main use case is to have a primary NINA instance (server) handle mount operations and guiding and then synchronize with secondary instances (clients), so they can take exposures when the primary is but then wait while the primary is doing any mount operations (slew, dither). ``` -------------------------------- ### NINA Sequence Example with Target Scheduler Condition Source: https://tcpalmer.github.io/nina-scheduler/sequencer/condition This example demonstrates the usage of the Target Scheduler Condition within a NINA sequence. It shows how to use the 'While Targets Remain Tonight' mode to control both a 'Night Container' and an 'Acquisition Container', ensuring the sequence concludes when no more targets are available for the night. ```NINA Sequence Normal Sequence Start Night Container Target Scheduler Condition: While Targets Remain Tonight Instructions Acquisition Container Loop While Safe Target Scheduler Condition: While Targets Remain Tonight Instructions Open Dome Shutter Unpark Scope Target Scheduler Container Manage Unsafe Container Loop While Unsafe Instructions Park Scope Close Dome Shutter Wait for 5 min Normal Sequence End ``` -------------------------------- ### Image File Pattern Example with Session Identifier Source: https://tcpalmer.github.io/nina-scheduler/flats Demonstrates how to incorporate the $$TSSESSIONID$$ custom image pattern into a file naming convention within NINA's Imaging options. This allows for automatic inclusion of the session identifier in saved image filenames, facilitating the organization and linking of light and flat frames. ```text $$TARGETNAME$$\$$DATEMINUS12$$\$$IMAGETYPE$$\$$FILTER$$\SESSION_$$TSSESSIONID$$\etc ``` -------------------------------- ### Assumptions for Target Scheduler Synchronization Source: https://tcpalmer.github.io/nina-scheduler/synchronization Successful synchronization assumes the primary goal is faster target completion, TS works without sync, all NINA instances are on the same PC, use different profiles, and TS projects/targets are defined under the server's profile. Equipment capabilities should be roughly equivalent, especially filter wheels. ```text Proper operation of synchronization for Target Scheduler will assume the following: * The primary goal of multiple OTAs/cameras on a single mount is to ‘gang up’ on the desired exposures for your targets and complete them faster. * You can successfully run TS without synchronization. * All NINA instances are running on the same Windows computer. * Each NINA instance will be using a different NINA profile designed to support synchronization. * The TS projects and targets you wish to image will be defined under the profile used by the server instance. * The capabilities of the equipment used by each setup (server and all clients) are roughly equivalent. This is most important for filter wheels (including filter naming) and somewhat less so for camera capabilities and focal lengths. ``` -------------------------------- ### Target Scheduler Synchronization Approach Source: https://tcpalmer.github.io/nina-scheduler/synchronization Target Scheduler (TS) takes a different approach to synchronized acquisition. The first NINA instance becomes the sync server, running a standard TS sequence. Subsequent instances become sync clients, communicating with the server for exposure details and instructions. All NINA instances must use different profiles, a NINA requirement. -------------------------------- ### Target Complete Message Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Details about the message published when a target plan is completed. ```APIDOC ## Target Complete Message ### Description This message is published by the TS planner when a target plan has all its exposures completed (100% complete). ### Method PUBLISH ### Topic TargetScheduler-TargetComplete ### Version 1 ### Content - **target name** (string) - The name of the completed target. ### Expiration none ### Headers - **ProjectName** (string) - The TS project name associated with the target. - **Coordinates** (NINA.Astrometry.Coordinates) - The astronomical coordinates of the target. - **Rotation** (double) - The target rotation angle as configured in the TS UI. ``` -------------------------------- ### Custom Synchronization Instructions in NINA Source: https://tcpalmer.github.io/nina-scheduler/synchronization Two key custom instructions are used for synchronization in NINA with Target Scheduler. '_Target Scheduler Sync Wait_' is used in both server and client sequences to ensure all instances are ready for the next action. '_Target Scheduler Sync Container_' is the client-side counterpart to '_Target Scheduler Container_', handling communication with the server for exposures. ```text The sequence instruction **_Target Scheduler Sync Wait_** can be used in either server or client sequences and serves to ‘sync up’ running instances to be sure all are ready for the next action. * The sequence instruction **_Target Scheduler Sync Container_** is the sync client counterpart to **_Target Scheduler Container_**. This instruction is used only in client sequences and handles communications with the server to poll for, accept, execute, and submit exposures. ``` -------------------------------- ### Calculate Client Exposures per Server Exposure Source: https://tcpalmer.github.io/nina-scheduler/synchronization This calculation determines how many shorter client exposures can be taken within the time of a single server exposure. It relies on the server exposure length and the client exposure length. ```pseudocode N = Truncate(server_length / client_length) ``` -------------------------------- ### Convert TS 4 Sequence Files to TS 5 with PowerShell Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/ts5-beta A PowerShell script to automatically update N.I.N.A. sequence files from Target Scheduler 4 to Target Scheduler 5. This script rewrites sequence files to use new TS 5 class names, preventing errors when loading older sequences. It requires specifying the input file and an output file name for the converted version. ```powershell sequenceToTS5.ps1 -file NAME.json -out NAME-TS5.json ``` -------------------------------- ### Synchronization Advantages and Challenges Source: https://tcpalmer.github.io/nina-scheduler/synchronization Direct communication between '_Target Scheduler Container_' and '_Target Scheduler Sync Container_' helps keep exposures in lock-step, potentially reducing wait times. However, clients may occasionally desynchronize due to actions like autofocus, but should be able to re-sync on subsequent exposures. ```text One advantage of this approach is that since **_Target Scheduler Container_** and **_Target Scheduler Sync Container_** directly communicate, it’s easier to keep exposures in lock-step on all instances, (hopefully) reducing wait times. However, clients may periodically get out of sync with the server (e.g. when an autofocus is triggered on the client) but they should be able to re-sync on later exposures, depending on the timing. ``` -------------------------------- ### TS Message Sender Details Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Details about the message sender identification used by the Target Scheduler plugin. ```APIDOC ## TS Message Sender Details TS messages are identified by the following properties: * **MessageSenderId**: `B4541BA9-7B07-4D71-B8E1-6C73D4933EA0` * **MessageSender**: `"Target Scheduler"` * **SentAt**: UTC Now (when message is composed/sent) * **CorrelationId**: TS is not currently using this message property. All messages sent from TS are logged in the TS log at compose/send time. ``` -------------------------------- ### Container Stopped Message Source: https://tcpalmer.github.io/nina-scheduler/adv-topics/pub-sub Details the message published when the TS Container instruction concludes. ```APIDOC ## Container Stopped When the TS Container instruction ends, a **_container stopped_** message is published. ### Topic `TargetScheduler-ContainerStopped` ### Version `1` ### Content * **(string)**: The literal string "Container Stopped". ### Expiration * `n/a` ### Headers * **StoppedAt** (DateTime): The time at which the container stopped. ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.