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
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.
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.
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
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.
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.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.
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....There still has to be another discovery mechanism, and addressing mechanism for fixtures. Each of these steps means some complexity.
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.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.
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.
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.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.
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.
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
We use essential cookies to make this site work, and optional cookies to enhance your experience.