How To | Tracking Redundant Core Usage From a 3rd Party Control System

Learn how to track redundant core usage from third-party control systems.

Updated at April 25th, 2024


There are three methods to track Redundant Core usage:

Using ECP

This is documented in our Help file:

A TCP/IP connection should be maintained with both Cores.

The status of each Core should be periodically polled using the Status Get command.

All other commands should be directed to the current "active" Core, as determined by the status polling.

Additionally, the DESIGN_ID values and IS_PRIMARY flags of the Cores should be checked to verify that they are indeed a primary/backup pair running the same design.

When polling Status Get, the following can be used to determine the Active Core:

Argument Data Type Description
DESIGN_NAME string The name with which the currently running design file was saved.
DESIGN_ID string A unique string generated every time a Design is deployed to a Core, or pair of Cores, or when the Design is emulated.
IS_PRIMARY unsigned integer Is a 1 if this is the primary Core of a redundant pair, or the design is not redundant, 0 otherwise
IS_ACTIVE unsigned integer Is a 1 if this is the active Core of a redundant pair or the design is not redundant, 0 if it is not active


Example:    sg "MyDesign" "NIEC2bxnVZ6a" 1 1


Using QRC

The StatusGet message is sent with the following responses:
Platform : The Q-SYS Core model.
State : One of the following strings – "Idle", "Active", "Standby".
DesignName : Name of the currently running design.
DesignCode : GUID of the currently running design.
IsRedundant : True if the design is configured to be a redundant design.
IsEmulator : True if the design is currently running in the emulator.