Basketball drop in HS Musical

If you ever need to pull a solenoid, flip a relay, or spin a small motor via DMX control, all our wireless dimmers do this stuff very easily. https://theatrewireless.com/

Safety concerns are real, of course -- DMX is not intended or rated for applications that could pose a risk to people or property. That said, the primary cause of DMX problems is channel-shift. If you use channel 512 to enable a mechanical system, and then other channels for the various different thing you need to control, you end up quite safe. This is because channel shift always ends up shortening the data packet, so chan 512 is always lost. Even a shift of a single channel means there is no chan 512 and the system cannot be armed.

This comment is for educational discussion only, I do not endorse this method or guarantee that it will be failsafe. Never control pyro or anything potentially dangerous with DMX.

Jim
RC4
 
In addition to channel shift, a danger of using DMX to control this kind of stuff is operator error; someone flipping through channels during light check (ask me about sweeping 9 tons of confetti 5 minutes to house open) or typing 1-512 @ full or whatever. Not to mention accidentally triggering it during programming or rehearsal. Including a physical deadman (like a normally open button supplying power to the device) would make me feel OK about using DMX for non-dangerous effects.
 
We controlled these soccer ball launchers with DMX via an LED tape dimmer on their control circuit. No real danger. (We also controlled a signal light and buzzer on each goal to indicate to the player which to aim for.)
To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.
 
In addition to channel shift, a danger of using DMX to control this kind of stuff is operator error; someone flipping through channels during light check (ask me about sweeping 9 tons of confetti 5 minutes to house open) or typing 1-512 @ full or whatever. Not to mention accidentally triggering it during programming or rehearsal. Including a physical deadman (like a normally open button supplying power to the device) would make me feel OK about using DMX for non-dangerous effects.

100% AGREE!
 
There are also the optional DMX512 System Information Packets that can be used to add a checksum to the DMX512 data stream and make it a good bit more robust against data errors. I don't know that many systems either generate or pay attention to these packets, however. For something like a ball drop or confetti cannon or other thing where unwanted activation could cause trouble I'd think it would be well worth employing them if possible.

If one were coding the controller gizmo for the effect oneself, it would also seem reasonable to have some sort of logic requiring a succession of a few packets with the same value before accepting it as a trigger. This does cause additional latency, but I'd think often it could be accommodated without trouble. Four or five successive packets would mean very roughly a tenth of a second delay, and be quite good at guarding against transient errors.

In any case, I would not suggest using DMX512 for anything that is safety-critical. To my mind a basketball drop is probably on the edge of okay, in some circumstances; but if it were a bowling ball drop, no thanks!
 
There are also the optional DMX512 System Information Packets that can be used to add a checksum to the DMX512 data stream

I'm not aware of this being part of the DMX standard. If I've missed something, can you direct me to where it's documented? If you're referring to RDM packets, they generally are not used for triggering real-time events, though it could certainly be done. Are there any examples of systems doing this?

I've done quite a few custom DMX data projects where I designed both the sender and the receiver, so I have the option of putting a checksum somewhere, or requiring a specific sequence of values to occur within a very defined timeframe in order to cause something to happen. In these cases we are using the DMX packet as a very basic transport and then packing more sophistication into the data itself. But it's not part of a standard, it becomes a unique system that is compatible only with itself. All good, of course, if it gets the job done with the level of security required.
 
Apparently the System Information Packets (SIPs) were added in the 2004 DMX-512 A revision, and are in the corresponding ESTA/ANSI specification. https://tsp.esta.org/tsp/documents/docs/ANSI-ESTA_E1-11_2008R2018.pdf is the current revision of it and has the information in annex D4, pages 32 through 35. Unfortunately the actual checksum algorithm is somewhat poorly documented for my taste (being described merely as the "sixteen bit one's complement additive checksum"). If the link doesn't work directly, you can navigate through the ETSA website manually to get there, after a simple, free sign-up.

(If I had my druthers, I'd have used a CRC checksum rather than an additive one.)
 

Users who are viewing this thread

Back