DMX Filters

ETB

New Member
First off, you guys seem to have a wonderful community here and I've enjoyed going over your posts. I'm new to a company dealing in large scale effects and working to learn as much as I can. Places like this make it much easier. I figured after lurking I would see if anyone could answer a question I can't seem to google my way out of.

DMX Filters

I know that DMX512 isn't rated for things like pyro because of the possibility of getting a false signal. Some of the equipment I'm reading up on uses a "DMX filter" to help prevent this. Can anyone explain how a filter would work? I understand what it's doing, just not how it's doing it.
 
The problem is that DMX by it's design nature has no error-check. It is simple one-way communication much like a megaphone. Because of this it is not suitable for motion/automation or Pyro work.
If a light flickers for a second, so be it, but if a prop moves at the wrong time or a squib goes off, people could get hurt.
 
Actually, DMX is used all the time for pyro, but there are external overrides. For example, all of the propane cues for a big rock show that is timecoded are probably getting triggered by the audio tracks, however the operator controls if that time-code is actually getting to his control desk, and then additionally has lockouts and e-stops, external to the DMX controller.
dmx
The timecode may say "go", but that does not do anything unless the tech has physically activated the particular system, that receives the DMX.
 
Hi,

you dont have to use dmx to synchronize pyro effects to time code. Nearly every professional firing system can be synchronized directly to timecode. This allows you to use a firing system that was build for this purpose to control the pyro. Firing systems always have an extensive error checking, and a lot of the newer ones use encryption to prevent other people from firing your effects.

For security reasons, most firing systems will only fire cues if they have revived several valid timecode frames in sequence, when in timecode mode. So, plan to have a timecode preroll.
 
I know that DMX512 isn't rated for things like pyro because of the possibility of getting a false signal. Some of the equipment I'm reading up on uses a "DMX filter" to help prevent this. Can anyone explain how a filter would work? I understand what it's doing, just not how it's doing it.

"DMX Filter" sounds like marketing speak to justify doing something that is clearly excluded from the DMX standard: control in safety critical applications. Some manufacturers justify using DMX by having separate "enable" and "fire" channels that must be set to specific values. The argument is that it's much less likely for a set of DMX addresses to go to this specific combination of levels due to random errors than just using a single "fire" channel. There may also be other software logic to ignore brief level changes and only fire if the right values are received for a certain number of DMX packets in a row.

All of that does prevent certain kinds of errors, but it doesn't really make things safe for the reasons mentioned above. There are cases where it can be okay to use DMX as a trigger, but there needs to be other safety equipment involved to prevent DMX errors from turning into serious injury or death.
 
"DMX Filter" sounds like marketing speak to justify doing something that is clearly excluded from the DMX standard: control in safety critical applications. Some manufacturers justify using DMX by having separate "enable" and "fire" channels that must be set to specific values. The argument is that it's much less likely for a set of DMX addresses to go to this specific combination of levels due to random errors than just using a single "fire" channel. There may also be other software logic to ignore brief level changes and only fire if the right values are received for a certain number of DMX packets in a row.

All of that does prevent certain kinds of errors, but it doesn't really make things safe for the reasons mentioned above. There are cases where it can be okay to use DMX as a trigger, but there needs to be other safety equipment involved to prevent DMX errors from turning into serious injury or death.


Thank you, this makes sense.
 
The argument is that it's much less likely for a set of DMX addresses to go to this specific combination of levels due to random errors than just using a single "fire" channel.

Exactly, but this will only prevent bit transmission errors. A manipulation error on the lighting console could fire the effect at any time. Therefor I absolutely agree that this isn't a safe practice. Dangerous effects are best controlled by their own control system, operated by a dedicated operator who has no other task than to guarantee the safety of the effect.
 
While I haven't looked into this sketchy territory; wouldn't it make sense to have a dead man enable switch (held by above mentioned operator) and then trigger via DMX?
 
While I haven't looked into this sketchy territory; wouldn't it make sense to have a dead man enable switch (held by above mentioned operator) and then trigger via DMX?

Absolutely in some cases. There are some effects where it runs on a predetermined schedule and the operator is there to make sure no one is in the area of effect.

Just to be clear I was looking for information on how a DMX filter works. I think we have a good working theory on what the manufacture what going for and that it's more industry lingo. If you're in a situation where you CAN'T have an unintended effect DMX isn't your answer. There's plenty of other options like optic cables but it is what it is.

It's interesting looking at this fresh. I come from a background in robotics where almost isn't acceptable. The more I see of any industry the more I understand that we're all trying to cobble solutions together.
 
"DMX Filter" could also be a marketing term for what is more commonly called a terminator. It functions kind of like a filter in that it prevents signal reflections. DMX is basically a more specific version of RS-485 and that specification talks about the need to terminate the end of the data chain.
 
The only other device I had heard of that "filters" is the DFD Decelerator: http://www.dfd.com/dmxdecel.html
The intent is to "clean up" a boarderline DMX signal and relax it's timing to get rid of numerous problems that may occur.

Calling it a "filter" is a bit of an understatement as it reprocesses and opto-isolates the DMX signal.
 
The only other device I had heard of that "filters" is the DFD Decelerator: http://www.dfd.com/dmxdecel.html
The intent is to "clean up" a boarderline DMX signal and relax it's timing to get rid of numerous problems that may occur.

Calling it a "filter" is a bit of an understatement as it reprocesses and opto-isolates the DMX signal.

OK, but none of the devices mentioned here turn DMX512 into a protocol that is reliable enough for applications with life-safety considerations.

DMX512 does not have an error checking or guaranteed delivery mechanism.

ST
 
OK, but none of the devices mentioned here turn DMX512 into a protocol that is reliable enough for applications with life-safety considerations.

DMX512 does not have an error checking or guaranteed delivery mechanism.

ST
Kind of what I said in post #2 above, fine for lighting but not appropriate for motion control or Pyro.
 
To clarify, sACN? or are those features only in the larger ACN suite?

While it would be nice, I don't think sACN has it. My knowledge of sACN is that it is just sending 0-255 values over UDP (UDP is fire and forget without implementing your own kind of acknowledge system)

Part of the appeal for UDP is that if a packet is lost, the system won't get jammed up because the next packet already has newer data than if you resent the old one again.

TCP is of course designed for getting data from point A to point B intact, at the cost of inherent delays from acknowledgement and resending packets.

This all being said, with UDP receiving devices will discard malformed packets, and any failing the checksum, so the device simply wouldn't operate for a frame or two until it was received.
On modern equipment, with proper cabling for your distance, you should practically never have to deal with dropped packets.

I was testing sACN to control 800 RGB LEDs @ 30 frames per second with a Python script I made through the Open Lighting Architecture, and using an old core 2 laptop, and an even older 10/100 switch with 100+ feet of cat-6, I lost no packets.

Wow that's a technical mouthful...

TL;DR, no inherent error correction with sACN, but any errors will be discarded by the receiving device, and await the next command to arrive milliseconds later.
 

Users who are viewing this thread

Back