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

MAESTRO — Automation Interface Protocol Technical Reference Manual 99
Sequential Transaction Queues Theory of Operation
tion commands and can be specified as the Transaction Queue in the
Maestro Automation commands to facilitate immediate execution of com-
mands with no regard for execution of other command messages. Transac-
tion Queues (200-254) are reserved for internal use (e.g. break down and
convert Legacy Commands such as Set Key, Set Mix etc. into Transaction
Queues so that they are processed correctly).
Any command messages
using Transactions Queues 200-254 will not be executed and an error
message will be generated.
Transaction Queues will be processed on a field basis. First, system events
will be processed to remove and report any completed or failed commands
from the queues. Then, the subsequent command in any pending queues
will be executed.
If a command in a Transaction Queue fails and no TransactionQueueBegin
command has been received for that queue, all subsequent commands
pending in that Transaction Queue will not be executed and will be
reported as failed.
If a command in a Transaction Queue fails and a TransactionQueueBegin
command has been received for that queue, all subsequent commands
pending in that Transaction Queue and any additional commands received
utilizing that transition queue will not be executed and will be reported as
failed until a TransactionQueueEnd command is encountered for that
Transaction Queue. It is recommended that TransactionQueueBegin and
TransactionQueueEnd commands be used by automation vendors to
demarcate a set of commands comprising a transaction as this prevents the
situation where: 1) a sequence of commands are in the process of being
communicated to be placed into a TransactionQueue, 2) A command in the
Transaction Queue fails, 3) All remaining pending commands in that queue
are marked as failed and removed from the transaction queue, and 4) Sub-
sequent commands in the transaction are received and acted upon as
though they are a new transaction. If one were to use TransactionQueue-
Begin and TransactionQueueEnd in this situation, if a failure occurred after
a TransactionQueueBegin had been encountered, all subsequent com-
mands either pending in the queue or received via the communication
channel would be marked as failed and not executed until a Transaction-
QueueEnd command for that Transaction Queue was encountered. It is rec-
ommended that unrelated or independent commands be placed in separate
transaction queues to prevent deletion of unrelated commands in the event
of failure.