What is Art-Net? Nodes, Port-Addresses and RDM explained
Art-Net is a protocol for carrying DMX512 lighting data over an ordinary Ethernet network, using UDP packets on port 6454. It was invented by Wayne Howell, the founder of Artistic Licence, and that company still owns and publishes it: anyone may implement Art-Net without paying a royalty, provided their user guide carries the credit Artistic Licence requires.
This guide covers what a node does, how a Port-Address is built from Net, Sub-Net and Universe, how controllers find nodes with ArtPoll, and how RDM travels over Art-Net. It also corrects the most repeated claim about the protocol: Art-Net 4 does not broadcast lighting data, it forbids it. Every figure comes from the current specification, Art-Net 4 revision 1.4dp.
Last updated
What Art-Net actually is
The current document is Art-Net 4, Specification for the Art-Net 4 Ethernet Communication Protocol, copyright Artistic Licence 1998-2025. Art-Net is a trademark of Artistic Licence Engineering Ltd, and the specification's own spelling is Art-Net: hyphenated, capital A, capital N.
Ownership is the structural difference from sACN, which ESTA publishes as an American National Standard. Art-Net is one company's protocol, given away: "Any third parties are welcome to use this communication protocol without royalty." Two obligations attach. A user guide must carry the credit "Art-Net(TM) Designed by and Copyright Artistic Licence", and implementers must apply for an OemCode identifying their product on the network.
Its scope is wider than sACN's: levels travel in ArtDmx, but the same protocol on the same port also discovers devices, configures them, synchronises universes and carries RDM.
How Art-Net travels: UDP 6454 and the 2.x.x.x scheme
Art-Net uses a single UDP port, 0x1936, which is 6454 decimal, as both source and destination: "Art-Net uses only one port of 0x1936." Data, discovery, configuration and RDM all share it. Worth knowing when comparing the two protocols, 6454 is not registered with IANA, whose registry lists 6447 to 6454 as Unassigned. sACN's 5568 is registered, as sdt.
The addressing is what catches people out on a first install. Art-Net products factory start on a Class A scheme: "Products implementing Art-Net should default to the Primary IP address of 2.?.?.?". A switch on the device selects a high byte of 2 or 10, the lower bytes come from the MAC address plus the OEM code, and "the sub-net mask is always initialised to 255.0.0.0, unless a custom IP address is in use".
A /8 mask makes the whole Art-Net world one flat network: every node is reachable without a router, and one directed broadcast to 2.255.255.255 reaches everything, which is what discovery needs. The cost is that your computer has to join that network, so a laptop on 192.168.1.x sees nothing from a node on 2.0.0.1 and nothing looks broken. Controllers poll both defaults, 2.255.255.255 and 10.255.255.255, DHCP is supported as an alternative, and the specification warns that Art-Net data must not be routed onto the internet. DMXDesktop is IPv4 only.
Port-Addresses: Net, Sub-Net and Universe
Art-Net has no plain universe number. It has a Port-Address, a 15-bit value assembled from three fields, described in the specification as "one of the 32,768 possible addresses to which a DMX frame can be directed".
| Field | Bits | Range | What it means |
|---|---|---|---|
| Bit 15 | 1 | always 0 | Reserved, which keeps a Port-Address to 15 bits |
| Net | 7 (bits 14 to 8) | 0 to 127 | 16 consecutive Sub-Nets, so 256 universes. There are 128 Nets |
| Sub-Net | 4 (bits 7 to 4) | 0 to 15 | 16 consecutive universes. Nothing to do with a subnet mask |
| Universe | 4 (bits 3 to 0) | 0 to 15 | The universe within that Sub-Net |
How many universes, and the numbering trap
The theoretical limit is 32,768, but the usable figure is the honest one: "The Port-Address valid range is 1 - 32,767. The value of zero is deprecated to enhance sACN compatibility." That is a genuine convergence, since E1.31 has always forbidden universe 0 outright. The real ceiling is usually the physical layer: the specification's unicast rule of thumb is about 400 universes on 100BaseT and 4,000 or more on 1000BaseT.
Now the trap, which is the commonest Art-Net support question. Art-Net counts universes from 0. DMXDesktop counts from 1, and so does sACN. DMXDesktop presents Art-Net addressing as one flat 15-bit field, 1 to 32768, and converts on the way out, so DMXDesktop universe 1 is transmitted as Art-Net universe 0. Net and Sub-Net are implied by that number rather than typed separately: the top 7 bits become the Net, the low 8 the Sub-Net and Universe. Node interfaces differ over whether they show the raw wire number or a 1-based one, so when output lands exactly one universe out, this is why.
DMXDesktop's own limits come from your plan rather than the protocol: 1 universe on Free, 2 on Standard, and no licence ceiling on Pro, where the engine caps output at 1024 universes.
Discovery: ArtPoll and ArtPollReply
This is the capability sACN has no equivalent of. "The ArtPoll packet is used to discover the presence of other Controllers, Nodes and Media Servers... Both Controllers and Nodes respond to the packet." A controller broadcasts ArtPoll to 2.255.255.255 on UDP 6454, and each device answers with an ArtPollReply giving its name, the Port-Addresses on its inputs and outputs, whether it does RDM, and its merge or error status.
Two timings are stated as requirements:
- Poll every 2.5 to 3 seconds. "It is a requirement of Art-Net that all controllers broadcast an ArtPoll every 2.5 to 3 seconds. This ensures that any network devices can easily detect a disconnect."
- Assume a 3 second reply timeout. If nothing arrives in that window, the controller "should consider the Node to have disconnected".
One Art-Net 4 change is easy to miss in older material: ArtPollReply may no longer be broadcast. Replies must be unicast back to the poller, mandated to mitigate scalability problems on very large networks.
DMXDesktop polls every 2500 milliseconds on every interface it detects, parses replies into a live node list carrying each port's universe and RDM flag, and answers inbound ArtPoll so other controllers see it as a node. It publishes ESTA manufacturer code 0x0786 and declares Art-Net 3 and 4 capability.
The broadcast myth: ArtDmx must be unicast
Search for Art-Net and you will be told repeatedly that it broadcasts DMX data to the whole network. For Art-Net 4 that is wrong, and the specification could hardly be clearer.
The ArtDmx packet strategy table lists Broadcast as "No" for a Controller, a Node and a Media Server alike. The text reads: "ArtDmx packets must be unicast to subscribers of the specific universe contained in the ArtDmx packet... If there are no subscribers to a universe, the controller shall not send ArtDmx." And then, leaving no room at all: "There are no conditions in which broadcast is allowed."
So how does a controller know where to send? Through discovery, which is why ArtPoll is structural rather than cosmetic. "The transmitting device must regularly ArtPoll the network to detect any change in devices which are subscribed. Nodes that are subscribed will list the subscription universe in the ArtPollReply." A node earns its data by answering ArtPoll and declaring which Port-Addresses it wants, which explains most "the node is on the network but the fixtures are dark" faults.
There is a neat asymmetry here. Art-Net data is unicast only. Art-Net synchronisation is broadcast only. ArtSync, for video and media-wall work where several universes must land in the same instant, is directed broadcast, with unicast not allowed.
DMXDesktop unicasts to a node address, which is the compliant route, and also offers a per-universe Broadcast switch targeting 2.255.255.255 for older gear that does not subscribe properly. It does not send ArtSync.
Merging: what Art-Net does instead of priority
sACN resolves competing sources with a priority octet. Art-Net has no priority field at all. ArtDmx carries an ID, OpCode, protocol version, Sequence, Physical, SubUni, Net, Length and Data, and nowhere to rank one source above another.
Merging happens instead, at the node. When ArtDmx for the same Port-Address arrives from two different IP addresses, or two Physical ports on one IP, the node either flags an error and waits for a human, or merges: "Merge is implemented in either LTP or HTP mode as specified by the ArtAddress packet", so the mode is a property of the node, set over the network.
- Two sources, hard limit. "Merging is limited to two sources, any additional sources will be ignored by the Node."
- A stopped source lingers 10 seconds. "If either (but not both) sources of ArtDmx stop, the failed source is held in the merge buffer for 10 seconds."
- If both stop, the output holds. "If both sources of ArtDmx fail, the output holds the last merge result." That is the opposite of sACN, where the required gateway mode on data loss is to stop transmitting DMX512.
DMXDesktop therefore offers its Priority merge mode only on sACN rows, and Art-Net input merges by HTP or LTP. Receiving DMX over the network requires a Pro plan.
Frame rate and keep-alive
A node declares how fast it will be fed: "The ArtPollReply-RefreshRate defines the maximum refresh rate that a gateway can accept ArtDmx packets. For a gateway outputting DMX512, this will always be the maximum rate of 44Hz." Non-DMX512 gateways may declare a higher limit. That ceiling is not an Art-Net invention: it is DMX512's own maximum refresh rate for a full 513-slot packet, from ANSI E1.11.
When nothing changes, an output port keeps re-transmitting the same frame. A static input re-sends its last valid ArtDmx packet at roughly four second intervals, though the specification recommends "a re-transmit time of 800mS to 1000mS" to converge with sACN, which is exactly the sACN keep-alive window.
DMXDesktop outputs at 40 Hz by default, configurable from 10 to 44 Hz per universe, with the same default and range for USB and network output.
RDM over Art-Net
RDM lets you talk back to fixtures down the same path: read an address, set it, ask what a device is. Art-Net carries it. sACN does not and cannot, because ANSI E1.31 defines no RDM mechanism at all.
Art-Net splits the job. Messages travel in ArtRdm, which "is used to transport all non-discovery RDM messages over Art-Net", unicast only. Discovery uses a Table of RDM Devices, the TOD, maintained per port: a controller asks with ArtTodRequest and receives ArtTodData. A node "must not interpret it as forcing full discovery. Full discovery is only initiated at power on or when an ArtTodControl.AtcFlush is received", so a fixture plugged in later needs an explicit flush before it appears.
The caveat many product pages get wrong: RDM over Art-Net is Artistic Licence's own transport inside its own protocol, not an ESTA standard. The ESTA standard for RDM over IP is RDMnet, ANSI E1.33. A datasheet claiming "RDM over sACN" is describing something that does not exist.
In DMXDesktop this is automatic: an RDM transport is registered for every discovered node whose ArtPollReply sets the RDM flag, and removed when that node leaves. RDM is available on the Standard and Pro plans. For hardware, start with the DMXKing eDMX MAX range (eDMX1 to eDMX8 MAX, plus the DIN rail variants), officially supported since version 1.0.51, speaking both Art-Net and sACN, with RDM verified on the bench here rather than only on the box. The Obsidian Netron EN4 is another verified Art-Net gateway with working RDM, and the supported hardware page records which devices were physically tested.
Art-Net and sACN on the same network
The two are not a straight either-or. Art-Net 4 added command options to ArtAddress that let a controller select, per gateway port, whether it converts sACN or Art-Net to DMX, so one Art-Net controller can configure a mixed rig.
The argument for that is quoted with its attribution attached, because it is a vendor describing a competing protocol in its own document. The Art-Net 4 specification says: "sACN is gaining in popularity as a method of transporting DMX data. However, it lacks any ability discover devices, configure devices or transport RDM data... This allows users to choose Art-Net as the discovery, management and RDM tool, while using sACN for the live control data."
Read as advocacy, the checkable part still holds: E1.31 defines no device configuration and no RDM transport. What it omits is what sACN has and Art-Net does not, principally the priority field and multicast addressing. There is a row-by-row comparison in the Art-Net vs sACN guide.
Common Art-Net problems
Nearly every Art-Net fault is one of these, and the first two account for most of them.
| Symptom | Most likely cause | What to check |
|---|---|---|
| The node never appears in the device list | Different IP ranges | Nodes default to 2.x.x.x or 10.x.x.x, mask 255.0.0.0. Put the computer in the same range, or set a custom scheme at both ends |
| Node is discovered, fixtures stay dark | Node not subscribed to that Port-Address | Art-Net 4 data is unicast to subscribers only. The node must list that universe on an input or output |
| Everything is exactly one universe out | Art-Net counts from 0 | DMXDesktop universe 1 goes out as Art-Net universe 0. Check whether the node shows the raw number or a 1-based one |
| Nothing at all, network otherwise fine | Firewall blocking UDP 6454 | Allow UDP 6454 in and out. Art-Net uses it as both source and destination port |
| Works on one machine, not another | Wrong network interface | Pick the adapter on the lighting network, and disable virtual adapters added by VPN software |
| Output flickers with two controllers running | Two sources merging on one Port-Address | There is no priority field. The node merges HTP or LTP, limited to two sources. Take one controller off the universe |
| A desk is off but its levels persist | The 10 second merge hold | A stopped source stays in the merge buffer for 10 seconds. If both stop, the output holds the last merge result |
| Node drops out of the list, then returns | ArtPoll missing the timeout | Poll every 2.5 to 3 seconds against a 3 second reply timeout. Congested and wireless links break that cadence |
Frequently asked questions
What port does Art-Net use?
UDP port 6454, written 0x1936, as both source and destination port, and it is the only port Art-Net uses: data, discovery, configuration and RDM all share it. It is not registered with IANA, whose registry lists 6447 to 6454 as Unassigned. sACN's 5568 is registered, as sdt.
Does Art-Net broadcast DMX data?
No. In Art-Net 4, ArtDmx must be unicast to nodes subscribed to that Port-Address, and the specification states "There are no conditions in which broadcast is allowed". Broadcast is still used for ArtPoll, and ArtSync is broadcast only, but lighting data is not.
How many universes can Art-Net carry?
32,768 addresses exist in theory, with a valid Port-Address range of 1 to 32,767 and zero deprecated for sACN compatibility. In practice the network decides. In DMXDesktop the limit is your plan: 1 universe on Free, 2 on Standard, no licence ceiling on Pro.
What is the difference between Net, Sub-Net and Universe?
Three fields inside one 15-bit Port-Address. Universe is 4 bits, 0 to 15. A Sub-Net is 16 consecutive universes, also 4 bits, and despite the name has nothing to do with a subnet mask. A Net is 16 Sub-Nets, so 256 universes, and there are 128 of them.
Does Art-Net support RDM?
Yes. Non-discovery RDM messages travel in ArtRdm packets, and discovery uses a Table of RDM Devices requested with ArtTodRequest and returned as ArtTodData. This is Artistic Licence's own transport, not an ESTA standard: the standard for RDM over IP is RDMnet, ANSI E1.33. DMXDesktop supports RDM over Art-Net on the Standard and Pro plans.
Why is my Art-Net node on an address like 2.0.0.1?
That is the specification's default. Art-Net products start on a Class A address of 2.x.x.x, or 10.x.x.x if the device's network switch is set, with the lower bytes derived from the MAC address and the OEM code, and a mask of 255.0.0.0. Your computer needs an address in the same range to see it.
