Home | News | Products | Support | Download | Sales | library | Guests | Contact | WebCam | Links
CDS Logo LanBox-Talk mail archive
 
By date: Prev | Next | Index By thread: Prev | Next | Index
Subject: Re: [LCtalk] Feature request...?
From: Eric Cornwell
Date: Mon, 12 Jan 2004 19:06:03 +0100

On Sun, Jan 11, 2004 at 01:20:44AM +0100, Fokko van Duin wrote:
At 11:27 -0500 10-01-2004, Eric Cornwell wrote:
Are you planning to support Art-Net? Or ACN?

We have looked to three protocols, including Art-Net and ACN, but for what we want I understood that those protocols are not really suited. The problem with those protocols seems to be that they assume only DMX (fixture) distribution, while we also need a protocol to have full control of a box.

Actually, the exact reasons are slightly different, though the basic idea is the correct. ACN and Art-Net don't really fit our needs because they are for controller-slave communication, while we need host-controller and controller-controller communication.

ACN is meant as a replacement for DMX, and is very fixture-oriented. It is also pretty ugly here and there (XML for fixture descriptors.. blegh)

But one of the features of LCEdit is that it, too, is very fixture oriented. It would be nice someday for LCEdit to be able to plug-and-play with ACN fixtures, which will describe their capabilities through DDL (XML) files, so that LCEdit could, for example, automatically assemble control palettes for previously unknown devices. Because of its great flexibility, LCEdit is an ideal controller for ACN-enabled fixtures.

No, the LanBox itself does not need to handle that information, but it seems potentially a good fit for LCEdit.


Art-Net is basically just a pure DMX-512 over Ethernet transport, and also puts very awkward restrictions on the IP layer. It doesn't support more than 512 channels, which makes sense when sending DMX-512 to a dumb endpoint.

DMX is only 512 "channels" also, and for the record for other readers Art-Net and other protocols typically provide for up to 64 universes of DMX on one cat5 cable -- or WiFi link. Yes, data for each universe does travel in a separate packet, but at almost 40x DMX speed even on "slow" ethernet, which is what allows many universes to be handled on one link without perceptible delays.

I'm not smart enough about IP addressing to understand the restriction issue. What I do know is that I use Art-Net on my little iBook, over Airport, simultaneously with SMTP email, web browsing, and local file sharing with no problems.


In our case however the data ends up in a layer and goes through the patcher and post-processing again. It can be quite useful to broadcast, for example, 800 channels to 3 devices, and have them pick up to 512 channels to be sent to DMX out.

Also, for controller->host, we need to indicate which layer the data comes from (a concept unknown to other protocols of course) and deal with things like disabled channels.

Finally, by making a protocol tuned to the task we need it to perform, there is less overhead and complexity. In particular, we want to minimize the burden on the LanBox, as it's still only a small device. (ACN in constast appears to assume a controller with plenty of memory and computing power - witness the use of XML)

Granted, neither of these protocols may be appropriate for internal LCEdit/LanBox communication, but both could be valuable for controlling and responding to the outside world. In a future all-ACN installation LCEdit could discuss abstract control topics with the fixtures while the LanBox transmitted output levels on ACN instead of DMX, all on the same piece of wire. You could build an ACN LCX that had only the ethernet port and save some costs, I should think.


--
Eric Cornwell
By date: Prev | Next | Index By thread: Prev | Next | Index