Art-Net - Artistic Licenceartisticlicence.com/WebSiteMaster/User Guides/art-net.pdf · Art-Net 4...

Art-Net 4

Specification for the Art-Net 4 Ethernet Communication Protocol

www.Art-Net.org.uk

Winner of the PLASA 2016 Innovation Award

http://www.art-net.org.uk/

© Copyright Artistic Licence Holdings Ltd 1998-2017

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 Holdings Ltd. The Art-Net protocol and

associated documentation is copyright Artistic Licence Holdings Ltd. Any third parties are

welcome to use this communication protocol without royalty. Please see section on

credits for details of copyright message.

Artistic Licence Holdings Ltd politely request that any manufacturer who implements this

protocol apply for an OemCode at the following link: www.art-net.org.uk/?page_id=203

http://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 -

Art-Net overview: ............................................................................................................ - 3 -

Art-Net 4: .................................................................................................................... - 3 -

Universe Addressing: .................................................................................................. - 5 -

Credits: ........................................................................................................................ - 6 -

Terminology: ............................................................................................................... - 6 -

Node ........................................................................................................................ - 6 -

Port-Address ........................................................................................................... - 6 -

Net .......................................................................................................................... - 6 -

Sub-Net ................................................................................................................... - 6 -

Universe .................................................................................................................. - 6 -

Kiloverse .................................................................................................................. - 6 -

Controller ................................................................................................................ - 7 -

IP ............................................................................................................................. - 7 -

Subnet Mask ........................................................................................................... - 7 -

Port ......................................................................................................................... - 7 -

Directed Broadcast .................................................................................................. - 7 -

Limited Broadcast ................................................................................................... - 7 -

Controller ................................................................................................................ - 7 -

Media Server ........................................................................................................... - 7 -

Ethernet Implementation: .............................................................................................. - 8 -

General Notes: ............................................................................................................ - 8 -

Protocol Operation ..................................................................................................... - 8 -

IP address configuration ............................................................................................. - 8 -

IP address configuration - DHCP ............................................................................. - 9 -

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

IP address Example ............................................................................................... - 10 -

Controller Default Poll .............................................................................................. - 11 -

Network Topology: ................................................................................................... - 11 -

Peer to Peer .......................................................................................................... - 11 -

Controller to Peer.................................................................................................. - 11 -

Art-Net packet definition .............................................................................................. - 12 -

ArtPoll: ...................................................................................................................... - 12 -

Multiple Controllers .............................................................................................. - 13 -

ArtPoll packet definition ....................................................................................... - 14 -

Table 1 - OpCodes: ................................................................................................ - 15 -

Table 2 - OemCode: ............................................................................................... - 17 -

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

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

ArtPollReply: ............................................................................................................. - 19 -

ArtPollReply packet definition .............................................................................. - 19 -

ArtIpProg: ................................................................................................................. - 26 -

ArtIpProg packet definition ................................................................................... - 26 -

ArtIpProgReply: ........................................................................................................ - 28 -

ArtIpProgReply packet definition .......................................................................... - 28 -

ArtAddress: ............................................................................................................... - 30 -

ArtAddress packet definition ................................................................................ - 30 -

ArtDiagData: ............................................................................................................. - 35 -

ArtDiagData packet definition............................................................................... - 35 -

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

ArtTimeCode: ............................................................................................................ - 37 -

ArtTimeCode packet definition ............................................................................. - 37 -

ArtCommand: ........................................................................................................... - 39 -

ArtCommand packet definition ............................................................................. - 39 -

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

ArtTrigger: ................................................................................................................. - 41 -

ArtTrigger packet definition .................................................................................. - 41 -

Key......................................................................................................................... - 42 -

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

SubKey................................................................................................................... - 42 -

Payload .................................................................................................................. - 44 -

ArtDmx: ..................................................................................................................... - 45 -

Unicast Subscription: ............................................................................................ - 47 -

ArtDmx packet definition ...................................................................................... - 47 -

Refresh Rate: ......................................................................................................... - 48 -

Synchronous Data: ................................................................................................ - 48 -

Data Merging: ....................................................................................................... - 48 -

ArtSync: .................................................................................................................... - 50 -

Managing Synchronous and non-Synchronous modes ......................................... - 51 -

ArtSync packet definition ...................................................................................... - 51 -

Multiple controllers............................................................................................... - 51 -

ArtNzs: ...................................................................................................................... - 53 -

ArtNzs packet definition........................................................................................ - 53 -

ArtVlc: ....................................................................................................................... - 55 -

ArtVlc packet definition ........................................................................................ - 55 -

ArtInput: ................................................................................................................... - 59 -

ArtInput packet definition ..................................................................................... - 59 -

Firmware and UBEA upgrades: ..................................................................................... - 61 -

ArtFirmwareMaster: ................................................................................................. - 62 -

ArtFirmwareMaster packet definition .................................................................. - 62 -

ArtFirmwareReply: .................................................................................................... - 64 -

ArtFirmwareReply packet definition ..................................................................... - 64 -

Firmware File Format: ........................................................................................... - 65 -

RDM Support: ............................................................................................................... - 67 -

Input Gateway ....................................................................................................... - 67 -

Output Gateway .................................................................................................... - 67 -

Table of Devices (TOD): ......................................................................................... - 67 -

RDM Discovery.......................................................................................................... - 67 -

Output Gateway Operation .................................................................................. - 67 -

Input Gateway Operation ..................................................................................... - 68 -

Controller Operation: ............................................................................................ - 68 -

ArtTodRequest: ......................................................................................................... - 69 -

ArtTodRequest packet definition .......................................................................... - 69 -

ArtTodData: .............................................................................................................. - 71 -

ArtTodData packet definition................................................................................ - 71 -

ArtTodControl: .......................................................................................................... - 74 -

ArtTodControl packet definition ........................................................................... - 74 -

ArtRdm: .................................................................................................................... - 76 -

ArtRdm packet definition ...................................................................................... - 76 -

ArtRdmSub: .............................................................................................................. - 78 -

ArtRdmSub packet definition ................................................................................ - 78 -

Display of status: ........................................................................................................... - 80 -

Data Integrity: ............................................................................................................... - 80 -

Art-Net 4 Protocol Release V1.4 Document Revision 1.4dd 22/1/2017 - 1 -

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.

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.


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

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 Holdings Ltd".

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.


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


IP Address A.B.C.D Subnet Mask

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

Network Topology:

Art-Net allows two network topologies to operate simultaneously:

Peer to Peer: This is an unmanaged network where multiple Nodes transfer data

without the intervention of a controller. All data transfer uses ArtDmx packets. All data is

Directed Broadcast. This is the power on mode of operation for all Art-Net compliant

nodes designed to receive DMX512.

Controller to Peer: This is the most sophisticated implementation whereby one or

more Nodes communicate with one or more central controllers (lighting consoles). This

mode of operation data transfer operates by unicast transmission of ArtDmx packets.


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

Controller Receive Send ArtPollReply.

Unicast Transmit Not Allowed.

Directed Broadcast Controller broadcasts this packet to poll all Controllers and Nodes on the network.

Node Receive Send ArtPollReply.


Broadcast Not Allowed.

Media Server

Receive Send ArtPollReply.



The ArtPoll packet is used to discover the presence of other Controllers, Nodes and

Media Servers. The ArtPoll packet is only sent by a 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 (to

Directed Broadcast address) with an ArtPollReply. This ensures that any other Controllers

listening to the network will detect all devices without the need for all Controllers

connected to the network to send ArtPoll packets. 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->TalkToMe-

>2).

If there are multiple controllers requesting diagnostics, diagnostics shall be broadcast.

(Ignore ArtPoll->TalkToMe->3).

The lowest minimum value of Priority shall be used. (Ignore ArtPoll->Priority).


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 16 - The OpCode defines the class of data 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 TalkToMe Int8 - Set behaviour of Node

7-5 Unused, transmit as zero, do not test upon receipt.

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 Priority Int8 - The lowest priority of diagnostics message that should be sent. See Table 5.


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 devices

Receive No Art-Net action.

Unicast Transmit Not allowed.

Broadcast Directed Broadcasts this packet in response to an ArtPoll.

A device, in response to a Controller’s ArtPoll, sends the ArtPollReply. This packet is also

broadcast to the Directed Broadcast address by all Art-Net devices on power up.

ArtPollReply packet definition



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 Transmitted low byte first.

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 [18]

Int8 - The array represents a null terminated short 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 [64]

Int8 - The array represents a null terminated long name for the Node. The Controller uses the ArtAddress packet to program this string. Max length is 63 characters plus the null. This is a fixed length field, although the string it contains can be shorter than the field.

17 NodeReport [64]

Int8 - The array is a textual report of the Node’s 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. This is a fixed length field, although the string it contains can be shorter than the 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

21 GoodInput [4]

Int8 - This array defines input status of the node.

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 [4]

Int8 - This array defines output status of the node.

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 SwVideo Int8 - Set to 00 when video display is showing local data. Set to 01 when video is showing ethernet data. The field is now deprecated

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, (TalkToMe 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, (TalkToMe 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.

41 Filler 26 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.



Media Server

Receive Reply with ArtIpProgReply.



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



2 OpCode Int16 - OpIpProg Transmitted low byte first.


4 ProtVerLo Int8 - Low byte of the Art-Net protocol revision 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-4 Not used, transmit as zero

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-26 Spare1-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 Server

Receive No Action

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.








ArtAddress:

Packet strategy.





Node Receive Reply by broadcasting ArtPollReply.



Media Server

Receive Reply by broadcasting 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



2 OpCode Int16 OpAddress Transmitted low byte first.


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. Use value 0x7f for no change.

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 [18]

Int8 The array represents a null terminated short name for 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 [64]

Int8 The array represents a null terminated long name for 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. 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. Use value 0x7f for no change.

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. 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. Use value 0x7f for no change.

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. 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. Use value 0x7f for no change.

12 SwVideo Int8 Reserved.

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.

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.




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).


0x62 AcArtNetSel2 Set DMX Port 2 to output both DMX512 and RDM packets from the Art-Net



protocol (default).


0x70 AcAcnSel0 Set DMX Port 0 to output DMX512 data from the sACN protocol and RDM data from the Art-Net protocol.




0x90 AcClearOp0 Clear DMX Output buffer 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



Media Server

Receive No Action



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



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 Priority Int8 - The priority of this diagnostic data. See Table 5.



9 LengthHi Int8 - The length of the text array below. High Byte.


ArtDiagData

10 LengthLo Int8 - Low Byte.

11 Data [Length]

Int8 - ASCII text array, null terminated. Max length is 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 Server

Receive 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



2 OpCode Int16 - OpTimeCode Transmitted low byte first.





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.








Media Server




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



2 OpCode Int16 - OpCommand Transmitted low byte first.



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 [Length]

Int8 - ASCII text command string, null terminated. 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.








Media Server




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



2 OpCode Int16 - OpTrigger , transmitted low byte first.





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.

Media Server



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 that the transmitter wishes to send, then the

ArtDmx must not be broadcast. If the number of universe subscribers exceeds 40 for a

given universe, the transmitting device may broadcast.

ArtDmx packet definition



2 OpCode Int16 - OpOutput Transmitted low byte first.



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 resequence 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 for information only. Use Universe for data routing.

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 which this packet is destined.

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 [Length]

Int8 - A variable length array of DMX512 lighting 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 Universe are received from different IP

addresses, 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 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-

TalkToMe 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 Server

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



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.


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 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.

Media Server



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



2 OpCode Int16 - OpNzs Transmitted low byte first.



5 Sequence Int8 - The sequence number is used to ensure that ArtNzs packets are used in the correct order. When Art-Net is carried over a medium such as the Internet, it is possible that ArtNzs packets



will reach the receiver out of order. This field is incremented in the range 0x01 to 0xff to allow the receiving node to resequence packets. The Sequence field is set to 0x00 to disable this 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. It represents the number of DMX512 channels encoded in packet. High Byte.


11 Data [Length]

Int8 - A variable length array of DMX512 lighting 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



2 OpCode Int16 - OpNzs Transmitted low byte first.



5 Sequence Int8 - The sequence number is used to ensure that ArtNzs packets are used in the correct order. When Art-Net is carried over a medium such as the Internet, it is possible that ArtNzs packets will reach the receiver out of order. This field is incremented in the range 0x01 to 0xff to allow the receiving node to resequence packets. The Sequence field is set to 0x00 to disable this 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. It represents the number of DMX512 channels encoded in packet. High Byte.


11 Vlc [Length] - A variable length array of VLC data as described below:

11 Vlc[0] ManIdHi

Int8 - 4116 Magic number used to identify this packet.

12 Vlc[1] ManIdLo

Int8 - 4C16 Magic number used to identify this packet.

13 Vlc[2] SubCode

Int8 - 4516 Magic number used to identify this packet.

14 Vlc[3] Flags

Int8 Bit fields used to control VLC operation. Bits 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] TransHi

Int8 - The transaction number is a 16-bit value which 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] TransLo

Int8 - Lo byte of above



17 Vlc[6] SlotAddrHi

Int8 - The slot number, range 1-512, of the device to which this packet is directed. A value 0f 0 indicates that all devices attached to this packet’s Port-Address should accept the packet.

18 Vlc[7] SlotAddrLo


19 Vlc[8] PayCountHi

Int8 - The 16-bit payload size in the range 0 to 48010.

20 Vlc[9] PayCountLo


21 Vlc[10] PayCheckHi

Int8 - The 16-bit unsigned additive checksum of the data in the payload.

22 Vlc[11] PayCheckLo


23 Vlc[12] Spare1

Int8 - Transmit as zero, receive does not check.

24 Vlc[13] VlcDepth

Int8 - The 8-bit VLC modulation depth expressed as a percentage in the range 1 to 100. A value of 0 indicates that the transmitter should use its default value

25 Vlc[14] VlcFreqHi

Int8 - The 16-bit modulation frequency of the VLC transmitter expressed in Hz. A value of 0 indicates that the transmitter should use its default value.

26 Vlc[15] VlcFreqLo


27 Vlc[16] VlcModHi

Int8 - The 16-bit modulation type number that the transmitter should use to transmit VLC. 000016 – Use transmitter default.

28 Vlc[17] VlcModLo


29 Vlc[18] PayLangHi

Int8 - The 16-bit payload language code. Currently registered values:

000016 – BeaconURL – Payload contains a simple text string representing a URL.



000116 – BeaconText – Payload contains a simple ASCII text message.

30 Vlc[19] PayLangLo


31 Vlc[20] BeacRepHi

Int8 - The 16-bit beacon mode repeat frequency. If 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.

32 Vlc[21] BeacRepLo


33 Vlc[22] Payload

Var - The actual VLC payload.


ArtInput:

Packet strategy.





Node Receive Reply with ArtPollReply.



Media Server

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



2 OpCode Int16 - OpInput Transmitted low byte first.






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 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. 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 Server

Receive Reply with OpFirmwareReply.



ArtFirmwareMaster packet definition



2 OpCode Int16 - OpFirmwareMaster. Transmitted low byte first.





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 Length3

Int8 - This Int64 parameter describes the total 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 Length2

Int8 -

11 Firmware Length1

Int8 -

12 Firmware Length0

Int8 - LSB

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.



Node Receive No Action.

Unicast Transmit Node transmits to a specific Controller IP address.


Media Server

Receive No Action.

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



2 OpCode Int16 - OpFirmwareReply. Transmitted low byte first.





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-546 Oem[256] An array of 256 words. Each word is hi byte first and represents an Oem code for which this file is valid. Unused entries must be filled with 0x0000.

547-1056

Spare[255] An array of 255 words. Currently unused and should be 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 Transmit

Not Allowed.

Broadcast Controller Directed Broadcasts to all nodes.

Node Output Gateway

Receive Reply with ArtTodData.

Unicast Transmit

Not Allowed.


Node Input Gateway

Receive No Action.

Unicast Transmit

Not Allowed.

Broadcast Input Gateway Directed Broadcasts to all nodes.

Media Server

Receive No Action.

Unicast Transmit

Not Allowed.


ArtTodRequest packet definition



2 OpCode Int16 - OpTodRequest. Transmitted low byte first.







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 [32]

Int8 - This array defines the low byte of the Port-Address of the Output Gateway nodes that must respond to this packet. The high nibble is the Sub-Net switch. The low nibble corresponds to the Universe. This is combined with the 'Net' field above to form the 15 bit address.


ArtTodData:

Packet strategy.



Unicast Transmit

Not Allowed.


Node Output Gateway

Receive No Action.

Unicast Transmit

Not Allowed.

Broadcast Output Gateway always Directed Broadcasts this packet.

Node Input Gateway

Receive No Action.

Unicast Transmit

Not Allowed.


Media Server

Receive No Action.

Unicast Transmit

Not Allowed.


ArtTodData packet definition



2 OpCode Int16 OpTodData. Transmitted low byte first.



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. Range 1-4.







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 Response

Int8 Defines the packet contents as follows.


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 [UidCount]

48 bit An array of RDM UID.


ArtTodControl:

Packet strategy.



Unicast Transmit

Allowed.

Broadcast Controller Directed Broadcasts to all nodes.

Node Output Gateway

Receive Reply with ArtTodData.

Unicast Transmit

Not Allowed.


Node Input Gateway

Receive No Action.

Unicast Transmit

Not Allowed.

Broadcast Input Gateway Directed Broadcasts to all nodes.

Media Server

Receive No Action.

Unicast Transmit

Not Allowed.


The ArtTodControl packet is used to send RDM control parameters over Art-Net. The

response is ArtTodData.

ArtTodControl packet definition



2 OpCode Int16 OpTodControl. Transmitted low byte first.














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 Transmit

Allowed – Preferred.

Broadcast Allowed.

Node Output Gateway

Receive No Action

Unicast Transmit

Allowed - Preferred.

Broadcast Allowed.

Node Input Gateway

Receive No Action.

Unicast Transmit


Broadcast Allowed.

Media Server

Receive No Action.

Unicast Transmit


Broadcast Allowed.

The ArtRdm packet is used to transport all non-discovery RDM messages over Art-Net.

ArtRdm packet definition



2 OpCode Int16 OpRdm. Transmitted low byte first.














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 [Vari]

The RDM data packet excluding the DMX StartCode.


ArtRdmSub:

Packet strategy.




Broadcast Not allowed.

Node Output Gateway

Receive No Action



Node Input Gateway

Receive No Action.



Media Server

Receive No Action.



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



2 OpCode Int16 OpRdmSub. Transmitted low byte first.

3 ProtVerHi Int8 High byte of the Art-Net protocol revision


ArtRdmSub

number.



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 [Vari]

Packed 16-bit big-endian data. The size of the 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 Input

On if good DMX received, Flashing if errors detected. Alternative Start Codes are not errors!

DMX Output

On if receiving ArtDmx for this output. Timeout after 6 seconds.

Data Integrity:

Art-Net receivers should check one item:

Compare the ID[8] field

© Artistic Licence Holdings Ltd. 1998-2015

Studio 1 Spectrum House 32-34 Gordon House Road London NW5 1LP

Tel: +44 (0)20 88 63 45 15

Fax: +44 (0)20 84 26 05 51

E: [email protected]

W: http://www.ArtisticLicence.com

W: www.Art-Net.org.uk

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 Holdings Ltd. It is not to be included in commercial products or

made available by Internet without the express written permission of Artistic Licence Holdings Ltd.

The information contained in this document is subject to change without notice. Artistic Licence Holdings Ltd.

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 Holdings Ltd. 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.

mailto:[email protected]

http://www.artisticlicence.com/

http://www.art-net.org.uk/

Art-Net - Artistic Licenceartisticlicence.com/WebSiteMaster/User Guides/art-net.pdf · Art-Net 4...

Documents

Transcript of Art-Net - Artistic Licenceartisticlicence.com/WebSiteMaster/User Guides/art-net.pdf · Art-Net 4...