Art-Net
Art-Net is a royalty-free Ethernet-based communication protocol designed for transmitting DMX512 lighting control data and Remote Device Management (RDM) over IP networks, primarily used in professional entertainment and architectural lighting applications to distribute control signals from consoles to fixtures and devices.[1] Developed by Artistic Licence Engineering Ltd., it enables the transport of up to 512 channels per DMX universe across Ethernet infrastructure, supporting unicast and broadcast methods for efficient data delivery.[2] The protocol originated in 1998 with Art-Net I, which initially supported up to 256 DMX universes via broadcast transmission, though practical limits were often lower due to network constraints.[3] Subsequent versions addressed these issues: Art-Net II (2006) introduced unicast after discovery to reduce traffic; Art-Net 3 (2011) expanded addressing to 32,767 universes and mandated unicast for data packets; and Art-Net 4 (2016) further refined port configurations, deprecated broadcast for most operations, and emphasized RDM integration while aligning with standards like E1.31 sACN for live control.[3][2][4] Art-Net operates on UDP port 0x1936 within the TCP/IP suite, utilizing specific packet types such as ArtDmx for DMX512 data (with 1-512 channels and sequence numbering for reliability) and ArtRdm for RDM commands, allowing up to 32,767 universes through 15-bit port addressing (combining Net, Sub-Net, and Universe fields).[2] It has been adopted by over 500 manufacturers worldwide, requiring OEM implementations to include conformance testing via Artistic Licence's ACT software and proper crediting of the protocol's ownership.[1] The protocol's scalability and compatibility with existing Ethernet hardware make it a cornerstone for networked lighting systems, though it recommends network segmentation to manage bandwidth for high-universe setups.[3]Overview
Definition and Purpose
Art-Net is a royalty-free, UDP-based communications protocol designed for transporting DMX512-A and Remote Device Management (RDM) data over IPv4 Ethernet networks.[2] Developed to leverage standard networking infrastructure, it facilitates the transmission of lighting control signals without the need for proprietary hardware beyond conventional Ethernet interfaces.[5] The protocol's core purpose is to enable precise control of lighting fixtures, LEDs, and other entertainment devices in applications such as stage productions, architectural installations, and broadcast environments. By extending the foundational DMX512 protocol—which is limited to 512 channels per universe—Art-Net allows multiple DMX universes, up to 32,768 in later versions, to be sent over a single network cable, supporting expansive setups that would otherwise require extensive cabling.[5][2] Key benefits of Art-Net include enhanced scalability for large-scale installations, remote patching to reconfigure device assignments, merging of signals from multiple controllers, and real-time monitoring of network status and devices. It is widely adopted, with support from hundreds of manufacturers worldwide, ensuring interoperability across diverse lighting and control equipment.[5][1][2]History and Development
Art-Net was developed by Wayne Howell, founder of Artistic Licence Engineering Ltd. in the United Kingdom, to overcome the limitations of the DMX512 protocol, such as its restriction to point-to-point wiring and short cable runs, by enabling DMX data transmission over Ethernet networks.[2][5] The protocol emerged in the late 1990s as an open, royalty-free standard to facilitate networked lighting control in theatrical and entertainment environments.[2][5] The initial version, Art-Net I, launched in 1998 as a broadcast-based solution optimized for early 10 Mbps Ethernet networks, supporting up to 256 DMX universes through UDP packets.[5][3] In 2006, Art-Net II introduced unicast transmission following device discovery, reducing network congestion while maintaining backward compatibility with the broadcast startup of Art-Net I.[5][3] Art-Net III followed in 2011, expanding addressing to 15 bits to accommodate up to 32,768 DMX universes, driven by the growing demand for pixel-based lighting systems.[5][3] The protocol reached Art-Net IV in September 2016, adding support for sACN compatibility, enhanced Remote Device Management (RDM) features, and Video Light Control (VLC) data transmission, which earned it the PLASA Award for Innovation that year.[5][2][6] In September 2022, Artistic Licence was acquired by Robe Lighting, the world's leading entertainment lighting manufacturer.[7] Robe continues to maintain Art-Net as an open standard with no royalty fees, focusing on refinements rather than major new versions since 2016 to ensure broad compatibility across devices.[2][8] The protocol document was revised to version 1.4 on October 23, 2025, incorporating features for sACN management, such as using Art-Net for discovery and RDM while leveraging sACN for live data streams.[2]Protocol Evolution
Versions
Art-Net I, released in 1998, introduced the foundational protocol for transmitting DMX512 data over Ethernet networks using a broadcast-only topology.[4] This version was designed for 10BaseT networks and supported approximately 10 DMX universes effectively, though theoretically up to around 40, through basic ArtDMX packets that carried 256 channels per universe.[4] The broadcast approach simplified initial setup by eliminating the need for network configuration but limited scalability due to network congestion.[4] Art-Net II, introduced in 2006, marked a significant advancement by incorporating unicast transmission to reduce network load and improve efficiency after nodes learned universe mappings dynamically.[4] It expanded support to 256 DMX universes and added new packet types, including ArtCommand for device control and ArtPoll for network discovery, enabling better management in larger setups.[4] These enhancements allowed for more reliable data distribution over Ethernet while maintaining compatibility with earlier hardware.[5] Art-Net III, launched in 2011, addressed scalability limitations with 15-bit addressing that permitted up to 32,768 DMX universes, a substantial increase from prior versions.[4] It introduced the Binding mechanism to facilitate multi-port gateways, allowing multiple universes to be assigned to individual ports on a single device, and enhanced discovery processes through ArtPollReply packets that provided detailed node information.[4] This version also supported multi-homing, where unique IP addresses could be assigned to blocks of four ports, improving flexibility in complex network environments.[4] Art-Net IV, released in September 2016 and revised in 2025, further optimized the protocol for high-density applications by supporting over 1,000 DMX ports per IP address through advanced port management.[4] Key additions included a compatibility toggle for sACN (E1.31) to enable seamless integration with other streaming protocols, full Remote Device Management (RDM) integration for bidirectional device communication, and support for Video Light Control (VLC) to handle visible light communication data.[4] The 2025 document update, version 1.4 dated October 23, refined sACN management by mandating unicast for certain packets like ArtPollReply and incorporating BindIndex updates in various command packets to enhance scalability and reduce broadcast overhead.[2]Key Enhancements Across Versions
The evolution of Art-Net from version I to IV reflects a series of targeted improvements addressing scalability, efficiency, and interoperability challenges in lighting control networks. In Art-Net I, the protocol relied exclusively on broadcast transmissions over Ethernet, which efficiently distributed DMX512 data in small setups but led to network saturation in larger configurations due to constant flooding of packets to all devices.[4] Art-Net II introduced a critical shift to unicast communication, where nodes learn universe mappings during discovery and subsequently send data directly to targeted recipients, significantly reducing bandwidth waste and enabling support for up to 256 universes without overwhelming the network. This enhancement allowed for larger installations, such as those with multiple DMX controllers, by minimizing unnecessary traffic and improving overall system reliability in bandwidth-constrained environments.[4][9] Building on this foundation, Art-Net III expanded addressing from 8-bit to 15-bit port numbers, increasing the addressable universes from 256 to 32,768 and accommodating massive pixel-based applications like LED walls requiring thousands of channels. This change, combined with binding mechanisms for multi-port gateways, addressed the limitations of earlier versions in handling high-channel-count systems while maintaining compatibility with prior implementations.[4] Art-Net IV further advanced integrations by mandating unicast for RDM packets to enable efficient bidirectional device management, such as remote configuration and diagnostics, and introducing sACN compatibility through dedicated address packets for seamless interoperability with ANSI E1.31 standards. Additionally, it incorporated VLC support for synchronizing lighting with video streams and enhanced features like synchronous data transmission via ArtSync packets, evolving the protocol into a versatile ecosystem that supports data merging, priority assignment, and real-time monitoring across diverse setups. These cumulative developments have transformed Art-Net from a basic DMX transport layer into a robust, backward-compatible framework for professional entertainment networks.[4][2]Technical Framework
Addressing
Art-Net employs a hierarchical addressing scheme to identify and route DMX data across networks, enabling precise control of lighting universes and devices.Universe Addressing
In Art-Net III and IV, universe addressing utilizes a 15-bit system, supporting Universe IDs from 0 to 32,767 and accommodating up to 32,768 distinct DMX universes. This is encoded with Bit 15 set to 0, Bits 14-8 representing the Net field (7 bits), Bits 7-4 the Sub-Net field (4 bits), and Bits 3-0 the Universe field (4 bits), forming a comprehensive Port-Address for scalability in large installations. Earlier versions, such as Art-Net II, were limited to an 8-bit Universe field (0-255), restricting the addressable universes to 256 per network segment. Nodes indicate support for the 8-bit legacy mode via the ArtPollReply Status2 Bit 3. This evolution allows for expanded network capacity, theoretically supporting up to 400 universes on a 100BaseT unicast Ethernet link, depending on physical layer constraints.[2]Node and Port Addressing
Nodes in an Art-Net network are identified by their unique IP addresses, typically derived from the device's MAC address (e.g., in the 2.x.y.z range with a 255.0.0.0 subnet mask), ensuring reliable unicast routing. Port addressing builds on this hierarchy: the Net field spans 0-127 (7 bits), defining broad network segments; the Sub-Net field covers 0-15 (4 bits), subdividing each Net into 16 groups; and the Universe field ranges 0-15 (4 bits) in legacy configurations, pinpointing individual DMX ports within a Sub-Net. This structure allows a single node to manage multiple ports, with the full 15-bit Port-Address (valid range 1-32,767; 0 deprecated for sACN compatibility) carried in packet headers to direct data flow. For example, a Port-Address might combine Net=0, Sub-Net=0, and Universe=1 to target the first universe on the default segment.[2]Binding and Merging
Binding in Art-Net assigns multiple local DMX output ports to a single IP address on a node, using the BindIndex field (starting at 1 for the root device) in messages like ArtPollReply and ArtAddress to group and identify these ports efficiently. Merging enables multiple controllers to share control of the same universe, combining DMX streams via Latest-Takes-Precedence (LTP) or Highest-Takes-Precedence (HTP) modes specified in ArtAddress packets, with support limited to two sources per universe. If sources fail, the node holds the last valid merge result for 10 seconds before reverting. Priority levels, ranging from 0 (lowest) to 200 (highest), are assigned via the AcnPriority field in ArtAddress (with 255 indicating no change), allowing hierarchical control where higher-priority inputs override lower ones during conflicts. This mechanism ensures synchronized operation in multi-controller environments without data loss.[2]RDM Addressing
Art-Net extends addressing to support Remote Device Management (RDM) through unique 48-bit device identifiers (UIDs), facilitating bidirectional communication between controllers and lighting fixtures. RDM data is transported via dedicated ArtRdm packets, which mandate unicast transmission to specific device UIDs for non-discovery commands such as configuration and parameter get/set. Nodes with RDM capability (indicated by ArtPollReply Status1 Bit 1) maintain a Table of Devices (ToD) listing connected UIDs, updated and shared via ArtTodData packets upon changes, enabling precise targeting of individual devices within a universe. Discovery commands are proxied locally by Art-Net devices. This integration allows Art-Net to handle RDM's peer-to-peer model over Ethernet, supporting up to thousands of devices per network segment.[2]Packet Format
Art-Net packets are structured as binary UDP datagrams with a fixed 18-byte header followed by a variable-length payload, ensuring efficient transmission of DMX512 data over Ethernet networks. The header begins with an 8-byte identifier "Art-Net\0" (ASCII values 0x41, 0x72, 0x74, 0x2D, 0x4E, 0x65, 0x74, 0x00), which allows receiving nodes to validate incoming packets against the protocol specification.[2] Immediately following is a 16-bit opcode field (bytes 8-9, transmitted low byte first in little-endian format), which specifies the packet type; for example, the opcode 0x5000 denotes an ArtDmx packet for streaming DMX data.[2] Bytes 10 and 11 represent the protocol version as two 8-bit integers (ProtVerHi and ProtVerLo), with the current Art-Net 4 version encoded as 0x00 (high) and 0x0E (low, decimal 14), enabling backward compatibility checks by receivers.[2] Byte 12 contains an 8-bit sequence number (0x00 to disable ordering or 0x01-0xFF for packet sequencing), which helps in detecting lost or out-of-order transmissions, particularly for real-time DMX streams.[2] The remaining header bytes (13-17) are type-specific, with the total header fixed at 18 bytes to maintain a consistent offset for payloads. For the ArtDmx packet, which carries DMX512 lighting control data, byte 13 holds an 8-bit physical port identifier (0-4, typically 0 for standard use), byte 14 is the low byte of a 15-bit universe address (SubUni, bits 7-0), and byte 15 provides the high 7 bits of the universe (Net, bits 14-8), together forming a port-address for routing data to specific DMX universes.[2] Bytes 16 and 17 form a 16-bit length field (high byte first, big-endian), indicating the size of the DMX payload in bytes (range 2-512, must be even), which follows immediately at byte 18 as an array of up to 512 8-bit DMX channel values, each representing intensity levels from 0 to 255.[2] This structure allows a single ArtDmx packet to encapsulate a full DMX512 frame, with the variable payload ensuring flexibility while keeping the maximum total packet size at 530 bytes (18 + 512) to fit within standard UDP limits of 576 bytes for efficient broadcast or unicast transmission.[2] Common fields across packets include the sender's IP address and UDP port (standard port 0x1936 or 6454), embedded in the UDP header rather than the Art-Net payload, facilitating identification of the originating node.[2] For unicast delivery, packets are directed to the receiver's specific IP address, while broadcasts use 255.255.255.255; status and error flags appear in dedicated packets like ArtPollReply but are absent from the core ArtDmx structure.[2] An optional checksum, computed in an IP-style manner for data integrity, may be included in certain packet types (e.g., ArtVlc) but is not required for standard ArtDmx transmissions, relying instead on UDP's lightweight nature.[2] Opcodes link to protocol facilities, such as polling for discovery, but the binary format prioritizes simplicity and low overhead for high-volume data flows.[2] The following table illustrates the byte-level structure of an ArtDmx packet for clarity:| Byte Offset | Field | Size (Bytes) | Type | Description |
|---|---|---|---|---|
| 0-7 | ID | 8 | Int8[10] | "Art-Net\0" identifier |
| 8-9 | OpCode | 2 | Int16 | 0x5000 (little-endian) for ArtDmx |
| 10 | ProtVerHi | 1 | Int8 | Protocol version high byte (0x00) |
| 11 | ProtVerLo | 1 | Int8 | Protocol version low byte (0x0E) |
| 12 | Sequence | 1 | Int8 | Packet sequence number |
| 13 | Physical | 1 | Int8 | Physical port (0-4) |
| 14 | SubUni | 1 | Int8 | Universe low byte (bits 7-0) |
| 15 | Net | 1 | Int8 | Universe high bits (14-8) |
| 16-17 | Length | 2 | Int16 | DMX data length (big-endian, 2-512 bytes) |
| 18+ | DMX Data | Variable | Int8[] | Up to 512 DMX channel values |