Control/Dimming ACN/RDM

punktech

Active Member
i was just wondering what everyone here thought of these two new acronyms. i'm pretty excited, personally. i think they'll make like a lot easier. no more hanging in horrible positions to address oddly hung DMX devices!
 
It is very exciting but as I sort of ranted about a little too much 6 months ago don't get too excited just yet. It may be quite a while before it becomes a reality. These things take a long time for the industry to adopt and implement. The ability to do this has been there quite a while (Two of those five DMX lines just sitting waiting for someone to use them). Clearly there is a matter of market forces being read to pay for it and control consoles being ready to make use of it. Well we are slowly getting there and everyone wants to brag that their latest gear is ACN/RDM "READY" or "Compatible". However as we learned with P.C.'s being "Vista Ready"... that may not mean much.

So yeah it's cool... but I think we are going to have LED Source4's before RDM is something that is a full reality... so don't hold your breath.
 
RDM seems like a sensible, incremental improvement that fits reasonably well in existing wiring and infrastructure.

ACN seems like a huge, rather vague, pipedream that seeks to solve a problem that I am not 100% sure even exists (I haven't lost much sleep over, say, multi-controller, multi target infrastructure).

Just my opinion.
-jjf
 
The thing I'm looking forward to the most with ACN is that it will consolidate the numerous E-DMX protocols out there into one (ala DMX in the 1980's). We're not looking at DMX being replaced, just the backbone really.
 
Except perhaps for large moving light fixtures which can sometimes use 20 or more DMX channels. That starts to eat away at the available DMX channels on your universe rather quickly. ACN is likely to be a boon to people who have to work in situations with many of these fixtures.
 
RDM does not use the other two wires in the 5 pin dmx line. It sends packets at the start of the dmx stream over the same wires that DMX uses.
 
I think something needs to come into play soon. Using 4 DMX universes to control just 8 DL2's is a little rediculous. I think DMX needs to eventually have error correction. It would really help solve glitches every now and then.
 
The frustrating thing is that standard computer networking gear has had all the technology needed to solve all these problems for years. There's no reason you shouldn't be able to plug a dozen DL2's in via ethernet cable, have the network identify them, and then just use them without the constraints of DMX universes.

The technology is all there... and it's not even expensive anymore. It's just a matter of getting the manufacturers to sit down and agree on standards and start building to those standards... which again will take years.
 
If I didn't make it clear above, the standards are two very different things.

RDM (Remote Device Management) is an attempt to standardize something that High End has already demonstrated. Namely, using the bi-directional capability of RS-485 to remotely obtain information about a DMX and configure it.

There is no new wiring or pairs. The standard outbound pair is used to send a non-valid DMX packet which is recognized as a discovery sequence. The controller then turns the RS-485 line around and listens while devices broadcast.

No new wiring, no significant cost of goods (you need to control the previously strapped T/R lines on your tranceiver and add a resistor bridge for proper termination), and some nice benefits - remote error check, addressing, etc.

Like I said, a nice incremental improvement.

ACN (Architecture for Control Networks) is an attempt to create a master controller of diverse sub control systems - all in the form of a TCP/IP protocol. I think it has three problems facing it.

First and foremost, it is a suprisingly high level standard. Once you start getting to high level, universal show control, there are a *lot* of design decisions, institutionalizing one path out of many makes wide adoption a more uphill battle. I thought it was very telling that RDM, which is a fairly incremental improvement to DMX-512 was initially a pretty tough fit for ACN. To me, that does not bode well for the standards ability to grow and adapt.

Second, when you examine it in a decision tree, the protocol is surprisingly complicated. So much so that most folks still assume that ACN will not widely replace the DMX-512 connector on fixtures, but be a "backbone" between smart nodes, with DMX-512A convertors to get to to actual lights. The worry is that ACN is too complicated to be targetted on simple fixtures.

Third, it is not clear to me what major problems that ACN solves when we have a very simple standard, like ArtNet (which already has provisions for RDM) now. Off the shelf 100BaseT NIC adapters easily support 24 universes at high update rates (above 25 Hz or so, more than 24 universes starts causing packet order reversals on some NIC chipsets, which most simple ArtNet receivers do not handle). Native ArtNet support continues to grow (I use ArtNet now to talk to two Media servers), and the standard is open. Sure, it is pretty lame, but it is simple, and ArtNet<>DMX512 adapters are becoming more and more plentiful and affordable.

I am not saying ArtNet and ACN are the same - they are not. ArtNet looks to address a specific problem - DMX wiring being a costly pain, and does so with simple existing LAN technology. ACN can be used to address the same problem, but comes with the complexity of a master control system. I could be wrong, but in my experience simple standards, even fairly lame ones like MIDI and DMX-512 often 'win'.

-jjf
 
If I didn't make it clear above, the standards are two very different things.
RDM (Remote Device Management) is an attempt to standardize something that High End has already demonstrated. Namely, using the bi-directional capability of RS-485 to remotely obtain information about a DMX and configure it.
There is no new wiring or pairs. The standard outbound pair is used to send a non-valid DMX packet which is recognized as a discovery sequence. The controller then turns the RS-485 line around and listens while devices broadcast.
No new wiring, no significant cost of goods (you need to control the previously strapped T/R lines on your tranceiver and add a resistor bridge for proper termination), and some nice benefits - remote error check, addressing, etc.
Like I said, a nice incremental improvement.
ACN (Architecture for Control Networks) is an attempt to create a master controller of diverse sub control systems - all in the form of a TCP/IP protocol. I think it has three problems facing it.
First and foremost, it is a suprisingly high level standard. Once you start getting to high level, universal show control, there are a *lot* of design decisions, institutionalizing one path out of many makes wide adoption a more uphill battle. I thought it was very telling that RDM, which is a fairly incremental improvement to DMX-512 was initially a pretty tough fit for ACN. To me, that does not bode well for the standards ability to grow and adapt.
Second, when you examine it in a decision tree, the protocol is surprisingly complicated. So much so that most folks still assume that ACN will not widely replace the DMX-512 connector on fixtures, but be a "backbone" between smart nodes, with DMX-512A convertors to get to to actual lights. The worry is that ACN is too complicated to be targetted on simple fixtures.
Third, it is not clear to me what major problems that ACN solves when we have a very simple standard, like ArtNet (which already has provisions for RDM) now. Off the shelf 100BaseT NIC adapters easily support 24 universes at high update rates (above 25 Hz or so, more than 24 universes starts causing packet order reversals on some NIC chipsets, which most simple ArtNet receivers do not handle). Native ArtNet support continues to grow (I use ArtNet now to talk to two Media servers), and the standard is open. Sure, it is pretty lame, but it is simple, and ArtNet<>DMX512 adapters are becoming more and more plentiful and affordable.
I am not saying ArtNet and ACN are the same - they are not. ArtNet looks to address a specific problem - DMX wiring being a costly pain, and does so with simple existing LAN technology. ACN can be used to address the same problem, but comes with the complexity of a master control system. I could be wrong, but in my experience simple standards, even fairly lame ones like MIDI and DMX-512 often 'win'.
-jjf

This was very informative and well written. I think the issue with ArtNet is that it's a propriatary protocal, where as ACN is not, thus there's no potential *cost* for using ACN, as there might be with companies adopting, and then having to pay for continual usage of the ArtNet protocal. That's the general idea behind ACN, though I suspect you are correct in that, by being an all-things-for-everyone protocal, it's way too complex and doesn't readily solve a simple problem without a lot of effort by a lot of companies, namely how to get all those assorted consoles and appliance to be smarter in their interaction.

Big question is, why hasn't RDM taken off ?. Possibly as everyone is waiting for the next thing - ACN ?, with nobody wanting to commit to something simple, yet useful such as RDM, and then getting hammered on a bid for not being "ACN Ready".

SB
 
s
Big question is, why hasn't RDM taken off ?. Possibly as everyone is waiting for the next thing - ACN ?, with nobody wanting to commit to something simple, yet useful such as RDM, and then getting hammered on a bid for not being "ACN Ready".
SB

My personal feeling is that ACN is nice and all, but the required gear updates that will have to be made are too big to implement it right now. I think this whole ACN/RDM thing will end up panning out, but its going to take some time. The question always is, who does it first, the console or the fixtures/dimmers. The next step after that is making sure all the opto's and other DMX gear will pass the info on. Its a big step, when it all happens I think we will be much better off, but I would say in the next ten years times are going to be interesting. Personally, I just want to plug 100baseT Ethernet into everything and call it a day.
 
This was very informative and well written. I think the issue with ArtNet is that it's a propriatary protocal, where as ACN is not, thus there's no potential *cost* for using ACN, as there might be with companies adopting, and then having to pay for continual usage of the ArtNet protocal.

FWIW, Artistic License placed ArtNet in the public domain without restriction or royalty. There is a downside that the protocol document is maintained by a private entity, but that could be rectified. It is actually getting pretty widely adopted. We'll output it, and a lot of visualizers, media servers, etc. take it directly.

RDM is kind of in stealth growth. Our controller hardware has supported it for about a year, and I know that a lot of other controller manufacturers are in a similiar situation. I just bought a splitter that supports it, so the bottleneck is the fixture makers.

-jjf
 
The frustrating thing is that standard computer networking gear has had all the technology needed to solve all these problems for years. There's no reason you shouldn't be able to plug a dozen DL2's in via ethernet cable, have the network identify them, and then just use them without the constraints of DMX universes.
The technology is all there... and it's not even expensive anymore. It's just a matter of getting the manufacturers to sit down and agree on standards and start building to those standards... which again will take years.

The real reason that you can't just plug in a dozen DL2's via ethernet cable is cable topology. Ethernet cannot be run in a daisy chain fashion ala DMX, each leg has to return to an active switch (or bridge, or hub, or router, etc). Can you imagine for a rig of 50+ movers having to have 50+ home runs to a central location? One solution would be to put an ethernet switch in each fixture, but it would have to be active, so if one fixture loses power, then each fixture in the chain afterwards goes AWOL.

The answer, I believe, is fairly simple. Use ethernet (Net2, ShowNet, ArtNet) as your backbone and convert via DMX node at a convenient point and run DMX from node to fixture in the same way we've done for 20+ years. As is stated above, the great thing about ACN, if I understand correctly, is that it will serve to standardize the ethernet backbone, and do so w/out proprietary constraints.

-Chris
 
That's not an entirely true statement about Ethernet. In fact, long before Ethernet used CAT5 cabling and home runs it was a daisy chain "bus" topology. It would not be difficult to use Ethernet in that way and put a (very inexpensive, much less than and more flexible than an Ethernet to DMX converter) media converter on the end of the chain. There are also ways to do Ethernet in a daisy chain topology with standard CAT5 cable and then convert it at the end of the chain to regular 100Base-T. Still I wonder why you would do any of this. Switches are so inexpensive these days it makes as much sense just to put an Ethernet switch on the end of every pipe or line of truss and do home runs from there to each fixture with one coming back down to a central switch.

There are a few problems with the converter based scenario you mention. First, you're still limited to the number of fixtures you can have coming off of each box when fixtures can take up tons of addresses. Second, the converter boxes are expensive, a lot more expensive than Ethernet switches. Third, the addressing is a nightmare! Each converter is its own universe (or more than one universe in some cases) and so your console has to be more complicated to know which one of possibly hundreds of converter boxes to send the signal and then which channel to send it to. It sounds like a patched up solution to me.

Why set your sights low when running Ethernet direct to each fixture can solve all of these problems and more? Ethernet is inherently a more flexible technology than DMX. If you plug each fixture into an Ethernet network and use TCP/IP you can have them auto addresses by a DHCP server and then do all the fixture configuration by computer assigning a "fixture number" and so on so that you don't need to refer to it by IP address. There are lots of other cool things you could do such as easy two way communication with fixtures which could alert you to bulb hour counts, etc but arguably the biggest benefit is that by sending true commands instead of channel values each fixture only needs one address because it can be sent complex commands instead of a simple channel number and value. The whole thing becomes a lot less complicated and you can get rid of all your DMX splitters and combiners and all the other hacks which have been added to DMX. Undoubtedly it will be a less expensive solution to install and maintain if only because of the pervasiveness of Ethernet.
 
That's not an entirely true statement about Ethernet. In fact, long before Ethernet used CAT5 cabling and home runs it was a daisy chain "bus" topology.

Yes, but at slower rates. The old coax Ts and terminators would not really work for 100mbit or 1G ether. Also, remember why 10BaseT became popular in the first place. A coax multidrop for ethernet had pretty much the same cost and connectivity problems as DMX-512.

Synchronous networks run pretty well in a ring, but a standard that does not leverage on the widely deployed and readily available NIC adapters we have now isn't going to get very far.

Why set your sights low when running Ethernet direct to each fixture can solve all of these problems and more? Ethernet is inherently a more flexible technology than DMX. If you plug each fixture into an Ethernet network and use TCP/IP you can have them auto addresses by a DHCP server and then do all the fixture configuration by computer assigning a "fixture number" and so on so that you don't need to refer to it by IP address. There are lots of other cool things you could do such as easy two way communication with fixtures which could alert you to bulb hour counts, etc

Actually, it gets a bit more complicated. Every DMX device would *start* with a unique address - the MAC address. DHCP just assigns a TCP/IP address and passes on gateway and DNS information. There still has to be another discovery mechanism, and addressing mechanism for fixtures. Each of these steps means some complexity.

And, ethernet is not a panacea. Using stock NIC adapters and a UDP (datagram) protocol, 24 universes at 30 Hz update rate is about it. After that, you get flickering and stuttering - that is 3 Mbit of data on a dedicated 10 Mbit (or even 100 Mbit) line. It the difference between what ethernet and NIC adapters are designed for, and a real time, low latency application like DMX.

Yes, duplex communication has some nice advantages, but look at how slow we are moving on RDM - which basically just uses the duplex tranceivers we've been sticking in DMX devices since day one. The principle appeal of Ethernet is that CAT5 cable is cheap, reliable, and can carry reasonable bandwith with existing hardware for our purposes (24 universes over a cheap cable still beats 1 over a much more expensive one).

but arguably the biggest benefit is that by sending true commands instead of channel values each fixture only needs one address because it can be sent complex commands instead of a simple channel number and value.

Actually, I think this is the biggest hurdle facing something like ACN. What high level commands? And how do you syncronize them? With channels and levels, you can do anything with the connection that the controller and fixture 'agree' on. This is why standards like MIDI, and DMX, despite some serious technical shortcomings, have proven to have longevity and be real world practical.

This is also why I ask, what problem is ACN seeking to solve? Do devices need to be smarter because controllers can't manage DMX at the channel level? No, even at higher update rates than most consoles use now, 8000, 16000, 32000 channels is not a computational bottleneck. Do we have a bandwidth problem? No, even poorly utilized ethernet looks ample. So, why add the problem of distributed syncronization and granularity matching? In other words, high level command systems have new problems, so what existing problem are they solving?

Sorry, I'm playing devil's advocate, at least a bit. I'm not really anti ACN, and I am certainly not anti-ether, I just think ACN is something of a waste of time. I'd rather see incremental improvements like RDM and official adoption of a simple, less ambitious ethernet standard.

-jjf
 
Sorry, I'm playing devil's advocate, at least a bit. I'm not really anti ACN, and I am certainly not anti-ether, I just think ACN is something of a waste of time. I'd rather see incremental improvements like RDM and official adoption of a simple, less ambitious ethernet standard.

-jjf

Sorry, but ACN is here to stay - for better or for worse. Too many people have put too much time into it for it to go away now. Why is it so complex? because those same people each have an agenda when it came to writing the spec for the protocol. And they were each going to have at least some aspect of their agenda represented in the final specification.

Can I ask who you work for/with? You seem really knowledgeable about this stuff and I'm just curious. Thanks!
 
ACN is going to stay because the technology has gone way beyond what we are using to control it. We need a new control protocol to get away from looking at everything as a channel and start looking at things as a unit as a whole. When the lighting fixture can send back the exact data where it is in relative space no matter what kind of fixture we are looking at, then that lessens up load on console algorithms. Also, we we can stop pulling 20 lines of DMX around everywhere with single points of failure everywhere, we will be much better off. Ethernet distro gear is CHEAP. For the cost of one opto, you can buy 8 high quality switches. We need to move away from proprietary gear that only this industry uses and use gear that the rest of the world uses. This will lessen costs and improve reliability.
 
Sorry, I'm playing devil's advocate, at least a bit. I'm not really anti ACN, and I am certainly not anti-ether, I just think ACN is something of a waste of time. I'd rather see incremental improvements like RDM and official adoption of a simple, less ambitious ethernet standard.
Me too, I'm not really pro-ACN but I do think we need to look beyond DMX and be more creative than just running DMX over Ethernet which doesn't solve a lot of the problems with DMX.

Yes, but at slower rates. The old coax Ts and terminators would not really work for 100mbit or 1G ether. Also, remember why 10BaseT became popular in the first place. A coax multidrop for ethernet had pretty much the same cost and connectivity problems as DMX-512.
Synchronous networks run pretty well in a ring, but a standard that does not leverage on the widely deployed and readily available NIC adapters we have now isn't going to get very far.
It's true about 10Base2 and 10Base5 running at 10Mb/s but I was just making a point really. As an example EtherSound (which decidedly does not run at 10Mbit) uses a daisy chain topology. Personally I think it has some limitations and would prefer home runs to a switch for everything, but I'm just pointing out it is possible.

...There still has to be another discovery mechanism, and addressing mechanism for fixtures. Each of these steps means some complexity.
Discovery (often a UDP broadcast or multicast to a subnet) is a well known problem in the networking world and is reasonably easy to do in software.

And, ethernet is not a panacea. Using stock NIC adapters and a UDP (datagram) protocol, 24 universes at 30 Hz update rate is about it. After that, you get flickering and stuttering - that is 3 Mbit of data on a dedicated 10 Mbit (or even 100 Mbit) line. It the difference between what ethernet and NIC adapters are designed for, and a real time, low latency application like DMX.
I think the problem is that you're still thinking about it in DMX terms where I would argue for an entirely new system. DMX sends a constant data stream, which is needed because it's really just a serial data stream that everyone is listening to all the time. With Ethernet you could only send data when you needed to and address it to specific fixtures which means with a segmented network (see switches on each pipe/truss) you can fit tons of lights onto the network. Audio has been able to do 64 channels of 20bit (better than CD) bidirectional uncompressed audio over 100BaseT, lighting should be able to do better than that.

Yes, duplex communication has some nice advantages, but look at how slow we are moving on RDM - which basically just uses the duplex tranceivers we've been sticking in DMX devices since day one.
This might be a valid point. I thought that many devices only had DMX receivers and not transceivers which would explain slow implementation (hardware level), it's much easier to develop software to do bidirectional communication than hardware.

Actually, I think this is the biggest hurdle facing something like ACN. What high level commands? And how do you syncronize them? With channels and levels, you can do anything with the connection that the controller and fixture 'agree' on. This is why standards like MIDI, and DMX, despite some serious technical shortcomings, have proven to have longevity and be real world practical.
In such a high level command system you should be able to query the device as to which commands it supports and with a standardized command structure things should talk to one another. Alternatively, you could continue to use identifiers and values (it would be incorrect to call them channels) but you could have essentially unlimited channels per device and not use up multiple addresses per device, this is the benefit I was talking about. There's no reason a device should need more than one address in an Ethernet based control system which is of tremendous value to the devices which now suck up tons of addresses.

This is also why I ask, what problem is ACN seeking to solve? Do devices need to be smarter because controllers can't manage DMX at the channel level? No, even at higher update rates than most consoles use now, 8000, 16000, 32000 channels is not a computational bottleneck...
I would say it's not a computational bottleneck, it's a logistical one. We're stating to talk about more and more universes which seems like a silly hack to me. Fixture addresses should be unique and all of them on the same 'universe' (to use DMX terminology) so that you don't need to worry about what universe is on what pipe, etc. It's about making life simpler for designers and installers. You shouldn't have to design a plot around where you can get DMX, how many addresses are left in that universe, etc. You should be able to put the lights where you want them, plug them in and do your job as a visual designer not an infrastructure one.
 
Wow, lot's of good comments, etc. Forgive me if I miss some:

jmabray: Here to stay? Almost certainly, as is DMX-512A, but a successful protocol? Remains to be seen. Understand, I've been involved with standards bodies many times over many years. Some amazing effort went into some USB device class standards, and most never made it into a single peripheral.

Remember, I"m not the one who has to be convinced - start with the Chinese, who are making mountains of sub $1K and even sub $500 intelligent fixtures. As long as there is a huge market of DMX fixtures, combined with a huge legacy of DMX fixtures, ACN will be a complex, composite solution. Unless there is a very big payoff for users, I wouldn't count on an explosion - regardless of how much work went into the standard.
Footer4321: You don't have to look at everything as a channel/level now. For example, when you control a device on our systems, you only look at devices (whole fixture) and features. Splitting an individual channel up into features, or changing the meaning of some channels in response to settings on others, etc., is our problem. The only time you still hassle with channels is in setting fixtures in modes and addressing. RDM would largely resolve that problem.

My point is that once you adopt a 'standard' as complex as ACN, you are giving up on a lot of options and innovation. For example, some controllers use a lowest common denominator approach - mapping all fixtures to a virtual fixture. We expose all features, free form. Each approach has strengths. Time can be also managed in very different ways. We decouple time from cues/scenes (any cue, any order, any speed...) This lets us do some things that many controllers cannot. For example, when we lock to timecode, we really lock. That is, we don't just trigger a virtual 'go' button at a matched SMPTE time, everything, fades, movement generation, etc. adjusts proportionally to even slight variations in the external timebase.

Will all users care? No, some will even prefer other approaches to time. But for some applications there are users who find true chase and lock invaluable. I think that there should be choices. And markets typically agree. Successful standards typically solve a common problem in relatively flexible, simple way. Standards that try to institutionalize one of many approaches to complex problems are generally only successful if there is a massive economic incentive. They also tend to be muddy and complex because they represent bits and pieces of several solutions, not a single cohesive one.

Regarding cost-of-gear, it isn't as simple an equation as it seems. There is a mountain of legacy gear, that means that there will be ACN<>DMX boxes. Like Optosplitters, these will not have the economics of scale of a 100BaseT hub. Also, with the fierce competition in fixture pricing and margin, many vendors, particularly those targetting the most cost sensitive buyers, are unlikely to add to COG unless the market compells them to do so.
Also, no change is going to be instantaneous. So as long as there are hybrid rigs, there will be adapter boxes, which means more cost and more points of failure.

Last, office networking gear is not nec. built for our environments. RJ connectors are not very durable and have open frame/exposed pin construction (bent pins, etc.) Most inexpensive networking gear uses wall worts with friction retention connectors...

BenFranske: Most DMX gear includes a stock RS485 tranceiver (ex. SN75176B) connected to a UART. There are some pieces using a RS422 type driver connected to a gate array, but these are the exception.

I understand concepts like UDP datagrams, and am not saying that complexity equates to unsolvable problems, just that the devil is often in the details. For example, do we really want RJ connectors? Does non guranteed token discovery work for us? If I can't browse the lan at work a few minutes when I boot, I get a cup of coffee. Waiting in the dark with an angry audience... Even something as simple as 'where does the DHCP service come from' can turn out to be a bigger problem than you might think. We don't have a gradually chaning company LAN with a department to administer it. Some of us pull heaps of gear from multiple sources in short periods of time. Just food for thought.

I'm not sure I agree with your aversion to universes and channels. We have some really weird legacy limits in TCP/IP, but most folks don't worry about them. With RDM, the principal headache becomes keeping fixture chains to limits of 32. Like, say, DHCP, there are still some margin cases, but it goes a long ways towards hiding the common headaches and redundant work.

Remember, ACN does not wholly displace DMX (it relies on RDM to deal with config/address headaches too), so if you are looking for a wholly new conceptual standard, it isn't it.

Again, please don't anyone take my comments personally. I've just been around these sorts of things a long time, so I inherently sound like an ornery old coot (because I am!)

-jjf
 
This was very informative and well written. I think the issue with ArtNet is that it's a propriatary protocal, where as ACN is not, thus there's no potential *cost* for using ACN, as there might be with companies adopting, and then having to pay for continual usage of the ArtNet protocal. That's the general idea behind ACN, though I suspect you are correct in that, by being an all-things-for-everyone protocal, it's way too complex and doesn't readily solve a simple problem without a lot of effort by a lot of companies, namely how to get all those assorted consoles and appliance to be smarter in their interaction.
Big question is, why hasn't RDM taken off ?. Possibly as everyone is waiting for the next thing - ACN ?, with nobody wanting to commit to something simple, yet useful such as RDM, and then getting hammered on a bid for not being "ACN Ready".
SB

Not exactly right... The least complex version of ACN is free to license, and the source code is available. But the higher two versions of the protocol require a license fee.
 

Users who are viewing this thread

Back