Grass Valley Maestro Master Control Reference Manual v.2.4.0 - Manual (Page 174)

174 MAESTRO — Automation Interface Protocol Technical Reference Manual
Section 6 — Examples
Typical Pitfalls
Source selection latency and subsequent modifications to that source
A common error among automation vendors is to assume instantaneous and sequential completion by Maestro of all auto-
mation commands. As a result, a command which selects a bus source will be immediately followed by commands to
modify that new bus source. One example of this would be to issue a TAKE_XPT and immediately, or even within the
same BEGIN-END construct, issue a command such as LRS-PST to modify the new source. In this case, where the auto-
mation system attempts to modify the source selected in TAKE_XPT without first verifying its presence on the desired
bus, it is likely that the specified modifications will be applied to the current source and not the source specified in the
TAKE_XPT command. A worse situation would be the immediate issuance of a TX_TRIG after a TAKE_XPT potentially
resulting in the wrong source “On Air”. One reason for this is due to the fact that Maestro may be relying upon an external
router to perform source switching and will only apply modifications to the selected source upon switch confirmation.
Another example is an automation system issuing a TX_TRIG and then immediately following it with commands modify-
ing the PST bus. Unless the automation system has verified that the transition is complete via TX_STAT messages, modi-
fications may unexpectedly appear on the PGM bus. If the automation vendor uses a query approach to determine if
TX_TRIG is complete, as opposed to the superior automatic update solution, they must resolve the problem of an imme-
diate “quiescent” TX_STAT reply meaning the transition hasn't started or the transition is complete (especially difficult in
the case of Cut). In the past, some attempts have been made to estimate the latency between receiving a source selection
command and when that source is available for modification. Due to the fact that every installation may be unique in its
configuration and external hardware setup, the following statements are made to supersede all previous estimates:
The latency of command execution at every installation is potentially unique due to such influ-
ences as hardware and software configuration, dependencies upon external hardware (possibly
3rd party), system load, etc. Due to this uniqueness, it is imperative that the automation vendor
NOT assume a fixed period of time between a command being issued and its completion. The
ideal solution to this problem is to use Maestro automatic updates of relevant commands.
Another, less than ideal, solution is to query relevant commands to determine when an issued
command has completed (must deal with aforementioned “quiescent” TX_STAT pitfall).
In conclusion, commands do not complete instantaneously and may not even complete sequentially in a multi-threaded
real-time environment such as Maestro.
Incorrect association of reply with query
Another common error when interfacing with Maestro is the incorrect association of a response from Maestro with the
wrong query. An example of this, and its result, is shown below:
Automation: BRK 82 80 02 06 7f 02 01 01 00 00 77 Set TAKE_XPT PST -> 01
Maestro: 04 ACK
Automation: 02 02 A1 04 59 Set LRS_PST -> Stereo
Maestro: 04 ACK
Automation: 02 02 4C 01 B1 Set VID_MODE -> Cut
Maestro: 04 ACK
Automation: 02 03 91 01 06 65 Set PROLL -> 1.6 seconds
Maestro: 04 ACK
Automation: 02 0E E0 07 09 80 05 00 00 02 00 00 00 00 00 00 7B Set SET_MIX -> . . .
Maestro: 04 ACK
Automation: 02 02 44 80 3A TX_TRIG (with preroll)
Maestro: 04 ACK
Automation: 02 02 22 45 97 (a) Query TX_STAT