Art Net

Art-Net 4
Specification for the Art-Net 4 Ethernet Communication Protocol
www.Art-Net.info
Winner of the PLASA 2016 Innovation Award

© Copyright Artistic Licence 1998-2022
This document is released without warranty of any kind including but not limited to the
implied warranties of fitness for a particular purpose.
Art-Net™ is a trade mark of Artistic Licence. The Art-Net protocol and associated
documentation is copyright Artistic Licence. Any third parties are welcome to use this
communication protocol without royalty. Please see section on credits for details of
copyright message.
Artistic Licence request that any manufacturer who implements this protocol apply for
an OemCode at the following link: www.art-net.org.uk/?page_id=203
Contents
Document History ........................................................................................................... - 1 -
Comments on Revisions AJ-BD: .................................................................................. - 1 -
Comments on Revision BE: ......................................................................................... - 1 -
Comments on Revision BF: ......................................................................................... - 1 -
Comments on Revision BG: ........................................................................................ - 1 -
Comments on Revision BH: ........................................................................................ - 1 -
Comments on Revision BI: .......................................................................................... - 2 -
Comments on Revision BJ:.......................................................................................... - 2 -
Comments on Revision BK: ......................................................................................... - 2 -
Comments on Revision DA: ........................................................................................ - 2 -
Comments on Revision DB: ........................................................................................ - 2 -
Comments on Revision DC: ........................................................................................ - 2 -
Comments on Revision DD: ........................................................................................ - 2 -
Comments on Revision DE: ......................................................................................... - 2 -
Art-Net overview: ........................................................................................................... - 5 -
Art-Net 4: .................................................................................................................... - 5 -
Universe Addressing: .................................................................................................. - 7 -
Credits: ....................................................................................................................... - 8 -
Terminology: ............................................................................................................... - 8 -
Node........................................................................................................................ - 8 -
Port-Address ........................................................................................................... - 8 -
Net .......................................................................................................................... - 8 -
Sub-Net ................................................................................................................... - 8 -
Universe .................................................................................................................. - 8 -
Kiloverse .................................................................................................................. - 8 -
Controller ................................................................................................................ - 9 -
IP ............................................................................................................................. - 9 -
Subnet Mask ........................................................................................................... - 9 -
Port ......................................................................................................................... - 9 -
Directed Broadcast.................................................................................................. - 9 -
Limited Broadcast ................................................................................................... - 9 -
Controller ................................................................................................................ - 9 -
Media Server ........................................................................................................... - 9 -
Ethernet Implementation: ............................................................................................ - 10 -
General Notes: .......................................................................................................... - 10 -
Protocol Operation ................................................................................................... - 10 -
IP address configuration ........................................................................................... - 10 -
IP address configuration - DHCP ........................................................................... - 11 -
IP address configuration – Static Addressing ........................................................ - 11 -
IP address Example ............................................................................................... - 12 -

Controller Default Poll .............................................................................................. - 13 -
Art-Net packet definition .............................................................................................. - 14 -
ArtPoll: ...................................................................................................................... - 14 -
Multiple Controllers .............................................................................................. - 15 -
Targeted Mode ..................................................................................................... - 15 -
ArtPoll packet definition ....................................................................................... - 16 -
Table 1 - OpCodes: ................................................................................................ - 18 -
Table 2 - OemCode:............................................................................................... - 20 -
Table 3 – NodeReport Codes: ............................................................................... - 20 -
Table 4 – Style Codes: ........................................................................................... - 21 -
ArtPollReply: ............................................................................................................. - 22 -
ArtPollReply packet definition .............................................................................. - 22 -
ArtIpProg: ................................................................................................................. - 31 -
ArtIpProg packet definition ................................................................................... - 31 -
ArtIpProgReply: ........................................................................................................ - 33 -
ArtIpProgReply packet definition .......................................................................... - 33 -
ArtAddress: ............................................................................................................... - 35 -
ArtAddress packet definition ................................................................................ - 35 -
ArtDiagData: ............................................................................................................. - 42 -
ArtDiagData packet definition .............................................................................. - 42 -
Table 5 – Priority Codes: ....................................................................................... - 43 -

ArtTimeCode:............................................................................................................ - 44 -
ArtTimeCode packet definition ............................................................................. - 44 -
ArtCommand: ........................................................................................................... - 46 -
ArtCommand packet definition............................................................................. - 46 -
Table 6 – ArtCommand Commands: ..................................................................... - 47 -
ArtTrigger:................................................................................................................. - 48 -
ArtTrigger packet definition .................................................................................. - 48 -
Key......................................................................................................................... - 49 -
Table 7 – ArtTrigger Key Values. ........................................................................... - 49 -
SubKey................................................................................................................... - 49 -
Payload.................................................................................................................. - 51 -
ArtDmx:..................................................................................................................... - 52 -
Unicast Subscription: ............................................................................................ - 54 -
ArtDmx packet definition ...................................................................................... - 54 -
Refresh Rate: ......................................................................................................... - 55 -
Synchronous Data: ................................................................................................ - 55 -
Data Merging: ....................................................................................................... - 55 -
ArtSync: .................................................................................................................... - 57 -
Managing Synchronous and non-Synchronous modes ......................................... - 58 -
ArtSync packet definition ...................................................................................... - 58 -
Multiple controllers .............................................................................................. - 59 -

ArtNzs: ...................................................................................................................... - 60 -
ArtNzs packet definition ....................................................................................... - 60 -
ArtVlc: ....................................................................................................................... - 62 -
ArtVlc packet definition ........................................................................................ - 62 -
ArtInput: ................................................................................................................... - 66 -
ArtInput packet definition ..................................................................................... - 66 -
Firmware and UBEA upgrades: ..................................................................................... - 68 -
ArtFirmwareMaster: ................................................................................................. - 69 -
ArtFirmwareMaster packet definition .................................................................. - 69 -
ArtFirmwareReply:.................................................................................................... - 71 -
ArtFirmwareReply packet definition ..................................................................... - 71 -
Firmware File Format: ........................................................................................... - 72 -
RDM Support: ............................................................................................................... - 74 -
Input Gateway ....................................................................................................... - 74 -
Output Gateway .................................................................................................... - 74 -
Table of Devices (TOD): ......................................................................................... - 74 -
RDM Discovery ......................................................................................................... - 74 -
Output Gateway Operation .................................................................................. - 74 -
Input Gateway Operation ..................................................................................... - 75 -
Controller Operation: ............................................................................................ - 75 -
ArtTodRequest:......................................................................................................... - 76 -
ArtTodRequest packet definition .......................................................................... - 76 -
ArtTodData: .............................................................................................................. - 78 -
ArtTodData packet definition ............................................................................... - 78 -
ArtTodControl: .......................................................................................................... - 81 -
ArtTodControl packet definition ........................................................................... - 81 -
ArtRdm: .................................................................................................................... - 83 -
ArtRdm packet definition ...................................................................................... - 83 -
ArtRdmSub: .............................................................................................................. - 85 -
ArtRdmSub packet definition ................................................................................ - 85 -
Display of status: ........................................................................................................... - 87 -
Data Integrity: ............................................................................................................... - 87 -

Document History
Comments on Revisions AJ-BD:
• Concept of Binding Address added to ArtPollReply.
• Error in Filler count in ArtPollReply corrected.
• DHCP Flag added to ArtPollReply.
• ArtDiagData packet added.
• ArtCommand packet added.
• Detail of ArtDmx unicast corrected.
• Notes on ArtDmx length added.
• ArtTimeCode packet added.
• Art-Net 3 release.
• 15 bit universe addresses added.
• Error in description of 'Net' corrected.
• Confusion over limited vs. directed broadcast resolved.
Comments on Revision BE:

• Typing error in ArtFirmwareMaster corrected - incorrectly defined
FirmwareLength as Int32.
• ArtNzs packet added.
• EstaCode in ArtPollReply redefined as two bytes.
• Port-Address programming authority explanation improved.
• Error in default IP address example corrected.
Comments on Revision BF:

• Clarification of Endian in ArtRdmSub.
• Description of Universe Subscription improved.
Comments on Revision BG:

• Clarification that ArtTodControl must be replied to with ArtTodData.
Comments on Revision BH:

• Clarifications.
• Readability improvements.
• Added definition of ArtCommand.
• Added definition of ArtNzs.
Art-Net 4 Protocol Release V1.4 Document Revision 1.4df 12/9/2022 -1-

• Added definition of ArtTrigger.
Comments on Revision BI:

• Typographic corrections.
• ArtSync added.
Comments on Revision BJ:

• Noted OpMac OpCodes as deprecated.
• Corrected casting error in ArtTodControl definition.
Comments on Revision BK:

• ArtVlc added
• Vlc management added to ArtPoll
• Recommended ArtDmx keep alive time changed to 800mS to 1000mS for sACN
compatibility.
• Clarification to array length in ArtTodRequest.
Comments on Revision DA:

• First release of Art-Net 4.
• Requirement that bound nodes have a different IP address to the root node has
been dropped in order to avoid the need to multi-home products with more
than four ports.
• BindIndex added to ArtTodData
• sACN / Art-Net protocol selection added to ArtPollReply and ArtAddress
Comments on Revision DB:

• ArtPollReply->Status2.Bit4 defined.
Comments on Revision DC:

• All spellings of “Port Address”, “PortAddress” changed to “Port-Address”.
• TCP/IP Port Number programming in ArtIpProg now shown as deprecated.
Comments on Revision DD:

• Missing filler fields in ArtTrigger corrected.
Comments on Revision DE:

• ArtPollReply->GoodOutputB fields added.
• ArtPollReply->Status2 updated.

• ArtPollReply->Status3 added.
• Additional ArtAddress commands for failsafesupport added.
• Added DefaultResponder to ArtPollReply.
• Added LLRP support flag.
• DefaultGateway added to ArtIpProg.
• ArtRdm unicast is now mandated to mitigate scalability issues in very large
systems.
• ArtPollReply unicast is now mandated to mitigate scalability issues in very large
systems.
• Added Target mode to ArtPoll in order to reduce traffic during discovery.
• Added sACN Priority field to ArtAddress in order that the priority of sACN
packets generated by DMX input nodes can be set.
• Relationship of the ArtDmx->Physical field to merging has been clarified.
Comments on Revision DF:

• Enumerations for port direction were missing from ArtAddress. Corrected.

Art-Net overview:
Art-Net is an Ethernet protocol based on the TCP/IP protocol suite. Its purpose is to allow
transfer of large amounts of DMX512 data over a wide area using standard networking
technology.
Art-Net 4:
This latest revision of the protocol implements a number of new features and also
simplifies the data transfer mechanism. The changes are all based on feedback from
manufacturers who are using the protocol.
Art-Net 4 incorporates a new scheme to handle gateways that support multiple DMX
ports. Previously, gateways that supported more than four DMX ports would need
multiple IP addresses (multi-homing). This was an annoyance for both users and
developers and indeed could not be achieved on some hardware platforms. The new
scheme allows a gateway (or any Art-Net product) to support over 1000 DMX ports. It is
achieved by adding a field called BindIndex to 4 Art-Net packets, namely: ArtPollReply,
ArtAddress, ArtInput and ArtTodData. The BindIndex allows all Art-Net devices to identify
the ‘page of DMX ports’ to which a packet refers.
The change is, from a developer perspective, very small and will be very quick to a
product design. It has also been added in such a way that it is 100% backwards
compatible with previous releases.
Art-Net can address over 30,000 universes. Previously, each group of 4 DMX ports were
limited to universes from a consecutive block of 16. Art-Net 4 allows this limit to be
resolved as the developer can choose to identify each DMX port individually. This simply
means encoding a single DMX port in each ArtPollReply. Using this mechanism, all DMX
ports can be assigned a fully independent universe.
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. Art-Net 4
incorporates the ability to manage sACN by selecting whether a given gateway port

should convert sACN or Art-Net to the DMX output. This allows users to choose Art-Net
as the discovery, management and RDM tool, while using sACN for the live control data.

Developers updating from Art-Net 3 to Art-Net 4 should review the following change
summary:
• ArtPollReply->BindAddress can now be identical in all BindIndex.

• ArtAddress->BindIndex added to discriminate packets from same IP
• ArtInput->BindIndex added to discriminate packets from same IP
• ArtTodData->BindIndex added to discriminate packets from same IP.
• ArtAddress->Command options added to select sACN or Art-Net conversion
• ArtPollReply broadcast not allowed.
• ArtRdm broadcast no longer allowed.
• ArtPoll Targeting options.
• ArtPollReply – numerous additional bit-fields.
Universe Addressing:
A theoretical limit of 32,768 universes exists in the Art-Net 4 specification. The actual
number of universes that can be transmitted is dependent upon both the network
physical layer and the casting used. The following table provides a rule of thumb.
Addressing Physical: 10BaseT Physical: 100BaseT Physical:

1000BaseT
Unicast 40 400 4000+
The Port-Address of each DMX512 Universe is encoded as a 15-bit number as shown in

the following table.
Bit 15 Bits 14-8 Bits 7-4 Bits 3-0

0 Net Sub-Net Universe
Port-Address

The high byte is called the 'Net'. This was introduced at Art-Net 3 and was previously
zero. The Net has a single value for each node. The high nibble of the low byte is referred
to as the Sub-Net address and is set to a single value for each Node. The low nibble of
the low byte is used to define the individual DMX512 Universe within the Node.
This means that any Node will have:
• One “Net” switch.
• One “Sub-Net” switch.
• One “Universe” switch for each implemented DMX512 input or output.
A product designer may opt to implement these as hard or soft switches.
Credits:
Any person or entity which implements Art-Net in their products shall include a user
guide credit of: "Art-Net™ Designed by and Copyright Artistic Licence".
Terminology:
Node: A device that translates DMX512 to or from Art-Net is referred to as a Node.
Port-Address: one of the 32,768 possible addresses to which a DMX frame can be
directed. The Port-Address is a 15-bit number composed of Net+Sub-Net+Universe.
Net: A group of 16 consecutive Sub-Nets or 256 consecutive Universes is referred to as a

net. There are 128 Nets in total.
Sub-Net: A group of 16 consecutive universes is referred to as a sub-net. (Not to be

confused with the subnet mask).
Universe: A single DMX512 frame of 512 channels is referred to as a Universe.
Kiloverse: A group of 1024 Universes.

Controller: A central controller or monitoring device (lighting console) is referred to as
a Controller.
IP: The IP is the Internet protocol address. It is expressed in either a long word format
(0x12345678) or dot format (2.255.255.255). Convention is that the former is
hexadecimal and the latter is decimal. The IP uniquely identifies any Nodes or Controllers
on a network.
Subnet Mask: Defines which part of the IP represents the Network address and which
part represents the Node address. Example: A Sub-Net mask of 255.0.0.0 means that the
first byte of the IP is the network address and the remaining three bytes are the Node
address.
Port: Actual data transmission on Art-Net uses the UDP protocol that operates ‘on top
of’ the TCP/IP protocol. UDP data transfer operates by transferring data from a specific
IP:Port on a Node or Controller to a second specific IP:Port on a second Node or
Controller. Art-Net uses only one port of 0x1936.
Directed Broadcast: When a network first connects, the Controller does not know the
number of Nodes on the network, nor does it know their IP addresses. The Directed
broadcast address allows the Controller to send an ArtPoll to all Nodes on the network.
Limited Broadcast: Art-Net packets should not be broadcast to the Limited Broadcast
address of 255.255.255.255.
Controller: A generic term describing an Art-Net device with the primary task of
generating control data. For example, a lighting console.
Media Server: A generic term describing an Art-Net device capable of generating

control data based on the ‘mx’ Media Extensions to Art-Net.

Ethernet Implementation:
General Notes:
All communication is UDP. Each packet format defined in this document forms the Data
field of an enclosing UDP packet.
Packet formats are specified in a manner similar to C-language structures, in which all
data items are considered to be unsigned integers of type INT8, INT16 or INT32
according to the number of bits. There are no hidden padding bytes, except at the very
end of a packet, which may be rounded up to a multiple of 2 or 4 bytes. Extra bytes at
the end of a valid received packet are ignored.
The protocols are generalised for handling future versions with increased numbers of
ports.
Many bit data fields contain unused positions. These may be used in future versions of
the protocol. They should be transmitted as zero and not tested by receivers.
All packet definitions are designed such that their length can be increased in future
revisions, whilst retaining compatibility. For this reason, only minimum packet length is
checked in this protocol.
Protocol Operation
A Node operates in one mode, each Node having a unique IP address derived from its
Ethernet MAC address. The UDP port used as both source and destination is 0x1936.
IP address configuration
The Art-Net protocol can operate on either a DHCP managed address scheme or using
static addresses. By default an Art-Net product will factory start using a Class A IP
address scheme. This allows Art-Net products to communicate directly and without the
need for a DHCP server to be connected to the network.
Art-Net 4 Protocol Release V1.4 Document Revision 1.4df 12/9/2022 - 10 -

IP address configuration - DHCP
Nodes report whether they are DHCP capable in the ArtPollReply packet. This document
details packets on the assumption that static addressing is used. When DHCP is used, the
addressing and subnet masks will be modified as dictated by the DHCP server.
IP address configuration – Static Addressing
The use of Class A addressing is allowed within a closed network. It is important to

ensure that Art-Net data is not routed onto the Internet.
Products implementing Art-Net should default to the Primary IP address of 2.?.?.?.
The IP address consists of a 32 bit number designated as A.B.C.D. The bytes B.C.D are
calculated from the MAC address. The high byte ‘A’ is set to one of two values as shown
in the following table.
The MAC address is a 48 bit number designated u:v:w:x:y:z. This is a globally unique
number. The upper three bytes ‘u:v:w’ are registered to a specific organisation. The
lower three bytes ‘x:y:z’ are assigned by that organisation. In order to ensure that there
is minimal possibility of IP address conflicts between different manufacturers supporting
Art-Net, the product OEM code is added to the MAC address.
The ‘B’ field of the IP address is calculated by adding the high byte of the OEM code with
the low byte of the OEM code and the ‘x’ field of the MAC address.
On power up, the Node checks its configuration for IP addressing mode. If it has been
programmed to use a custom IP address, the following procedure is not used.

IP Address A.B.C.D Subnet Mask
Product Switch Settings A B C D
Custom IP Programmed As Programmed As Programmed
Network Switch Off 2 x+OEM y z 255.0.0.0
Network Switch On 10 x+OEM y z 255.0.0.0
The sub-net mask is always initialised to 255.0.0.0, unless a custom IP address is in use.
This means that the network address is the most significant 8 bits and the Node address
is the least significant 24 bits of the IP address. This is a Class A network address and for
this reason care must be exercised when connecting to other networks. If an installation
requires connection of an Art-Net network to another network that has Internet access,
then the connection must be implemented via a router that filters out the Class A
addresses.
IP address Example
Given the following settings, the IP address calculation will be as follows:
• Network Switch = Off
• MAC address = 12:45:78:98:34:76 (hexadecimal number)
• OEM code = 0x0010
Calculation:
• IP Address A = 2.
• IP Address B = 168 (0x98 + 0 + 16).
• IP Address C = 52 (0x34 from MAC address).
• IP Address D = 118 (0x76 from MAC address).
• IP Address = 2.168.52.118.

Controller Default Poll
By default a Controller should poll both the primary and secondary Art-Net addresses:
• 2.255.255.255:0x1936 Primary Art-Net Address
• 10.255.255.255:0x1936 Secondary Art-Net Address

Art-Net packet definition
All UDP packets accepted by the Node conform to the Art-Net protocol specification as
defined below. Any other packets are ignored.
ArtPoll:
Packet strategy.
Entity Direction Action

All Receive Send ArtPollReply.
Unicast Transmit Allowed, with Targeted Mode.
Directed Broadcast Controller broadcasts this packet to poll all
Controllers and Nodes on the network.
Limited Broadcast Not recommended.
The ArtPoll packet is used to discover the presence of other Controllers, Nodes and
Media Servers. The ArtPoll packet can be sent by any device, but is usually only sent by
the Controller. Both Controllers and Nodes respond to the packet.
A Controller broadcasts an ArtPoll packet to IP address 2.255.255.255 (sub-net mask

255.0.0.0) at UDP port 0x1936, this is the Directed Broadcast address.
The Controller may assume a maximum timeout of 3 seconds between sending ArtPoll
and receiving all ArtPollReply packets. If the Controller does not receive a response in
this time it should consider the Node to have disconnected.
The Controller that broadcasts an ArtPoll should also reply to its own message (by
unicast) with an ArtPollReply. 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.

Multiple Controllers
Art-Net allows and supports multiple controllers on a network. When there are multiple
controllers, Nodes will receive ArtPolls from different controllers which may contain
conflicting diagnostics requirements. This is resolved as follows:
If any controller requests diagnostics, the node will send diagnostics. (ArtPoll->Flags->2).
If there are multiple controllers requesting diagnostics, diagnostics shall be broadcast.

(Ignore ArtPoll->Flags->3).
The lowest minimum value of Priority shall be used. (Ignore ArtPoll->DiagPriority).
Targeted Mode
Targeted mode allows the ArtPoll to define a range of Port-Addresses. Nodes will only
reply to the ArtPoll is they are subscribed to a Port-Address that is inclusively in the
range TargetPortAddressBottom to TargetPortAddressTop. The bit field ArtPoll->Flags->5
is used to enable Targeted Mode.

ArtPoll packet definition
Field Name Size Bit Description
1 ID[8] Int8 - Array of 8 characters, the final character
is a null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int - The OpCode defines the class of data
16 following ArtPoll within this UDP packet.
Transmitted low byte first. See Table 1
for the OpCode listing.
Set to OpPoll.
3 ProtVerHi Int8 - High byte of the Art-Net protocol
revision number.
4 ProtVerLo Int8 - Low byte of the Art-Net protocol revision
number. Current value 14. Controllers
should ignore communication with
nodes using a protocol version lower
than 14.
5 Flags Int8 - Set behaviour of Node
7-6 Unused, transmit as zero, do not test
upon receipt.
5 0 = Disable Targeted Mode.
1 = Enable Targeted Mode.
4 0 = Enable VLC transmission.
1 = Disable VLC transmission.
3 0 = Diagnostics messages are broadcast.
(if bit 2).
1 = Diagnostics messages are unicast. (if
bit 2).
2 0 = Do not send me diagnostics
messages.
1 = Send me diagnostics messages.
1 0 = Only send ArtPollReply in response to
an ArtPoll or ArtAddress.
1 = Send ArtPollReply whenever Node
conditions change. This selection allows
the Controller to be informed of changes
without the need to continuously poll.
0 0 = Deprecated.
6 DiagPriority Int8 - The lowest priority of diagnostics
message that should be sent. See Table
5.
7 TargetPort Int8 - Top of the range of Port-Addresses to be
AddressTopHi tested if Targeted Mode is active.
8 TargetPort Int8 -
AddressTopLo
9 TargetPort Int8 - Bottom of the range of Port-Addresses
AddressBottomHi to be tested if Targeted Mode is active.
10 TargetPort Int8 -
AddressBottomLo

Table 1 - OpCodes:
The following table details the legal OpCode values used in Art-Net packets:
Opcodes
Name Value Definition
OpPoll 0x2000 This is an ArtPoll packet, no other data is contained
in this UDP packet.
OpPollReply 0x2100 This is an ArtPollReply Packet. It contains device
status information.
OpDiagData 0x2300 Diagnostics and data logging packet.
OpCommand 0x2400 Used to send text based parameter commands.
OpOutput / OpDmx 0x5000 This is an ArtDmx data packet. It contains zero start
code DMX512 information for a single Universe.
OpNzs 0x5100 This is an ArtNzs data packet. It contains non-zero
start code (except RDM) DMX512 information for a
single Universe.
OpSync 0x5200 This is an ArtSync data packet. It is used to force
synchronous transfer of ArtDmx packets to a node’s
output.
OpAddress 0x6000 This is an ArtAddress packet. It contains remote
programming information for a Node.
OpInput 0x7000 This is an ArtInput packet. It contains enable –
disable data for DMX inputs.
OpTodRequest 0x8000 This is an ArtTodRequest packet. It is used to request
a Table of Devices (ToD) for RDM discovery.
OpTodData 0x8100 This is an ArtTodData packet. It is used to send a
Table of Devices (ToD) for RDM discovery.
OpTodControl 0x8200 This is an ArtTodControl packet. It is used to send
RDM discovery control messages.
OpRdm 0x8300 This is an ArtRdm packet. It is used to send all non
discovery RDM messages.
OpRdmSub 0x8400 This is an ArtRdmSub packet. It is used to send
compressed, RDM Sub-Device data.
OpVideoSetup 0xa010 This is an ArtVideoSetup packet. It contains video
screen setup information for nodes that implement
the extended video features.

Opcodes
OpVideoPalette 0xa020 This is an ArtVideoPalette packet. It contains colour
palette setup information for nodes that implement
the extended video features.
OpVideoData 0xa040 This is an ArtVideoData packet. It contains display
data for nodes that implement the extended video
features.
OpMacMaster 0xf000 This packet is deprecated.
OpMacSlave 0xf100 This packet is deprecated.
OpFirmwareMaster 0xf200 This is an ArtFirmwareMaster packet. It is used to
upload new firmware or firmware extensions to the
Node.
OpFirmwareReply 0xf300 This is an ArtFirmwareReply packet. It is returned by
the node to acknowledge receipt of an
ArtFirmwareMaster packet or ArtFileTnMaster
packet.
OpFileTnMaster 0xf400 Uploads user file to node.
OpFileFnMaster 0xf500 Downloads user file from node.
OpFileFnReply 0xf600 Server to Node acknowledge for download packets.
OpIpProg 0xf800 This is an ArtIpProg packet. It is used to re-
programme the IP address and Mask of the Node.
OpIpProgReply 0xf900 This is an ArtIpProgReply packet. It is returned by the
node to acknowledge receipt of an ArtIpProg packet.
OpMedia 0x9000 This is an ArtMedia packet. It is Unicast by a Media
Server and acted upon by a Controller.
OpMediaPatch 0x9100 This is an ArtMediaPatch packet. It is Unicast by a
Controller and acted upon by a Media Server.
OpMediaControl 0x9200 This is an ArtMediaControl packet. It is Unicast by a
Controller and acted upon by a Media Server.
OpMediaContrlReply 0x9300 This is an ArtMediaControlReply packet. It is Unicast
by a Media Server and acted upon by a Controller.
OpTimeCode 0x9700 This is an ArtTimeCode packet. It is used to transport
time code over the network.
OpTimeSync 0x9800 Used to synchronise real time date and clock
OpTrigger 0x9900 Used to send trigger macros
OpDirectory 0x9a00 Requests a node's file list
OpDirectoryReply 0x9b00 Replies to OpDirectory with file list

Table 2 - OemCode:
The registered OEM codes are detailed in “Art-NetOemCodes.h” which is found in the
SDK directory of the DMX-Workshop installation.
The OEM code defines a specific manufacturer’s product type. The OemCode is returned
in the ArtPollReply.
Table 3 – NodeReport Codes:
The following table details the NodeReport codes. TheNodeReport code defines generic
error, advisory and status messages for both Nodes and Controllers. The NodeReport is
returned in ArtPollReply.
Code Mnemonic Description

0x0000 RcDebug Booted in debug mode (Only used in development)
0x0001 RcPowerOk Power On Tests successful
0x0002 RcPowerFail Hardware tests failed at Power On
0x0003 RcSocketWr1 Last UDP from Node failed due to truncated length,
Most likely caused by a collision.
0x0004 RcParseFail Unable to identify last UDP transmission. Check
OpCode and packet length.
0x0005 RcUdpFail Unable to open Udp Socket in last transmission
attempt
0x0006 RcShNameOk Confirms that Short Name programming via
ArtAddress, was successful.
0x0007 RcLoNameOk Confirms that Long Name programming via
ArtAddress, was successful.
0x0008 RcDmxError DMX512 receive errors detected.
0x0009 RcDmxUdpFull Ran out of internal DMX transmit buffers.
0x000a RcDmxRxFull Ran out of internal DMX Rx buffers.
0x000b RcSwitchErr Rx Universe switches conflict.
0x000c RcConfigErr Product configuration does not match firmware.
0x000d RcDmxShort DMX output short detected. See GoodOutput field.
0x000e RcFirmwareFail Last attempt to upload new firmware failed.
0x000f RcUserFail User changed switch settings when address locked by
remote programming. User changes ignored.
0x0010 RcFactoryRes Factory reset has occurred.
Table 4 – Style Codes:
The following table details the Style codes. The Style code defines the general
functionality of a Controller. The Style code is returned in ArtPollReply.

0x00 StNode A DMX to / from Art-Net device
0x01 StController A lighting console.
0x02 StMedia A Media Server.
0x03 StRoute A network routing device.
0x04 StBackup A backup device.
0x05 StConfig A configuration or diagnostic tool.
0x06 StVisual A visualiser.

ArtPollReply:
Packet strategy.

All Receive No Art-Net action.
devices Unicast Transmit Allowed.
Broadcast Not Allowed.
A device, in response to a Controller’s ArtPoll, sends the ArtPollReply. The device should
wait for a random delay of up to 1s before sending the reply. This mechanism is intended
to reduce packet bunching when scaling up to very large systems.
ArtPollReply packet definition

1 ID[8] Int8 - Array of 8 characters, the final character is a
null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpPollReply
Transmitted low byte first.
3 IP Address[4] Int8 - Array containing the Node’s IP address. First
array entry is most significant byte of
address. When binding is implemented,
bound nodes may share the root node’s IP
Address and the BindIndex is used to
differentiate the nodes.
4 Port Int16 - The Port is always 0x1936
5 VersInfoH Int8 - High byte of Node’s firmware revision
number. The Controller should only use this
field to decide if a firmware update should
proceed. The convention is that a higher
number is a more recent release of
firmware.
6 VersInfoL Int8 - Low byte of Node’s firmware revision
number.
7 NetSwitch Int8 - Bits 14-8 of the 15 bit Port-Address are

encoded into the bottom 7 bits of this field.
This is used in combination with SubSwitch
and SwIn[] or SwOut[] to produce the full
universe address.
8 SubSwitch Int8 - Bits 7-4 of the 15 bit Port-Address are
encoded into the bottom 4 bits of this field.
This is used in combination with NetSwitch
and SwIn[] or SwOut[] to produce the full
universe address.
9 OemHi Int8 - The high byte of the Oem value.
10 Oem Int8 - The low byte of the Oem value.
The Oem word describes the equipment
vendor and the feature set available. Bit 15
high indicates extended features available.
Current registered codes are defined in
Table 2.
11 Ubea Version Int8 - This field contains the firmware version of
the User Bios Extension Area (UBEA). If the
UBEA is not programmed, this field contains
zero.
12 Status1 Int8 - General Status register containing bit fields
as follows.
7-6 Indicator state.
00 Indicator state unknown.
01 Indicators in Locate / Identify
Mode.
10 Indicators in Mute Mode.
11 Indicators in Normal Mode.
5-4 Port-Address Programming Authority
00 Port-Address Programming
Authority unknown.
01 All Port-Address set by front panel
controls.
10 All or part of Port-Address
programmed by network or Web
browser.

11 Not used.
3 Not implemented, transmit as zero,
receivers do not test.
2 0 = Normal firmware boot (from flash).
Nodes that do not support dual boot, clear
this field to zero.
1 = Booted from ROM.
1 0 = Not capable of Remote Device
Management (RDM).
1 = Capable of Remote Device Management
(RDM).
0 0 = UBEA not present or corrupt
1 = UBEA present
13 EstaManLo Int8 - The ESTA manufacturer code. These codes
are used to represent equipment
manufacturer. They are assigned by ESTA.
This field can be interpreted as two ASCII
bytes representing the manufacturer initials.
14 EstaManHi Int8 - Hi byte of above
15 ShortName Int8 - The array represents a null terminated short
[18] name for the Node. The Controller uses the
ArtAddress packet to program this string.
Max length is 17 characters plus the null.
This is a fixed length field, although the
string it contains can be shorter than the
field.
16 LongName Int8 - The array represents a null terminated long
[64] name for the Node. The Controller uses the
ArtAddress packet to program this string.
Max length is 63 characters plus the null.
field.
17 NodeReport Int8 - The array is a textual report of the Node’s
[64] operating status or operational errors. It is
primarily intended for ‘engineering’ data
rather than ‘end user’ data. The field is
formatted as: “#xxxx [yyyy..] zzzzz…”
xxxx is a hex status code as defined in Table
3. yyyy is a decimal counter that increments
every time the Node sends an
ArtPollResponse.
This allows the controller to monitor event
changes in the Node.
zzzz is an English text string defining the
status.
field.
18 NumPortsHi Int8 - The high byte of the word describing the
number of input or output ports. The high
byte is for future expansion and is currently
zero.
19 NumPortsLo Int8 - The low byte of the word describing the
number of input or output ports. If number
of inputs is not equal to number of outputs,
the largest value is taken. Zero is a legal
value if no input or output ports are
implemented. The maximum value is 4.
Nodes can ignore this field as the
information is implicit in PortTypes[].
20 PortTypes [4] Int8 - This array defines the operation and
protocol of each channel. (A product with 4
inputs and 4 outputs would report 0xc0,
0xc0, 0xc0, 0xc0). The array length is fixed,
independent of the number of inputs or
outputs physically available on the Node.
7 Set is this channel can output data from the
Art-Net Network.
6 Set if this channel can input onto the Art-Net
Network.
5-0 000000 = DMX512
000001 = MIDI
000010 = Avab

000011 = Colortran CMX
000100 = ADB 62.5
000101 = Art-Net
000110 = DALI
21 GoodInput Int8 - This array defines input status of the node.
[4] 7 Set – Data received.
6 Set – Channel includes DMX512 test
packets.
5 Set – Channel includes DMX512 SIP’s.
4 Set – Channel includes DMX512 text
packets.
3 Set – Input is disabled.
2 Set – Receive errors detected.
1-0 Unused and transmitted as zero.
22 GoodOutput Int8 - This array defines output status of the node.
A [4] 7 Set – Data is being transmitted.
6 Set – Channel includes DMX512 test
packets.
5 Set – Channel includes DMX512 SIP’s.
4 Set – Channel includes DMX512 text
packets.
3 Set – Output is merging ArtNet data.
2 Set – DMX output short detected on power
up
1 Set – Merge Mode is LTP.
0 Set – Output is selected to transmit sACN.
Clr – Output is selected to transmit Art-Net.
23 SwIn [4] Int8 - Bits 3-0 of the 15 bit Port-Address for each
of the 4 possible input ports are encoded
into the low nibble.
24 SwOut [4] Int8 - Bits 3-0 of the 15 bit Port-Address for each
of the 4 possible output ports are encoded
into the low nibble.
25 AcnPriority Int8 - The sACN priority value that will be used
when any received DMX is converted to
sACN.

26 SwMacro Int8 - If the Node supports macro key inputs, this
byte represents the trigger values. The Node
is responsible for ‘debouncing’ inputs. When
the ArtPollReply is set to transmit
automatically, (Flags Bit 1), the ArtPollReply
will be sent on both key down and key up
events. However, the Controller should not
assume that only one bit position has
changed.
The Macro inputs are used for remote event
triggering or cueing.
Bit fields are active high.
7 Set – Macro 8 active.
27 SwRemote Int8 - If the Node supports remote trigger inputs,
this byte represents the trigger values. The
Node is responsible for ‘debouncing’ inputs.
When the ArtPollReply is set to transmit
automatically, (Flags Bit 1), the ArtPollReply
will be sent on both key down and key up
events. However, the Controller should not
assume that only one bit position has
changed.
The Remote inputs are used for remote
event triggering or cueing.
Bit fields are active high.
7 Set – Remote 8 active.
28 Spare Int8 Not used, set to zero
31 Style Int8 The Style code defines the equipment style
of the device. See Table 4 for current Style
codes.
32 MAC Hi Int8 MAC Address Hi Byte. Set to zero if node
cannot supply this information.
33 MAC Int8 MAC Address
37 MAC Lo Int8 MAC Address Lo Byte
38 BindIp[4] Int8 If this unit is part of a larger or modular
product, this is the IP of the root device.
39 BindIndex Int8 This number represents the order of bound
devices. A lower number means closer to
root device. A value of 1 means root device.
40 Status2 Int8 0 Set = Product supports web browser
configuration.
1 Clr = Node’s IP is manually configured.
Set = Node’s IP is DHCP configured.
2 Clr = Node is not DHCP capable.
Set = Node is DHCP capable.
3 Clr = Node supports 8-bit Port-Address (Art-
Net II).
Set = Node supports 15-bit Port-Address
(Art-Net 3 or 4).
4 Clr = Node not able to switch between Art-
Net and sACN.
Set = Node is able to switch between Art-
Net and sACN.
5 Clr = Not squawking.

Set = squawking.
6 Clr = Node does not support switching of
output style using ArtAddress.
Set = Node supports switching of output
style using ArtAddress.
7 Clr = Node does not support control of RDM
using ArtAddress.
Set = Node supports control of RDM using
ArtAddress.
41 GoodOutput Int8 - This array defines output status of the node.
B [4] 7 Set – RDM is disabled.
Clr – RDM is enabled.
6 Set – Output style is continuous
Clr – Output style is delta.
5 Not used, set to zero
42 Status3 Int8 - General Status register containing bit fields
as follows.
7-6 Failsafe state. How the node behaves in the
event that network data is lost.
00 Hold last state.
01 All outputs to zero.
10 All outputs to full.
11 Playback fail safe scene.
5 Set – Node supports fail-over.
Clr – Node does not support fail-over.
4 Set – Node supports LLRP.
Clr – Node does not support LLRP.
3 Set – Node supports switching ports
between input and output. (PortTypes[]
shows the current direction)
Clr – Node does not support switching port

direction.
43 DefaulRespUID Int8 RDMnet & LLRP Default Responder UID MSB
Hi
44 DefaulRespUID Int8 RDMnet & LLRP Default Responder UID
48 DefaulRespUID Int8 RDMnet & LLRP Default Responder UID LSB
Lo
49 Filler 15 x 8 Transmit as zero. For future expansion.

ArtIpProg:
Packet strategy.

Controller Receive No Action.
Unicast Transmit Controller transmits to a specific node IP address.
Node Receive Reply with ArtIpProgReply.
Unicast Transmit Not Allowed.
Media Receive Reply with ArtIpProgReply.
Server Unicast Transmit Not Allowed.
The ArtIpProg packet allows the IP settings of a Node to be reprogrammed.
The ArtIpProg packet is sent by a Controller to the private address of a Node. If the Node
supports remote programming of IP address, it will respond with an ArtIpProgReply
packet. In all scenarios, the ArtIpProgReply is sent to the private address of the sender.
ArtIpProg packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpIpProg
3 ProtVerHi Int8 - High byte of the Art-Net protocol revision
number.
number. Current value 14
5 Filler1 Int8 - Pad length to match ArtPoll.
7 Command Int8 - Action this packet as follows:
- Defines the how this packet is processed. If all

bits are clear, this is an enquiry only.
7 Set to enable any programming.
6 Set to enable DHCP (if set ignore lower bits).
5 Not used, transmit as zero
4 Program Default gateway
3 Set to return all three parameters to default
2 Program IP Address
1 Program Subnet Mask
0 Program Port
8 Filler4 Int8 Set to zero. Pads data structure for word
alignment.
9 ProgIpHi Int8 IP Address to be programmed into Node if
enabled by Command Field
10 ProgIp2 Int8
11 ProgIp1 Int8
12 ProgIpLo Int8
13 ProgSmHi Int8 Subnet mask to be programmed into Node if
enabled by Command Field
14 ProgSm2 Int8
15 ProgSm1 Int8
16 ProgSmLo Int8
17 ProgPortHi Int8 (Deprecated)
18 ProgPortLo Int8
19 ProgDgHi Int8 Default Gateway to be programmed into Node
if enabled by Command Field
20 ProgDg2 Int8
21 ProgDg1 Int8
22 ProgDgLo Int8
23-26 Spare4-8 Int8 Transmit as zero, receivers don’t test.

ArtIpProgReply:
Packet strategy.

Node Receive No Action.
Unicast Transmit Transmits to specific Controller IP address.
Media Receive No Action
Server Unicast Transmit Transmits to specific Controller IP address.
The ArtIpProgReply packet is issued by a Node in response to an ArtIpProg packet. Nodes
that do not support remote programming of IP address do not reply to ArtIpProg
packets. In all scenarios, the ArtIpProgReply is sent to the private address of the sender.
ArtIpProgReply packet definition

Field Name Size Description
1 ID[8] Int8 Array of 8 characters, the final character is a null
termination. Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpIpProgReply Transmitted low byte first.
3 ProtVerHi Int8 High byte of the Art-Net protocol revision number.
4 ProtVerLo Int8 Low byte of the Art-Net protocol revision number. (14)
5 Filler1 Int8 Pad length to match ArtPoll.
7 Filler3 Int8 Pad length to match ArtIpProg.
8 Filler4 Int8 Pad length to match ArtIpProg.
9 ProgIpHi Int8 IP Address of Node.
10 ProgIp2 Int8
11 ProgIp1 Int8
12 ProgIpLo Int8
13 ProgSmHi Int8 Subnet mask of Node.
14 ProgSm2 Int8

15 ProgSm1 Int8
16 ProgSmLo Int8
17 ProgPort Hi Int8 (Deprecated).
18 ProgPort Lo Int8
19 Status Int8 Bit 7 0
Bit 6 DHCP enabled.
Bit 5-0 0
20 Spare2 Int8 Transmit as zero, receivers don’t test.
21 ProgDgHi Int8 Default Gateway of Node.
22 ProgDg2 Int8
23 ProgDg1 Int8
24 ProgDgLo Int8

ArtAddress:
Packet strategy.

Node Receive Reply by unicasting ArtPollReply.
Media Receive Reply by unicasting ArtPollReply.
A Controller or monitoring device on the network can reprogram numerous controls of a
node remotely. This, for example, would allow the lighting console to re-route DMX512
data at remote locations. This is achieved by sending an ArtAddress packet to the Node’s
IP address. (The IP address is returned in the ArtPoll packet). The node replies with an
ArtPollReply packet.
Fields 5 to 13 contain the data that will be programmed into the node.
ArtAddress packet definition

termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpAddress
4 ProtVerLo Int8 Low byte of the Art-Net protocol revision number.
Current value 14
5 NetSwitch Int8 Bits 14-8 of the 15 bit Port-Address are encoded into
the bottom 7 bits of this field. This is used in
combination with SubSwitch and SwIn[] or SwOut[] to

produce the full universe address.
This value is ignored unless bit 7 is high. i.e. to
program a value 0x07, send the value as 0x87.
Send 0x00 to reset this value to the physical switch
setting.
6 BindIndex Int8 The BindIndex defines the bound node which
originated this packet and is used to uniquely identify
the bound node when identical IP addresses are in
use. This number represents the order of bound
devices. A lower number means closer to root device.
A value of 1 means root device.
7 Short Name Int8 The array represents a null terminated short name for
[18] the Node. The Controller uses the ArtAddress packet
to program this string. Max length is 17 characters
plus the null. The Node will ignore this value if the
string is null.
This is a fixed length field, although the string it
contains can be shorter than the field.
8 Long Name Int8 The array represents a null terminated long name for
[64] the Node. The Controller uses the ArtAddress packet
to program this string. Max length is 63 characters
plus the null. The Node will ignore this value if the
string is null.
This is a fixed length field, although the string it
contains can be shorter than the field.
9 SwIn [4] Int8 Bits 3-0 of the 15 bit Port-Address for a given input
port are encoded into the bottom 4 bits of this field.
This is used in combination with NetSwitch and
SubSwitch to produce the full universe address.
setting.
10 SwOut [4] Int8 Bits 3-0 of the 15 bit Port-Address for a given output
port are encoded into the bottom 4 bits of this field.
This is used in combination with NetSwitch and
SubSwitch to produce the full universe address.

setting.
11 SubSwitch Int8 Bits 7-4 of the 15 bit Port-Address are encoded into
the bottom 4 bits of this field. This is used in
combination with NetSwitch and SwIn[] or SwOut[] to
produce the full universe address.
setting.
12 AcnPriority Int8 Sets the sACN Priority field for sACN generated on all 4
ports encoded into this packet. A value of 255
represents no change. Values of 0 to 200 inclusive are
valid.
13 Command Int8 Node configuration commands:
Val Mnemonic Action
0x00 AcNone No action
0x01 AcCancel Merge If Node is currently in
merge mode, cancel
merge mode upon receipt
of next ArtDmx packet.
See discussion of merge
mode operation.
0x02 AcLedNormal The front panel indicators
of the Node operate
normally.
0x03 AcLedMute The front panel indicators
of the Node are disabled
and switched off.
0x04 AcLedLocate Rapid flashing of the
Node’s front panel
indicators. It is intended as
an outlet identifier for
large installations.
0x05 AcResetRx Flags Resets the Node’s Sip,

Text, Test and data error
flags.
If an output short is being
flagged, forces the test to
re-run.
0x06 AcAnalysisOn Enable analysis and
debugging mode.
0x07 AcAnalysisOff Disable analysis and
debugging mode.
Failsafe configuration commands: These settings
should be retained by the node during power cycling.
0x08 AcFailHold Set the node to hold last
state in the event of loss
of network data.
0x09 AcFailZero Set the node’s outputs to
zero in the event of loss of
network data.
0x0a AcFailFull Set the node’s outputs to
full in the event of loss of
network data.
0x0b AcFailScene Set the node’s outputs to
play the failsafescene in
the event of loss of
network data.
0x0c AcFailRecord Record the current output
state as the failsafescene.
Node configuration commands: Note that Ltp / Htp
settings should be retained by the node during power
cycling.
0x10 AcMergeLtp0 Set DMX Port 0 to Merge
in LTP mode.
in LTP mode.
in LTP mode.
in LTP mode.
0x20 AcDirectionTx0 Set Port0 direction to
Output.
Output.
Output.
Output.
0x30 AcDirectionRx0 Set Port0 direction to
Input.
Input.
Input.
Input.
0x50 AcMergeHtp0 Set DMX Port 0 to Merge
in HTP (default) mode.
0x60 AcArtNetSel0 Set DMX Port 0 to output
both DMX512 and RDM
packets from the Art-Net
protocol (default).
both DMX512 and RDM
protocol (default).
both DMX512 and RDM
protocol (default).

both DMX512 and RDM
protocol (default).
0x70 AcAcnSel0 Set DMX Port 0 to output
DMX512 data from the
sACN protocol and RDM
data from the Art-Net
protocol.
protocol.
protocol.
protocol.
0x90 AcClearOp0 Clear DMX Output buffer
for Port 0
for Port 1
for Port 2
for Port 3
0xa0 AcStyleDelta0 Set output style to delta
mode (DMX frame
triggered by ArtDmx) for
Port 0

mode (DMX frame
Port 1
mode (DMX frame
Port 2
mode (DMX frame
Port 3
0xb0 AcStyleConst0 Set output style to
constant mode (DMX
output is continuous) for
Port 0
constant mode (DMX
Port 1
constant mode (DMX
Port 2
constant mode (DMX
Port 3
0xc0 AcRdmEnable0 Enable RDM for Port 0
0xd0 AcRdmDisable0 Disable RDM for Port 0

ArtDiagData:
Packet strategy.

Controller Receive Application Specific.
Unicast Transmit As defined by ArtPoll.
Broadcast As defined by ArtPoll.
Node Receive No Action
Unicast Transmit As defined by ArtPoll.
Media Receive No Action
Server Unicast Transmit As defined by ArtPoll.
ArtDiagData is a general purpose packet that allows a node or controller to send
diagnostics data for display.
The ArtPoll packet sent by controllers defines the destination to which these messages
should be sent.
ArtDiagData packet definition

ArtDiagData
null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpDiagData, transmitted low byte first.
3 ProtVerHi Int8 - High byte of the Art-Net protocol revision.
5 Filler1 Int8 - Ignore by receiver, set to zero by sender.
6 DiagPriority Int8 - The priority of this diagnostic data. See Table 5.
7 LogicalPort Int8 - The logical DMX port of the product to which
the message relates. Set to zero for general
messages. This field if purely informational and

ArtDiagData
is designed to allow development tools to filter
diagnostics.
9 LengthHi Int8 - The length of the text array below. High Byte.
10 LengthLo Int8 - Low Byte.
11 Data Int8 - ASCII text array, null terminated. Max length is
[Length] 512 bytes including the null terminator.
Table 5 – Priority Codes:
The following table details the Diagnostics Priority codes. These are used in ArtPoll and
ArtDiagData.

0x10 DpLow Low priority message.
0x40 DpMed Medium priority message.
0x80 DpHigh High priority message.
0xe0 DpCritical Critical priority message.
0xf0 DpVolatile Volatile message. Messages of this type are displayed
on a single line in the DMX-Workshop diagnostics
display. All other types are displayed in a list box.

ArtTimeCode:
Packet strategy.

Unicast Transmit Application Specific.
Broadcast Application Specific.
Node Receive Application Specific.
Media Receive Application Specific.
Server Unicast Transmit Application Specific.
ArtTimeCode allows time code to be transported over the network. The data format is
compatible with both longitudinal time code and MIDI time code. The four key types of
Film, EBU, Drop Frame and SMPTE are also encoded.
Use of the packet is application specific but in general a single controller will broadcast
the packet to the network.
ArtTimeCode packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpTimeCode
number.
7 Frames Int8 - Frames time. 0 – 29 depending on mode.

8 Seconds Int8 - Seconds. 0 - 59.
9 Minutes Int8 - Minutes. 0 - 59.
10 Hours Int8 - Hours. 0 - 23.
11 Type Int8 - 0 = Film (24fps)
1 = EBU (25fps)
2 = DF (29.97fps)
3 = SMPTE (30fps)

ArtCommand:
Packet strategy.

The ArtCommand packet is used to send property set style commands. The packet can be
unicast or broadcast, the decision being application specific.
ArtCommand packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpCommand
number.
5 EstaManHi Int8 - The ESTA manufacturer code. These codes are
used to represent equipment manufacturer.
They are assigned by ESTA. This field can be
interpreted as two ASCII bytes representing the
manufacturer initials.
6 EstaManLo Int8 - Hi byte of above
7 LengthHi Int8 - The length of the text array below. High Byte.
8 LengthLo Int8 - Low Byte.

9 Data Int8 - ASCII text command string, null terminated.
[Length] Max length is 512 bytes including the null term.
The Data field contains the command text. The text is ASCII encoded and is null
terminated and is case insensitive. It is legal, although inefficient, to set the Data array
size to the maximum of 512 and null pad unused entries.
The command text may contain multiple commands and adheres to the following syntax:
Command=Data&
The ampersand is a break between commands. Also note that the text is capitalised for
readability; it is case insensitive.
Thus far, two commands are defined by Art-Net. It is anticipated that additional
commands will be added as other manufacturers register commands which have
industry wide relevance.
These commands shall be transmitted with EstaMan = 0xFFFF.
Table 6 – ArtCommand Commands:
The following table details the commands defined for use in ArtCommand.
Command Description
SwoutText This command is used to re-programme the label
associated with the ArtPollReply->Swout fields.
Syntax: "SwoutText=Playback&"
SwinText This command is used to re-programme the label
associated with the ArtPollReply->Swin fields.
Syntax: "SwinText=Record&"

ArtTrigger:
Packet strategy.

The ArtTrigger packet is used to send trigger macros to the network. The most common
implementation involves a single controller broadcasting to all other devices.
In some circumstances a controller may only wish to trigger a single device or a small
group in which case unicast would be used.
ArtTrigger packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpTrigger , transmitted low byte first.
number.
7 OemCodeHi Int8 - The manufacturer code (high byte) of nodes
that shall accept this trigger.
8 OemCodeLo Int8 - The manufacturer code (low byte) of nodes

that shall accept this trigger.
9 Key Int8 - The Trigger Key.
10 SubKey Int8 - The Trigger SubKey.
11 Data [512] Int8[] - The interpretation of the payload is defined by
the Key.
Key
The Key is an 8-bit number which defines the purpose of the packet. The interpretation
of this field is dependent upon the Oem field. If the Oem field is set to a value other than
0xffff then the Key and SubKey fields are manufacturer specific.
However, when the Oem field = 0xffff the meaning of the Key, SubKey and Payload is
defined by Table 7.
Table 7 – ArtTrigger Key Values.
The following table details the commands defined for use in ArtCommand.
Key Name Purpose

0 KeyAscii The SubKey field contains an ASCII character which the
receiving device should process as if it were a keyboard
press. (Payload not used).
1 KeyMacro The SubKey field contains the number of a Macro which
the receiving device should execute. (Payload not used).
2 KeySoft The SubKey field contains a soft-key number which the
receiving device should process as if it were a soft-key
keyboard press. (Payload not used).
3 KeyShow The SubKey field contains the number of a Show which
the receiving device should run. (Payload not used).
4-255 Undefined Undefined
SubKey
The SubKey is an 8-bit number. The interpretation of this field is dependent upon the
Oem field. If the Oem field is set to a value other than ffff16 then the Key and SubKey
fields are manufacturer specific.

However, when the Oem field = ffff16 the meaning of the SubKey field is defined by the
table above.

Payload
The Payload is a fixed length array of 512, 8-bit bytes. The interpretation of this field is
dependent upon the Oem field. If the Oem field is set to a value other than 0xffff then
the Payload is manufacturer specific.

ArtDmx:
Packet strategy.

Unicast Transmit Yes.
Broadcast No.
Broadcast No.
Server Unicast Transmit Yes.
Broadcast No.
ArtDmx is the data packet used to transfer DMX512 data. The format is identical for
Node to Controller, Node to Node and Controller to Node.
The Data is output through the DMX O/P port corresponding to the Universe setting. In
the absence of received ArtDmx packets, each DMX O/P port re-transmits the same
frame continuously.
The first complete DMX frame received at each input port is placed in an ArtDmx packet
as above and transmitted as an ArtDmx packet containing the relevant Universe
parameter. Each subsequent DMX frame containing new data (different length or
different contents) is also transmitted as an ArtDmx packet.
Nodes do not transmit ArtDmx for DMX512 inputs that have not received data since
power on.
However, an input that is active but not changing, will re-transmit the last valid ArtDmx
packet at approximately 4-second intervals. (Note. In order to converge the needs of Art-
Net and sACN it is recommended that Art-Net devices actually use a re-transmit time of
800mS to 1000mS).
A DMX input that fails will not continue to transmit ArtDmx data.
Unicast Subscription:
ArtDmx packets must be unicast to subscribers of the specific universe contained in the
ArtDmx packet.
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. Subscribed means any universes listed in either the Swin or
Swout array.
If there are no subscribers to a universe, the controller shall not send ArtDmx. There are
no conditions in which broadcast is allowed.
ArtDmx packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpOutput
number.
5 Sequence Int8 - The sequence number is used to ensure that
ArtDmx packets are used in the correct order.
When Art-Net is carried over a medium such as
the Internet, it is possible that ArtDmx packets
will reach the receiver out of order.
This field is incremented in the range 0x01 to
0xff to allow the receiving node to re-sequence
packets.
The Sequence field is set to 0x00 to disable this
feature.
6 Physical Int8 - The physical input port from which DMX512
data was input. This field is used by the

receiving device to discriminate between
packets with identical Port-Address that have
been generated by different input ports and so
need to be merged.
7 SubUni Int8 - The low byte of the 15 bit Port-Address to
which this packet is destined.
8 Net Int8 - The top 7 bits of the 15 bit Port-Address to
9 LengthHi Int8 - The length of the DMX512 data array. This
value should be an even number in the range 2
– 512.
It represents the number of DMX512 channels
encoded in packet. NB: Products which convert
Art-Net to DMX512 may opt to always send 512
channels.
High Byte.
10 Length Int8 - Low Byte of above.
11 Data Int8 - A variable length array of DMX512 lighting
[Length] data.
Refresh Rate:
The ArtDmx packet is intended to transfer DMX512 data. For this reason, the ArtDmx
packet for a specific IP Address should not be transmitted at a repeat rate faster than the
maximum repeat rate of a DMX packet containing 512 data slots.
Synchronous Data:
In video or media-wall applications, the ability to synchronise multiple universes of

ArtDmx is beneficial. This can be achieved with the ArtSync packet.
Data Merging:
The Art-Net protocol allows multiple nodes or controllers to transmit ArtDmx data to the
same universe.

A node can detect this situation by comparing the IP addresses of received ArtDmx
packets. If ArtDmx packets addressed to the same Port-Address are received from
different IP addresses (or different Physical ports on the same IP address), a potential
conflict exists.
The Node can legitimately handle this situation using one of two methods:
• Consider this to be an error condition and await user intervention.
• Automatically merge the data.
Nodes should document the approach that is implemented in the product user guide.
The Merge option is preferred as it provides a higher level of functionality.
Merge is implemented in either LTP or HTP mode as specified by the ArtAddress packet.
Merge mode is implemented as follows:
If ArtDmx with identical Port-Address is received from differing IP addresses, the

data is merged to the DMX output. In this situation, ArtPollReply-GoodOutput-
Bit3 is set. If Art-Poll-Flags Bit 1 is set, an ArtPollReply should be transmitted
when merging commences.
If ArtDmx with identical Port-Address is received from identical IP addresses but

differing Physical fields, the data is merged to the DMX output. In this situation,
ArtPollReply-GoodOutput-Bit3 is set. If Art-Poll-Flags Bit 1 is set, an ArtPollReply
should be transmitted when merging commences.
Exit from Merge mode is handled as follows:
If ArtAddress AcCancelMerge is received, the Next ArtDmx message received

ends Merge mode. The Node then discards any ArtDmx packets received from
an IP address that does not match the IP address of the ArtDmx packet that
terminated Merge mode.

If either (but not both) sources of ArtDmx stop, the failed source is held in the
merge buffer for 10 seconds. If, during the 10 second timeout, the failed source
returns, Merge mode continues. If the failed source does not recover, at the
end of the timeout period, the Node exits Merge mode.
If both sources of ArtDmx fail, the output holds the last merge result.
Merging is limited to two sources, any additional sources will be ignored by the Node.
The Merge implementation allows for the following two key modes of operation.
• Combined Control: Two Controllers (Consoles) can operate on a network and

merge data to multiple Nodes.
• Backup: One Controller (Console) can monitor the network for a failure of the
primary Controller. If a failure occurs, it can use the ArtAddress AcCancelMerge
command to take instant control of the network.
When a node provides multiple DMX512 inputs, it is the responsibility of the Node to
handle merging of data. This is because the Node will have only one IP address. If this
were not handled at the Node, ArtDmx packets with identical IP addresses and identical
universe numbers, but conflicting level data would be transmitted to the network.
ArtSync:
Packet strategy.

Controller Receive No action.
Directed Broadcast Controller broadcasts this packet to synchronously
transfer previous ArtDmx packets to Node’s
output.
Node Receive Transfer previous ArtDmx packets to output.
Media Receive Transfer previous ArtDmx packets to output.
The ArtSync packet can be used to force nodes to synchronously output ArtDmx packets
to their outputs. This is useful in video and media-wall applications.
A controller that wishes to implement synchronous transmission will unicast multiple

universes of ArtDmx and then broadcast an ArtSync to synchronously transfer all the
ArtDmx packets to the nodes’ outputs at the same time.
Managing Synchronous and non-Synchronous modes
At power on or reset a node shall operate in non-synchronous mode. This means that
ArtDmx packets will be immediately processed and output.
When a node receives an ArtSync packet it should transfer to synchronous operation.

This means that received ArtDmx packets will be buffered and output when the next
ArtSync is received.
In order to allow transition between synchronous and non-synchronous modes, a node

shall time out to non-synchronous operation if an ArtSync is not received for 4 seconds
or more.
ArtSync packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - The OpCode defines the class of data within
this UDP packet.
Transmitted low byte first. See Table 1 for the
OpCode listing.
Set to OpSync.

number.
number. Current value 14. Controllers should
ignore communication with nodes using a
protocol version lower than 14.
5 Aux1 Int8 - Transmit as zero.
6 Aux2 Int8 - Transmit as zero.
Multiple controllers
In order to allow for multiple controllers on a network, a node shall compare the source
IP of the ArtSync to the source IP of the most recent ArtDmx packet. The ArtSync shall be
ignored if the IP addresses do not match.
When a port is merging multiple streams of ArtDmx from different IP addresses, ArtSync
packets shall be ignored.

ArtNzs:
Packet strategy.

Broadcast No.
Broadcast No.
Server Unicast Transmit Yes.
Broadcast No.
ArtNzs is the data packet used to transfer DMX512 data with non-zero start codes
(except RDM). The format is identical for Node to Controller, Node to Node and
Controller to Node.
ArtNzs packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpNzs
number.
ArtNzs packets are used in the correct order.
the Internet, it is possible that ArtNzs packets
0xff to allow the receiving node to resequence
packets.
feature.
6 StartCode Int8 - The DMX512 start code of this packet. Must not
be Zero or RDM.
9 LengthHi Int8 - The length of the data array. This value should
be a number in the range 1 – 512.
encoded in packet.
High Byte.
11 Data Int8 - A variable length array of DMX512 lighting
[Length] data.

ArtVlc:
ArtVlc is a specific implementation of the ArtNzs packet which is used for the transfer of
VLC (Visible Light Communication) data over Art-Net. (The packet’s payload can also be
used to transfer VLC over a DMX512 physical layer).
Fields 2, 6, 11, 12 and 13 should be treated as ‘magic numbers’ to detect this packet.
ArtVlc packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpNzs
number.
ArtNzs packets are used in the correct order.
the Internet, it is possible that ArtNzs packets
0xff to allow the receiving node to resequence
packets.
feature.
6 StartCode Int8 - The DMX512 start code of this packet is set to
9116. No other values are allowed.
9 LengthHi Int8 - The length of the Vlc data array. This value

should be in the range 1 – 512.
encoded in packet.
High Byte.
11 Vlc [Length] - A variable length array of VLC data as described
below:
11 Vlc[0] Int8 - 4116 Magic number used to identify this packet.
ManIdHi
12 Vlc[1] Int8 - 4C16 Magic number used to identify this packet.
ManIdLo
13 Vlc[2] Int8 - 4516 Magic number used to identify this packet.
SubCode
14 Vlc[3] Int8 Bit fields used to control VLC operation. Bits
Flags that are unused shall be transmitted as zero.
Flags.Ieee 7 If set, data in the payload area shall be
interpreted as IEEE VLC data.
If clear, PayLanguage defines the payload
contents.
Flags.Reply 6 If set this is a reply packet that is in response to
the request sent with matching number in the
transaction number: TransHi/Lo.
If clear this is not a reply.
Flags.Beacon 5 If set, the transmitter should continuously
repeat transmission of this packet until another
is received.
If clear, the transmitter should transmit this
packet once.
15 Vlc[4] Int8 - The transaction number is a 16-bit value which
TransHi allows VLC transactions to be synchronised. A
value of 0 indicates the first packet in a
transaction. A value of ffff16 indicates the final
packet in the transaction. All other packets
contain consecutive numbers which increment
on each packet and roll over to 1 at fffe16.
16 Vlc[5] Int8 - Lo byte of above
TransLo

17 Vlc[6] Int8 - The slot number, range 1-512, of the device to
SlotAddrHi which this packet is directed. A value 0f 0
indicates that all devices attached to this
packet’s Port-Address should accept the
packet.
SlotAddrLo
19 Vlc[8] Int8 - The 16-bit payload size in the range 0 to 48010.
PayCountHi
PayCountLo
21 Vlc[10] Int8 - The 16-bit unsigned additive checksum of the
PayCheckHi data in the payload.
PayCheckLo
23 Vlc[12] Int8 - Transmit as zero, receive does not check.
Spare1
24 Vlc[13] Int8 - The 8-bit VLC modulation depth expressed as a
VlcDepth percentage in the range 1 to 100. A value of 0
indicates that the transmitter should use its
default value
25 Vlc[14] Int8 - The 16-bit modulation frequency of the VLC
VlcFreqHi transmitter expressed in Hz. A value of 0
indicates that the transmitter should use its
default value.
VlcFreqLo
27 Vlc[16] Int8 - The 16-bit modulation type number that the
VlcModHi transmitter should use to transmit VLC.
000016 – Use transmitter default.

VlcModLo
29 Vlc[18] Int8 - The 16-bit payload language code. Currently
PayLangHi registered values:
000016 – BeaconURL – Payload contains a
simple text string representing a URL.
000116 – BeaconText – Payload contains a
simple ASCII text message.
000216 – BeaconLocationID – Payload contains
a big-endian 16-bit number.
PayLangLo
31 Vlc[20] Int8 - The 16-bit beacon mode repeat frequency. If
BeacRepHi Flags.Beacon is set, this 16-bit value indicates
the frequency in Hertz at which the VLC packet
should be repeated.
000016 – Use transmitter default.

BeacRepLo
33 Vlc[22] Var - The actual VLC payload.
Payload

ArtInput:
Packet strategy.

Node Receive Reply with ArtPollReply.
Media Receive Reply with ArtPollReply.
A Controller or monitoring device on the network can enable or disable individual
DMX512 inputs on any of the network nodes. This allows the Controller to directly
control network traffic and ensures that unused inputs are disabled and therefore not
wasting bandwidth.
All nodes power on with all inputs enabled.
Caution should be exercised when implementing this function in the controller. Keep in
mind that some network traffic may be operating on a node to node basis.
ArtInput packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpInput
number.

6 BindIndex Int8 - The BindIndex defines the bound node which
originated this packet and is used to uniquely
identify the bound node when identical IP
addresses are in use. This number represents
the order of bound devices. A lower number
means closer to root device. A value of 1
means root device.
7 NumPortsHi Int8 - The high byte of the word describing the
number of input or output ports. The high
byte is for future expansion and is currently
zero.
8 NumPortsL Int8 - The low byte of the word describing the
o number of input or output ports. If number of
inputs is not equal to number of outputs, the
largest value is taken. The maximum value is
4.
9 Input [4] Int8 - This array defines input disable status of each
channel. (Example = 0x01, 0x00, 0x01, 0x00
to disable first and third inputs)
7-1 Not currently used
0 Set to disable this input.

Firmware and UBEA upgrades:
This section defines the packets used to send firmware revisions to a node. In all
instances, communication is private. Under no circumstances should the broadcast
address be used.
The transaction involves the controller sending multiple ArtFirmwareMaster packets to a

Node’s IP address. Each packet is acknowledged by the Node with an ArtFirmwareReply.
The controller allows a 30 second maximum delay for reception of the

ArtFirmwareReply.
If the reply is not received in this time, the controller aborts the transaction. The large
time period is to allow for Nodes that are writing directly to slow non-volatile memory.
The Node allows a 30 second delay between sending an ArtFirmwareReply and receipt of
the next consecutive ArtFirmwareMaster. If the next consecutive block is not received
within this time, the Node aborts the transaction. In this instance the Node returns to its
previous operating system and sets ArtPollReply->Status and ArtPollReply ->NodeReport
accordingly.
The firmware update file contains a header that defines the Node OEM values that are
valid for this update. The Controller must check this value before sending to a Node. The
Node also checks this data on receipt of the first packet. If the Node receives a packet
with an invalid code, it sends an error response.
The UBEA is the User Bios Expansion Area. This is a limited firmware upload mechanism
that allows third party firmware extensions to be added to a Node.
Manufacturers who implement this feature must document the software interface
requirements.

ArtFirmwareMaster:
Packet strategy.

Node Receive Reply with OpFirmwareReply.
Media Receive Reply with OpFirmwareReply.
ArtFirmwareMaster packet definition
null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpFirmwareMaster.
number.
7 Type Int8 - Defines the packet contents as follows:
Value Mnemonic Function
0x00 FirmFirst The first packet of a
firmware upload.
0x01 FirmCont A consecutive
continuation packet of
a firmware upload.
0x02 FirmLast The last packet of a
firmware upload.

0x03 UbeaFirst The first packet of a
UBEA upload.
0x04 UbeaCont A consecutive
continuation packet of
a UBEA upload.
0x05 UbeaLast The last packet of a
UBEA upload.
8 BlockId Int8 - Counts the consecutive blocks of firmware
upload. Starting at 0x00 for the FirmFirst or
UbeaFirst packet.
9 Firmware Int8 - This Int64 parameter describes the total
Length3 number of words (Int16) in the firmware
upload plus the firmware header size. Eg a 32K
word upload plus 530 words of header
information == 0x00008212. This value is also
the file size (in words) of the file to be
uploaded.
10 Firmware Int8 -
Length2
11 Firmware Int8 -
Length1
12 Firmware Int8 - LSB
Length0
13 Spare[20] Int8 - Controller sets to zero, Node does not test.
14 Data[512] Int16 - This array contains the firmware or UBEA data
block. The order is hi byte first. The
interpretation of this data is manufacturer
specific. Final packet should be null packed if
less than 512 bytes needed.

ArtFirmwareReply:
Packet strategy.

Controller Receive Send next OpFirmwareMaster.
Unicast Transmit Node transmits to a specific Controller IP address.
Media Receive No Action.
Server Unicast Transmit Node transmits to a specific Controller IP address.
This packet is sent by the Node to the Controller in acknowledgement of each
OpFirmwareMaster packet.
ArtFirmwareReply packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpFirmwareReply.
number.
7 Type Int8 - Defines the packet contents as follows. Codes
are used for both firmware and UBEA.
0x00 FirmBlockGood Last packet
received
successfully.

0x01 FirmAll Good All firmware
received
successfully.
0xff FirmFail Firmware upload
failed. (All error
conditions).
8 Spare[21] Int8 - Node sets to zero, Controller does not test.
Firmware File Format:
All firmware and UBEA upload files should be of the following format.
The firmware file extension is .alf.
The UBEA file extension is .alu.
Byte Name Description

1 ChecksumHi This is a 16 bit, one’s-complement checksum of the
firmware data area.
2 ChecksumLo LSB of above
3 VersInfoHi High byte of Node’s firmware revision number. The
Controller should only use this field to decide if a
firmware update should proceed. The convention is that
a higher number is a more recent release of firmware.
4 VersInfoLo LSB of above
5-34 UserName 30 byte field of user name information. This information
is not checked by the Node. It is purely for display by the
Controller. It should contain a human readable
description of file and version number. Whilst this is a
fixed length field, it must contain a null termination.
35- Oem[256] An array of 256 words. Each word is hi byte first and
546 represents an Oem code for which this file is valid.
Unused entries must be filled with 0x0000.
547- Spare[255] An array of 255 words. Currently unused and should be
1056 set to zero.

Byte Name Description
1057 Length3 The total length in words of the firmware information
following this field.
1058 Length2
1059 Length1
1060 Length0 LSB
1061 Data[] The firmware data as an array of 16 bit values ordered
hi byte first. The actual data is manufacturer specific.

RDM Support:
This section defines the packet structure used to gate the Remote Device Management
(RDM) protocol across Art-Net. It is assumed that the reader is familiar with the RDM
document.
Art-Net devices support RDM as follows:
• All RDM discovery commands are proxied; Art-Net devices hold local RDM
device lists and conduct their own discovery.
• All RDM Get / Set commands are non-proxied; they are passed to end devices
for response.
This document defines the following terms:
Input Gateway: A device that inputs DMX512 onto the Art-Net network (e.g. Art-Lynx
IP).
Output Gateway: A device that outputs DMX512 from the Art-Net network (e.g. Art-
Lynx OP)
Table of Devices (TOD): The list of RDM devices maintained by both Input and Output
Gateways.
RDM Discovery
Output Gateway Operation
Output Gateways perform RDM discovery independent of network operation. This

includes full discovery upon power-on and incremental discovery as a background task.
The Output Gateway informs the network about its TOD as follows:
Upon receipt of an ArtTodRequest packet, the Output Gateways Directed Broadcast an

ArtTodData packet containing the entire TOD. All Input Gateways parse the ArtTodData

packets. If the Sub-Net and Universe fields match, the Input Gateway adds the TOD
contents to their own internal TOD. This allows Input Gateways to respond to any
physical layer RDM discovery commands they receive.
Upon completion of initial RDM discovery, Output Gateways Directed Broadcast their
TOD in an ArtTodData packet.
When an RDM device is added to or removed from the Output Gateway’s TOD (during
incremental discovery), an ArtTodData packet is broadcast automatically.
Input Gateway Operation
Input Gateways generate a TOD by monitoring Art-Net traffic. The TOD is then used to
reply to RDM discovery commands by proxy. Operation is as follows:
Upon power-on, Input Gateways Directed Broadcast an ArtTodRequest packet.
The network is monitored for ArtTodData packets. If the Sub-Net and Universe fields
match, the Input Gateway adds the TOD contents to its own internal TOD. This allows
Input Gateways to respond to any RDM discovery commands they receive.
Input Gateways do not transmit any RDM discovery messages to the network.
Controller Operation:
Controllers emulate the operation of Input Gateways.

ArtTodRequest:
This packet is used to request the Table of RDM Devices (TOD). A Node receiving this
packet must not interpret it as forcing full discovery. Full discovery is only initiated at
power on or when an ArtTodControl.AtcFlush is received. The response is ArtTodData.
Packet strategy.

Unicast Not Allowed.
Transmit
Broadcast Controller Directed Broadcasts to all nodes.
Node Receive Reply with ArtTodData.
Output Unicast Not Allowed.
Gateway Transmit
Node Input Receive No Action.
Gateway Unicast Not Allowed.
Transmit
Broadcast Input Gateway Directed Broadcasts to all nodes.
Server Unicast Not Allowed.
Transmit
ArtTodRequest packet definition

null termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 - OpTodRequest.
number.
7 Spare1 Int8 - Transmit as zero, receivers don’t test.
14 Net Int8 - The top 7 bits of the 15 bit Port-Address of
Nodes that must respond to this packet.
15 Command Int8 - Value Mnemonic Function
0x00 TodFull Send the
entire TOD.
16 AddCount Int8 - The number of entries in Address that are used.
Max value is 32.
17 Address Int8 - This array defines the low byte of the Port-
[32] Address of the Output Gateway nodes that
must respond to this packet. This is combined
with the 'Net' field above to form the 15 bit
address.

ArtTodData:
Packet strategy.

Unicast Not Allowed.
Transmit
Gateway Transmit
Broadcast Output Gateway always Directed Broadcasts this
packet.
Transmit
Transmit
ArtTodData packet definition

termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpTodData.
Current value 14
5 RdmVer Int8 Art-Net Devices that only support RDM DRAFT V1.0
set field to 0x00. Devices that support RDM
STANDARD V1.0 set field to 0x01.

6 Port Int8 Physical port index. Range 1-4. This number is used
in combination with BindIndex to identify the
physical port that generated the packet. This is done
by referencing data in the ArtPollReply with a
matching BindIndex:
ArtPollReplyData->BindIndex == ArtTodData-
>BindIndex
An ArtPollReply can encode between 1 and 4

physical ports, defined by ArtPollReply-
>NumPortsLo. This number must be used when
calculating the physical port in order to allow for the
variable encoding.
The calculation is:
Physical Port = (BindIndex-1) * ArtPollReply-

>NumPortsLo + ArtTodData->Port
As most modern Art-Net gateways implement one
universe per ArtPollReply, ArtTodData->Port will
usually be set to a value of 1.

13 BindIndex Int8 The BindIndex defines the bound node which
originated this packet. In combination with Port and
Source IP address, it uniquely identifies the sender.
This must match the BindIndex field in ArtPollReply.
This number represents the order of bound devices.
A lower number means closer to root device. A value

of 1 means root device.
14 Net Int8 The top 7 bits of the Port-Address of the Output
Gateway DMX Port that generated this packet.
15 Command Int8 Defines the packet contents as follows.
Response
Valu Mnemonic Function
e
0x00 TodFull The packet contains the entire
TOD or is the first packet in a
sequence of packets that
contains the entire TOD.
0xff TodNak The TOD is not available or
discovery is incomplete.
16 Address Int8 The low 8 bits of the Port-Address of the Output
Gateway DMX Port that generated this packet. The
high nibble is the Sub-Net switch. The low nibble
corresponds to the Universe.
17 UidTotalHi Int8 The total number of RDM devices discovered by this
Universe.
18 UidTotalLo Int8
19 BlockCount Int8 The index number of this packet. When UidTotal
exceeds 200, multiple ArtTodData packets are used.
BlockCount is set to zero for the first packet and
incremented for each subsequent packet containing
blocks of TOD information.
20 UidCount Int8 The number of UIDs encoded in this packet. This is
the index of the following array.
21 ToD 48 bit An array of RDM UID.
[UidCount]

ArtTodControl:
Packet strategy.

Unicast Allowed.
Transmit
Broadcast Controller Directed Broadcasts to all nodes.
Node Receive Reply with ArtTodData.
Gateway Transmit
Transmit
Broadcast Input Gateway Directed Broadcasts to all nodes.
Transmit
The ArtTodControl packet is used to send RDM control parameters over Art-Net. The
response is ArtTodData.
ArtTodControl packet definition

termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpTodControl.
Current value 14

14 Net Int8 The top 7 bits of the Port-Address of the Output
Gateway DMX Port that should action this command.
15 Command Int8 Defines the packet action.
0x00 AtcNone No action.
0x01 AtcFlush The node flushes its TOD
and instigates full
discovery.
16 Address Int8 The low byte of the 15 bit Port-Address of the DMX
Port that should action this command.

ArtRdm:
Packet strategy.

Unicast Yes.
Transmit
Broadcast Not allowed.
Output Unicast Yes.
Gateway Transmit
Gateway Unicast Yes.
Transmit
Server Unicast Yes.
Transmit
The ArtRdm packet is used to transport all non-discovery RDM messages over Art-Net.
ArtRdm packet definition

termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpRdm.
Current value 14
5 RdmVer Int8 Art-Net Devices that only support RDM DRAFT V1.0 set
field to 0x00. Devices that support RDM STANDARD
V1.0 set field to 0x01.

14 Net Int8 The top 7 bits of 15 bit Port-Address that should action
this command.
15 Command Int8 Defines the packet action.
0x00 ArProcess Process RDM Packet.
16 Address Int8 The low 8 bits of the Port-Address that should action
this command.
17 RdmPacket Int8 The RDM data packet excluding the DMX StartCode.
[Vari]

ArtRdmSub:
Packet strategy.

Output Unicast Transmit Yes.
Gateway Broadcast Not allowed.
Gateway Unicast Transmit Yes.
The ArtRdmSub packet is used to transfer Get, Set, GetResponse and SetResponse data
to and from multiple sub-devices within an RDM device. This packet is primarily used by
Art-Net devices that proxy or emulate RDM. It offers very significant bandwidth gains
over the approach of sending multiple ArtRdm packets.
Please note that this packet was added at the release of Art-Net II. For backwards
compatibility it is only acceptable to implement this packet in addition to ArtRdm. It
must not be used instead of ArtRdm.
ArtRdmSub packet definition

ArtRdmSub
termination.
Value = ‘A’ ‘r’ ‘t’ ‘-‘ ‘N’ ‘e’ ‘t’ 0x00
2 OpCode Int16 OpRdmSub.
3 ProtVerHi Int8 High byte of the Art-Net protocol revision

ArtRdmSub
number.
4 ProtVerLo Int8 Low byte of the Art-Net protocol revision
5 RdmVer Int8 Art-Net Devices that only support RDM DRAFT
V1.0 set field to 0x00. Devices that support RDM
STANDARD V1.0 set field to 0x01.
6 Filler2 Int8 Transmit as zero, receivers don’t test.
7 UID Int8[6] UID of target RDM device.
9 CommandClass Int8 As per RDM specification. This field defines
whether this is a Get, Set, GetResponse,
SetResponse.
10 ParameterId Int16 As per RDM specification. This field defines the
type of parameter contained in this packet. Big-
endian.
11 SubDevice Int16 Defines the first device information contained in
packet. This follows the RDM convention that 0 =
root device and 1 = first subdevice. Big-endian.
12 SubCount Int16 The number of sub devices packed into packet.
Zero is illegal. Big-endian.
17 Data Int16 Packed 16-bit big-endian data. The size of the
[Vari] data array is defined by the contents of
CommandClass and SubCount:
CommandClass Array Size
Get 0
Set SubCount
GetResponse SubCount
SetResponse 0

Display of status:
Most Art-Net compliant equipment will provide some level of status indication. The
following format is suggested:
Name Mnemonic Function

Power Pow Normally on, flashes if fault detected.
Communication Com On if any Art-Net packets detected on
network, timeout after 6 seconds.
DMX512 DMX x DMX On if good DMX received,
Input Flashing if errors detected.
Alternative Start Codes are not
errors!
DMX On if receiving ArtDmx for this
Output output. Timeout after 6 seconds.
Data Integrity:
Art-Net receivers should check one item:
Compare the ID[8] field

© Artistic Licence. 1998-2022
E: Support@ArtisticLicence.com
W: http://www.ArtisticLicence.com
W: www.Art-Net.info
Please note that whilst the Art-Net SDK, Art-Net View & DMX-Workshop are free of charge, they are not
‘freeware’ and remain copyright Artistic Licence. It is not to be included in commercial products or made
available by Internet without the express written permission of Artistic Licence.
The information contained in this document is subject to change without notice. Artistic Licence. makes no
warranty of any kind with regard to this material, including, but not limited to, the implied warranties of fitness
for a particular purpose.
Artistic Licence shall not be liable for errors contained herein or for incidental or consequential damages in
connection with the furnishing, performance or use of this material.
All trademarks are acknowledged.

Art Net

Uploaded by

Copyright:

Available Formats

Art Net

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Art Net

Uploaded by

Copyright:

Available Formats

Art-Net 4

Specification for the Art-Net 4 Ethernet Communication Protocol

Winner of the PLASA 2016 Innovation Award

Comments on Revisions AJ-BD: .................................................................................. - 1 -

Comments on Revision BE: ......................................................................................... - 1 -

Comments on Revision BF: ......................................................................................... - 1 -

Comments on Revision BG: ........................................................................................ - 1 -

Comments on Revision BH: ........................................................................................ - 1 -

Comments on Revision BI: .......................................................................................... - 2 -

Comments on Revision BJ:.......................................................................................... - 2 -

Comments on Revision BK: ......................................................................................... - 2 -

Comments on Revision DA: ........................................................................................ - 2 -

Comments on Revision DB: ........................................................................................ - 2 -

Comments on Revision DC: ........................................................................................ - 2 -

Comments on Revision DD: ........................................................................................ - 2 -

Comments on Revision DE: ......................................................................................... - 2 -

Art-Net overview: ........................................................................................................... - 5 -

Universe Addressing: .................................................................................................. - 7 -

Subnet Mask ........................................................................................................... - 9 -

Limited Broadcast ................................................................................................... - 9 -

Media Server ........................................................................................................... - 9 -

Ethernet Implementation: ............................................................................................ - 10 -

General Notes: .......................................................................................................... - 10 -

Protocol Operation ................................................................................................... - 10 -

IP address configuration ........................................................................................... - 10 -

IP address configuration - DHCP ........................................................................... - 11 -

IP address configuration – Static Addressing ........................................................ - 11 -

IP address Example ............................................................................................... - 12 -

Art-Net packet definition .............................................................................................. - 14 -

Multiple Controllers .............................................................................................. - 15 -

Targeted Mode ..................................................................................................... - 15 -

ArtPoll packet definition ....................................................................................... - 16 -

Table 1 - OpCodes: ................................................................................................ - 18 -

Table 3 – NodeReport Codes: ............................................................................... - 20 -

Table 4 – Style Codes: ........................................................................................... - 21 -

ArtPollReply packet definition .............................................................................. - 22 -

ArtIpProg packet definition ................................................................................... - 31 -

ArtIpProgReply packet definition .......................................................................... - 33 -

ArtAddress packet definition ................................................................................ - 35 -

ArtDiagData packet definition .............................................................................. - 42 -

Table 5 – Priority Codes: ....................................................................................... - 43 -

ArtTimeCode packet definition ............................................................................. - 44 -

ArtCommand packet definition............................................................................. - 46 -

Table 6 – ArtCommand Commands: ..................................................................... - 47 -

ArtTrigger packet definition .................................................................................. - 48 -

Table 7 – ArtTrigger Key Values. ........................................................................... - 49 -

Unicast Subscription: ............................................................................................ - 54 -

ArtDmx packet definition ...................................................................................... - 54 -

Refresh Rate: ......................................................................................................... - 55 -

Synchronous Data: ................................................................................................ - 55 -

Data Merging: ....................................................................................................... - 55 -

Managing Synchronous and non-Synchronous modes ......................................... - 58 -

ArtSync packet definition ...................................................................................... - 58 -

Multiple controllers .............................................................................................. - 59 -

ArtNzs packet definition ....................................................................................... - 60 -

ArtVlc packet definition ........................................................................................ - 62 -

ArtInput packet definition ..................................................................................... - 66 -

Firmware and UBEA upgrades: ..................................................................................... - 68 -

ArtFirmwareMaster packet definition .................................................................. - 69 -