I would readily agree with the comment above that rigging/flying involves serious
safety concerns and should not be undertaken lightly.
I would also agree with the statements that
DMX is a terrible native format for
safety related control. Frankly, I've always thought that the complete lack of error checking makes it pretty lame for lighting, but after two decades, that is a debate I am willing to let go...
Still, a fair amount of 'unsuitable' equipment (
pyro, flame jets, lasers, moving staging/rigging) are regularly controlled via
DMX. And it is probably worth examining how it is done with reasonable
safety - if, for no other reason, folks do not try to come up with simple
DMX solutions.
First, it is important to understand when you are looking at, say, terrifying propane jets at a huge concert, the
DMX control is not 'direct'. That is, it typically isn't a simple DMX->
relay board. Typically, the
pyro, flames, lasers,
etc. have a controller of their own.
DMX is used to 'trigger' one
system from another. The dedicated control
system often supports specific
safety interlocks and additional operator over rides. This can be fairly involved, for example one setup I can think of involved pressure mats to account for everyone on
stage. Another had an operator arm specific charge groups. That is,
DMX provided the precise timing of the fires, but a human armed the effects just moments before while visually inspecting clearance.
Second, for anything remotely life threatening,
DMX is seldom used in a
conventional channel->value->result fashion. The standard is typically enhanced in two ways. First,
DMX one (often two) channels used by the
safety system are typically repurposed for error checking. Take one I can think of off the top of my head. It uses 4
DMX channels to set off fire jets. Instead of a
conventional DMX channel/
fixture map, you get:
Toggle
Charge
Action
CRC
It actually resembles
conventional DMX usage very little. It is more like it is borrowing 5 bytes of bandwidth on the RS-485 connection to implement a control
protocol. The 'Charge' and 'Action' are close to what you might expect. Pick a 'charge' (0-255) and tell it to take an 'Action' (prep=001, arm=122, or fire=165).
However, you would be hard pressed to work the two channels with a simple
DMX board. The prep, arm, and fire values must come in order, and no other values must be received (any value other that 1, 122, or 165 tells the
system to look for 'arm' again). Similiarly, the 'charge value' cannot change during the sequence, otherwise the controller again goes back to idle.
If the thing being controlled were scary, but safe (ex. big fire blast, but never near anyone), this scheme alone is pretty good (sequence in time). However, in this case, a higher
level of error protection was required, so two additional mechanisms are present. The '
toggle' an 8
bit counter. The bottom 2 bits must to match the 'action', and count in order (idle, prep, arm, fire means a count of 00, 01, 10, 11). The top 6 bits count 'command cycles'. Mathmatically, this does not improve the error checking that much, but it does make the messages longer, and more unique, which helps with the other form of error checking - the last byte is a CRC, based on the first 3.
Again, any error, packet count, action to count modula, CRC error, resets the state engine and alerts the
effect operator.
The above is just one example, but it shows the sort of solutions that get used. In this case, you can use a the
cue stack in a memory board to 'run' the
system (using a little tool to calculate the CRC and
toggle values). However,
bit errors, programming errors, or just breaking
cue order all have a mathmatically very high probability of stopping the jets and alerting the
safety operator.
Again, my
point isn't to encourage people to use
DMX for
safety related control. My
point is just the opposite. When
DMX has been safely used for this sort of thing, a lot of work and extra precautions normally go into it.
-jjf