ESTA E1.30-4 PDF

Reaffirmed in 2015

Introductory Discussion 

DMX512 In the years since its introduction in 1986, USITT DMX512 (often referred to as DMX512 or just DMX) has spread from its initial remit of providing simple level control to dimmers, to control of a huge range of devices. The most recent standard specification is DMX512-A [DMX512]. Because the semantics of controlling anything except dimmers are outside the scope of any of the DMX512 specifications, there is no standard way to arrange control of other items. However, other DMX512 devices are prevalent throughout the lighting industry and are characterized by a wide range of control styles and methods.

Versions of DMX512, E1.31 and DMX512 over Ethernet Protocols

The first standard for DMX512 was published in 1986. Subsequent standards have updated this and ESTA has developed a protocol for transport of DMX512 data over IP networks contained in the E1.31 standard [E1.31]. There are also a number of proprietary protocols in use that perform a similar function of transporting DMX512 data over Ethernet or other media. All these standards share the same NULL START Code data format and the syntax described here is intended to work with the latest standard DMX512-A, and also with earlier versions of DMX512, with E1.31 and with any other protocol which uses DMX512 NULL START Code data format. For this reason, the term DMX512 is used within this document to refer to any such protocol as applicable. When specific versions of protocols are referenced then the terms DMX512-A, DMX512/1990, DMX512-1986, E1.31 are used ([DMX512-A], [DMX512/1990], [DMX512-1986], [E1.31]).

DDL

Device Description Language [DDL] provides a rich and extensible way to describe a wide range of controllable devices, and maintains a separation between the device model which it describes as a structure of properties, and the access protocol which is used to access some of those properties remotely. It provides the <protocol> element that allows any necessary extension for describing how the properties of the device model are accessed using any given protocol. This EPI defines the syntax of the protocol element used to describe DMX512 access to properties.

Multiple Interfaces

Historically, a DMX512 device (as opposed to a controller) usually had a single DMX512 interface for control. The advent of E1.31 [E1.31] means that it is much more common for devices to have multiple sources of DMX512 data – these may correspond with physical interfaces (e.g. one DMX512-A and one Ethernet interface) or may be multiple logical streams received on a single physical interface (as is common with E1.31), or both.

This EPI recognizes and expects that many devices will receive multiple concurrent sources of DMX512 data.

Input vs Output

DMX512 is a unidirectional protocol, however devices may have both DMX512 inputs and DMX512 outputs. This EPI only specifies a means to declare the way DMX512 inputs access device properties, because these are a means to access and control a DDL device. DMX512 outputs can be described using foreign or xeno-binding behaviors. Properties specific to configuration or status of the DMX512 interface itself whether input or output, can be described using netinterface derived behaviors.

Characteristics of DMX512 Access

The extensions defined in this EPI only attempt to describe devices controlled using NULL START Code data as defined in [DMX512].

Because DMX512 is a unidirectional protocol, any property that is accessed by it is implicitly write-only. NULL START Code data provides an array of up to 512 eight-bit bytes that are called “Slots” in DMX512-A terminology. This array is repeatedly updated at a rate that is variable but must be faster than once per second and is typically of the order of 20 to 40 updates per second.

Usually a DMX512 device is configured with an “address” (sometimes called “start address” or “base address”), that is an index into the array. It then uses the value of that and some number of consecutive slots as its control data values. Other devices on the link will be configured with different addresses and will therefore take their control values from different slots in the array.

Because the number of available slots is quite limited and the eight-bit format is very rigid, many devices either pack multiple functions into a single slot, or use multiple slots for a single function. There is no standardized way to do this and to complicate things further, many more complex DMX512 devices implement control channels or similar mechanisms where special values in one slot change the meaning of other slots, or where one or more slots needs to take a sequence of values – often with some timing constraints – in order to trigger or access a function.