DMX should not be used for pyro/laser

[zonino]

We've got some laser and pyro users who specifically use a small number of channels at the beginning of a universe to achieve this.

 

I would really hope you DON'T have any pyro users using that product!

[jfitzpat]

I would really hope you DON'T have any pyro users using that product!

 

Multiple, with literally thousands of shows run so far without incident. With fireworks, propane, etc. you can't (or at least shouldn't) do a simple 1:1 channel map. Most do arming and sequences.

 

JJF: If you update the date at 40Hz why do you send it out the interface any faster? I know its legal, but the world is full of broken DMX receivers that seem to have problems if the gap between breaks is significantly shorter than "normal", normal being the 44Hz rate...? Where does the benefit accrue?

 

If data update and packet generation are asyncronous (as with many (most?) consoles, and somewhat inherent in USB adapters), smaller packets sent more often lowers the amount of variation in latency. New data can't be sent until the last packet has been transmitted.

 

Also, DMX has no error checking. So, if the packet rate is artificially low any bit errors will be 'on display' for longer.

 

-jjf

[Nick S]

Multiple, with literally thousands of shows run so far without incident. With fireworks, propane, etc. you can't (or at least shouldn't) do a simple 1:1 channel map. Most do arming and sequences.

 

And with DMX you can't use it for triggering pyrotechnics.

 

Also, DMX has no error checking. So, if the packet rate is artificially low any bit errors will be 'on display' for longer.

 

...and now you've answered precisely why.

 

It doesn't even matter if you don't do a simply one to one channel map, you simply can't use DMX for any sort of pyrotechnics. The revised USITT DMX-512 ANSI specification specifically states that "DMX512 is not an appropriate control protocol for hazardous applications." If you wanted it any more clearer, direct from their website: " DMX512 and DMX512/1990, with their lack of error detection, is NOT appropriate for some applications - such as pyrotechnic control and scenery automation". Using DMX potentially invalidates your insurance in case of a dangerous mis-fire, even if it wasn't the protocol's fault. Even with safety features you describe, it still doesn't stopit being a bad idea all round.

 

If you do a quick search of the board, you'll see several detailed topics explaining just why pyro control via DMX is not a viable solution.

[jfitzpat]

And with DMX you can't use it for triggering pyrotechnics.

 

I think you mean to say "shouldn't". That is at least open for discussion. "[C]an't" is already disproved.

 

The revised USITT DMX-512 ANSI specification specifically states that "DMX512 is not an appropriate control protocol for hazardous applications."

 

Some would argue that DMX-512 is not an appropriate control protocol for conventional or moving lights. Certainly most manufacturers assumed it wasn't early on... :)

 

Seriously, there are really only two important issues. Legality and safety. If something is illegal in a certain local, then it should not be used. Period.

 

However, if your concern is safety you have to step back. Many, many pyrotechnical performances are fired via longitudinal timecode with only a rudimentary interlock system. Simple 80 bit timecode has almost no frame validation and, as an analog signal is, itself, very noise prone.

 

DMX is, at it's core, an RS-485 link. Current loop and digital. Now, let's take a simplified look at a real theme park retrofit. Instead of tape being directly decoded, tape drives our controller and 15 DMX channels are used. Basically there is a 1 byte command, a 12 byte firing code, and a 2 byte (16 bit CRC) all sent as DMX channels. The controller sends an arm code to the pyro box 5 seconds before the actual fire. Then a fire code is sent at the cue time. The fire code, despite a 16 bit CRC, will not work unless the arm code (also CRC protected) was received 4.5 to 5.5 seconds previously. The arm code also is displayed to the pyro safety operator on a simple display next to a big red abort button. In theory, false triggers are a couple hundred thousand times less likely to occur than the original system. In practice, we still don't know. Misfires went from a couple weekly to none in a 14 month period. On the flip side, syncronization was improved. This coupled with no more misfires means better looking shows.

 

Should a person take DMX, drive a DMX relay board, and fire pyro? I say no, though at least one big tour has used a cascade of relay boards to create a traditional arm/fire/safety setup for flame effects. But with less firmware and intelligence than a typical moving fixture it is possible to build a very robust and reliable DMX to pyro interface that outperforms tape and most other traditional pyro show control technologies. And, provided it can regurgitate channel values at precise times, no real changes are required on the DMX controller side.

 

-jjf

[mark_s]

If you do a quick search of the board, you'll see several detailed topics explaining just why pyro control via DMX is not a viable solution.

 

...such as here

[ampcats]

Note from the moderators : this member has deleted/edited several of his posts in a fit of pique. Apologies if it makes the thread harder to follow - we've reinstated what we can, but the newer ones hadn't been cached so there's nothing we can do about them.

[jfitzpat]

from the horses mouth - emphasis mine

 

Sorry, being an old timer you'd think I'd like blind deference to authority. After all, it would be much easier to write, "well, the first time I wrote firmware for a fireworks control system at a major theme park 22 years ago..." than to spell out technicalities. But once an engineer...

 

Anyone taken a look at the power supply and manufacturer safety notes on a modern short arc lamp setup? Words like "explosion" and "poison" crop up. Yet, *gasp*, lamp cooling can be controlled via DMX on some fixtures (ex. fan control). Some fixtures even let you overpump the lamp via DMX (ex. 'lamp assisted lighting effect'). How can this be? The USITT has spoken! You can't control something as dangerous as these lamps with a moronic one way protocol with no error detection...

 

Not convinced? How about a micro yag laser system from China? Now were talking about something so inherently dangerous that it is under a special regulatory body in the US (CDRH) and additional regulations in some US states (ex. New York). And, we are often combining it with shoddy manufacturing and improper UV protection. Next, we put it in the hands of part time DJ and control it via DMX...

 

The key in both these cases is that consoles are not directly controlling the devices on a low level via DMX. They can't, DMX isn't even very good at its original design objective (replacing DC control signals from boards to dimmers). Everything from refresh rate to lack of error detection conspires against it for something as complex as directly manipulating, say, the lamp system and stepper motors in a modern moving fixture. DMX, instead, is used as 'high level' protocol which is translated by a fairly sophisticated controller at the device end. The high error probability and typically modest refresh rate of DMX has to be handled by this controller, including any safety implications.

 

Of course, there is a certain funny irony is this discussion. I was, in fact, one of the people criticising the original spec for not including rudimentary error checking when it was proposed. Now, the 'same' folks are using my own arguments as 'proof' in another debate. From my point of view it feels like a 'not-thinking 2, thinking 0' type situation. Sort of the same way I've felt during the last two Presidential election cycles here in the US... :)

 

-jjf

[Tomo]

I really shouldn't but...

Anyone taken a look at the power supply and manufacturer safety notes on a modern short arc lamp setup? Words like "explosion" and "poison" crop up. Yet, *gasp*, lamp cooling can be controlled via DMX on some fixtures (ex. fan control). Some fixtures even let you overpump the lamp via DMX (ex. 'lamp assisted lighting effect'). How can this be? The USITT has spoken! You can't control something as dangerous as these lamps with a moronic one way protocol with no error detection...

The lamphouse is designed to contain the bits in the event of catastrophic lamp failure, and there are internal sensor overrides as you imply.

 

How about a micro yag laser system from China?

Personally, I don't think lasers should be DMX controlled - it's Chinese, so what do you expect?

 

DMX, instead, is used as 'high level' protocol which is translated by a fairly sophisticated controller at the device end. The high error probability and typically modest refresh rate of DMX has to be handled by this controller, including any safety implications.

And how you do intend to apply this safety to pyro?

The unit itself cannot detect if someone or something is too close to the pyro, or the myriad of other issues that might crop up - you need an actual person for that.

 

I was, in fact, one of the people criticising the original spec for not including rudimentary error checking when it was proposed.

I think that the argument against it was the expense of processing back then! DMX-512A is an extremely simple protocol to implement, as all the receiver has to be able to do is count the packets.

Error checking needs much more - it's dirt cheap now, but even in 1990 suitable ICs were fairly expensive.

 

Since then, backward compatibility has been more important - hence RDM.

[dbuckley]

Personally, I don't think lasers should be DMX controlled - it's Chinese, so what do you expect?

 

Oi! Want to control your laser via DMX512? The look no further than http://www.jpk.co.nz, a good Kiwi company making DMX512 interfaces expressly designed for the laser industry.

[jfitzpat]

The lamphouse is designed to contain the bits in the event of catastrophic lamp failure, and there are internal sensor overrides as you imply.

 

Yes, that was my point.

 

Personally, I don't think lasers should be DMX controlled - it's Chinese, so what do you expect?

 

Better check out alt.lasers or ILDA (industry trade group). The Stadium gigs are controlled that way too. Of course, the laser industry always makes the point that safety perceptions like yours are, in their opinion, wrong. Morons have started big fires with PAR cans, most annecdotal tales of injuries from the laser entertainment industry are false.

 

And how you do intend to apply this safety to pyro?

 

See above. I've done it. DMX is used as a replacement for a common industry pre-programmed firing technique and this result is dramatically improved safety and reliability.

 

I think that the argument against it was the expense of processing back then! DMX-512A is an extremely simple protocol to implement, as all the receiver has to be able to do is count the packets.

Error checking needs much more - it's dirt cheap now, but even in 1990 suitable ICs were fairly expensive.

 

Yes, that was the argument, but repeating it does not make it any less false. Well before 1990, some popular UARTs (like the Z80 SIO) already had very sophisticated error checking (CRC) built in. For reasons no one every really explained, the argument centered around non-UART implementations. Even then the argument was pointless. Someone (I think it might have been Dick from Avolites) made the point that a 16V8 GAL was already down to $1 in single piece pricing and posted a nifty checksum JEDEC file and design for all to use should they be too scared of UARTs or microcontrollers. The response was that a programmable part would require an investment ($49 for a programmer) and would be "too scary" for non digital savvy engineers to implement. I did a discrete design which added a checksum to the shift register solution being argued about that cost a whopping $0.40 in Digikey pricing (the catalog was a lot smaller than an urban phone book back then). Always the one to outdo, Doug Mobley did a fantastically clever error checking scheme for $0.15, and provided the error tolerance proof to back it up. In the end, it all seemed to hinge on the idea that some unidentified segment of the manufacturing community was already 'adverse' to digital electronics and anything as complicated as a checksum or a CRC would scare them away.

 

Ironically, almost no discrete implementations ever existed. Even then, a complete 8051 family solution clocked in at about $15 in BOM. And a microcontroller was just a heck of a lot easier way to do it than building a UART from discretes (find the bit clock, find the breaks, shift out the bits...) And yes, even back in the dark ages of the 80s, all the microcontrolers had an 'add'....

 

Hmmmm. Repeating something that isn't true until everyone accepts it as fact. Does that remind me of US politics as well?

 

-jjf

[dbrateris]

I understand the concerns voiced in this thread, but I am wondering why DMX being used in professional products such as this: MagicFX

 

These were use on the TSO tour this year.

If using DMX is so dangerous when used properly, why is it being used on professional tours and in professional products?

 

Thanks

[david.elsbury]

I understand the concerns voiced in this thread, but I am wondering why DMX being used in professional products such as this: MagicFX

 

These were use on the TSO tour this year.

If using DMX is so dangerous when used properly, why is it being used on professional tours and in professional products?

 

Thanks

 

To quote from the website: " For safety reasons the Flamaniac is equipped with a DMX safety channel which needs to be opened between 40-60%."

 

I'd say it comes down to your risk assessment. Considering that the chance of a DMX fault resulting in the 'safety channel' being between 40 and 60% AND the actual 'fire' channel being up are less likely than a glitch on a single channel... then depending on where the actual units are, I'd be prepared to think about considering this risk acceptable... if it's on the stage with performers nearby, it's clearly a higher risk than in a more remote location...

 

Your milage may vary however!

 

David

[dbrateris]

Thanks for the reply. I am actually an electrical engineer and I understand the electrical issues associated with DMX. To me it just seems bizarre that I see so many people protest DMX for pyro but then I see numerous professional products using it.

 

I just don't understand why DMX is such a problem for people, especially when you have a pyro operator, an arming key, an estop, a deadman switch, and onstage indication that the effects are armed. To me, that seems like plenty of levels of safety. And despite the lack of error checking in DMX,a level of safety can be added by requiring multi channel sequences and codes to fire the effect that are extraordinarily unlikely to occur. It just seems like there are enough failsafes with a setup like that.

 

Thoughts?

[Brian]

...especially when you have a pyro operator, an arming key, an estop, a deadman switch, and onstage indication that the effects are armed...Thoughts?

And how many situations really have all of those?

[adam2]

In general I do not believe that DMX should be used to control Pyro or other potentialy hazardous effects, for the reasons already given.

 

A possible exception would be when pyro has to be accuratly fired in conjunction with other effects, or if large numbers of pyros must be fired in in an accuratly controlled sequence. In such circumstances of course a suitably experienced operator should be placed were they have a good view, and the remote DMX controlled firing should only be enabled when this operator holds down a suitable "dead mans control" This keeps "fire or not to fire" control in suitably experienced human hands, but gives the DMX signal control over exact timing.

 

Another, rare, exception is when the pyros are at such a distance from the crowd or talent, that an accidental or premature firing will cause no danger. This is likely to apply only outdoors, and is more applicable to filming than to theatre.