possible error with ACN

ahelgorahelgor Registered User
Hi there!

Some time ago, I did some programming in a theatre with a working ACN setup(Eos, a lot of nodes) and Used a H3 with a dp8000 to controll all of their stuff. (build 2826)
-It could be a fault in either the dp's ACN packets, or ETc's nodes i believe.

Here's what I discovered:
-some of the nodes did not accept the ACN packets if the dmx-values of the ACN packet was not "complete" with 512 bytes.
(since The acn packets sent out of the dp only contains bytes for channels up to the last patched dmx address.)

-A workaround on the site was to just patch something on address 512 on all universes "tricking" the dp to send out "complete" ACN packets, worked very well.

-All nodes from etc where upgraded to latest software.

-Even though this is probably most likely a bug in ETC's nodes if the packets are supposed to be "shrunk" when possible to minimize packet sizes, it may lead to problems for other people with similiar ACN setups.

Comments

  • edited February 2011
    This is a common problem with Art-Net devices. The Art-Net standard allows variable length packets, but many popular Art-Net receivers break if you send them fewer than 512 slots of data. For this reason, Hogs always send 512 data slots in Art-Net packets even if you've patched less than that.

    As you found, our E1.31/sACN allows variable length packets. It only send enough data slots to cover what you've patched. This is much better behavior because without it you waste a lot of network bandwidth.

    Which ETC Net3 devices were you using? ETC has 1, 2, and 4 port nodes, and newer sensors CEM+ software will take E1.31 natively. We've tested the 4 port node extensively, so I know it supports variable length packets. If you know the CEM+ and Node firmware versions from your show, please send them to me. We have a good working relationship with ETC and several other manufacturers that make E1.31 compatible products, and can usually get this kinds of problems resolved.


    We're willing to do the 512-slot workaround in Art-Net because there are lots of legacy Art-Net devices out there that can't be easily upgraded. Art-Net is already very inefficient on the network, and this makes it only marginally worse.

    One of the major goals of E1.31 was to work better over Layer 3 networks than Art-Net. If we always force full-length packets, it eliminates much of that advantage. Also, E1.31 is new enough that any implementations should properly support variable length packets. If they don't support it, then they need to fix their software, otherwise they'll have lots of interoperability problems.
Sign In or Register to comment.