Duplicates & Merging

For an introduction to ArtDmx, please refer to Streaming Packets.

Duplicates & Merging

The Art-Net protocol allows multiple ArtDmx packets to be sent to the same destination Port-Address. Without the receiving node explicitly handling the situation, a fault condition would occur as a specific channel would flicker back and forth as the conflicting controller data was processed.

A node can detect that it is receiving ArtDmx from different controllers by comparing the sender IP address of the ArtDmx packet.

The protocol is flexible in allowing the node to handle the potential conflict in a number of ways; in fact the only mandate is that the product documents its approach.

Three approaches exist:

  • IP Lock
  • Error condition
  • Merge

IP Lock

The IP Lock approach is simply to ignore any ArtDmx received from a controller with an IP address that is different to the first IP address sent to the node. Clearly a time-out procedure is also required otherwise the node could become locked to a controller that had gone off line.

The approach is used by a number of manufacturers.

Error Condition

This approach is really just saying that the node is not designed to handle duplicate ArtDmx data and that user intervention is required to resolve the problem. While this is the least flexible approach, it has the benefit of putting the onus on the operator to ensure all is operating as expected.

Merge

The Merge approach is the most flexible, implicit in which is the assumption that the duplicate data packets are intentional and that the user wants them to be merged.

Art-Net does not mandate that a node must merge duplicate ArtDmx streams. However, if the product does implement merging, it must do so in a specific manner.

Merging only ever operates with data from two controllers; if a third stream is detected the node will ignore it. Merging can operate in two different modes:

  • LTP – Latest Takes Precedence
  • HTP – Highest Takes Precedence

Operating in LTP mode means that the level of the merged channel will be set to that defined by the ArtDmx packet which was most recently received. Conversely, in HTP mode the level of the merged channel will be the greater of those in the two received ArtDmx packets that are being merged. The LTP or HTP mode of merging is selected per physical port using:

ArtAddress->Command

The transition into and out of merge mode must be reported in:

ArtPollReplyGoodOutput[]->Bit3

Numerous conditions can lead to the termination of merge mode. The following table defines the conditions:

merge1

It will be clear from the description above that numerous scenarios exist whereby a discontinuity in level can occur – causing lights to flash or flicker. It is left to the product designer to find the most elegant and aesthetically pleasing implementation of the above requirements.

It is worth noting that all the merge operations discussed above relate only to the conversion of network data back to DMX512 – be that physical or virtual. A similar situation can arise with input nodes tasked to convert physical DMX512 into Art-Net.

Consider a product with 4 DMX512 inputs all set to be encoded on to identical Port-Addresses. Art-Net requires that the manufacturer resolve this problem (the term ‘problem’ is used in the sense that if the product generated multiple ArtDmx streams, they would all be encoded with identical source IP addresses and so ‘break’ the merge algorithm).

Some manufacturers have implemented a concept of input merging, others choose to prioritise their input ports. Either is acceptable so long as the approach is documented in the user guide.