How To | Tracking Redundant Core Usage From a 3rd Party Control System
Learn how to track redundant core usage from third-party control systems.
If you are not finding the results you need and still have questions, submit a request using the form below and our Tech Docs team will get right on it. Our goal is to provide the content you need!
Your engagement helps us create the content you need. Click here to review this article.
Table of Contents
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:
|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|
Syntax: sr DESIGN_NAME DESIGN_ID IS_PRIMARY IS_ACTIVE
Example: sr "MyDesign" "NIEC2bxnVZ6a" 1 1
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.