Posted on

Developer: Art-Net – Identifying the source of an ArtTodData packet

The ArtTodData packet is used to encode a list of UIDs received from a particular physical port. This is the Table of Devices or ToD.

It is often useful to identify the physical port that generated the packet. Because Art-Net (for historical reasons) allows a variable number of ports to be encoded in an ArtPollReply, the calculation is not trivial.

ArtTodData->Port is limited to a range of 1-4. It is used in combination with BindIndex to identify the physical port that generated the packet. This is done by referencing data in the ArtPollReply with a matching BindIndex:

ArtPollReplyData->BindIndex == ArtTodData->BindIndex

An ArtPollReply can encode between 1 and 4 physical ports, defined by ArtPollReply->NumPortsLo. This number must be used when calculating the physical port in order to allow for the variable encoding.

The calculation is:

Physical Port = (BindIndex-1) * ArtPollReply->NumPortsLo + ArtTodData->Port

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

The following tables show how this works in practice:

A gateway that has 5 physical ports and encodes 1 port per ArtPollReply (the recommended modern implementation).

Physical port 1-xArtTodData->BindIndexArtPollReply->NumPortsLoArtTodData->Port
1111
2211
3311
4411
5511

A gateway that has 9 physical ports and encodes 2 ports per ArtPollReply (very widely implemented in Art-Net 3 era products).

Physical port 1-xArtTodData->BindIndexArtPollReply->NumPortsLoArtTodData->Port
1121
2122
3221
4222
5321
6322
7421
8422
9521

A gateway that has 9 physical ports and encodes 4 ports per ArtPollReply (very widely implemented in Art-Net 3 era products).

Physical port 1-xArtTodData->BindIndexArtPollReply->NumPortsLoArtTodData->Port
1141
2142
3143
4144
5241
6242
7243
8244
9341

Posted on

Developer: RDM – Manufacturer Specific PIDs

Manufacturer-specific PIDs are used to provide manufacturers with a mechanism to implement RDM commands that are not available in the standard RDM command set. The RDM standard says:

“Manufacturer-specific PID‘s shall be created in the range of 0x8000 – 0xFFDF. Uniqueness of PID‘s in this range is accomplished by associating the PID with the Manufacturer ID found as the most significant 16-bits of the UID. PID‘s in the range of 0xFFE0 – 0xFFFF are reserved for future uses of this standard.”

There are generally two categories of use:

1) To implement additional functionality that will be available to all.

2) To implement manufacturing specific commands that will be closed to all but the manufacturer.

The first option is simple to implement. The manufacturer-specific PIDs are defined and published using PIDs such as Supported_Parameters and Parameter_Description. From then on, it is the controller’s responsibility to ensure that it only sends you valid manufacturer-specific Pids.

The second option provides more room for error if the designer does not think through all scenarios. It is quite usual for manufacturers to use a manufacturer-specific Pid for functions such as ‘programme UID’. Clearly these are intended to only be used in the manufacturing process and chaos would ensue if they were activated in the field.

What can manufacturers do to protect against inadvertent activation of their manufacturer-specific Pids:

1) Not public the Pid in Supported-Parameters. This is sensible, but does not give any real protection. For example, network test software way well send un-published manufacturer-specific Pids to see whether the device responds.

2) Ensure that the responder will only accept critical manufacturer-specific Pids when it is in a “special configuration mode”.

3) Include ‘magic-numbers’ in the packet to ensure that manufacturer-specific Pids sent in error do not have unexpected effects.

4) Ensure that the responder will only accept critical manufacturer-specific Pids which have a source-UID containing the manufacturer code. This is the strongest protection.

An index of published manufacturer PIDs can be found at http://rdm.openlighting.org/pid/manufacturer

Posted on

Developer: Art-Net Version Numbers

Numerous of the Art-Net packets contain Version numbers.

These can be either the version number of Art-Net or the Node’s version number. The terms ProtVerHi / ProtVerLo are used to describe the Art-Net protocol version number. This has never been changed and is set at:

  • ProtVerHi = 0
  • ProtVerLo = 14

The terms VersInfoH / VersInfoL are used to describe the Node’s version number. This field is defined by the manufacturer and usually contains the firmware revision number. The ArtPollReply message contains this information.

Posted on

Developer: Art-Net – Multiple controllers

Art-Net allows and supports multiple controllers on a network. When there are multiple controllers, Nodes will receive ArtPolls from different controllers which may contain conflicting diagnostics requirements. This is resolved as follows:

  • If any controller requests diagnostics, the node will send diagnostics. (ArtPoll->Flags->2).
  • If there are multiple controllers requesting diagnostics, diagnostics shall be broadcast. (Ignore ArtPoll->Flags->3).
  • The lowest minimum value of Priority shall be used. (Ignore ArtPoll->Priority).
Posted on

Developer: Art-Net – ArtPoll and ArtPollReply timeout

A Node must respond to an ArtPoll with an ArtPollReply within 3 seconds. If the Controller does not receive a response in this time it should consider the Node to have disconnected. 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.

Posted on

Developer: Art-Net – Implementing ArtPoll and ArtPollReply

In order to make a product visible in DMX-Workshop, the product must reply to an ArtPoll with one or more ArtPollReply. The screenshot below shows a Wire Shark capture of the ArtPollReply packets from a Data-Lynx IOP.

Common errors in formatting ArtPollReply are:

1) The text signature at the top of the packet is “Art-Net”. It is case sensitive.

2) DMX-Workshop only listens on Port 6454 (decimal).

If you have difficulty making your product visible in DMX-Workshop then submit a Wire Shark capture on a support ticket and we will try to help.

artpollreply in wireshark
artpollreply in wireshark