Posted on

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

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

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

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

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