View Single Post
Old February 7th, 2011   #3
Join Date: Feb 2006
Posts: 425
Send a message via AIM to sblair Send a message via MSN to sblair


You are correct in regards to the relationships of the Binding UID that gets reported for the other ports. i.e. all responder ports report they are bound to UIDa.

Beyond that there is no other requirements for how devices respond or behave on their secondary ports. It does NOT mean that they only respond on the primary port.

The classic example for the Binding UID is the 2-port Dimmer Rack. Most dimmer racks have at least 2 input ports on them to deal with the rack that has a universe split occur. If you have a bank of 6+ 96-way dimmer racks you end up with a universe split in the middle of Rack #6 where Universe 1 feeds part of the rack and Universe 2 feeds the 2nd part of the rack. For this example we are talking a single console.

The Binding UID allows the system to recognize intelligently associate these 2 different responders as being a single physical device. That allows the console to more intelligently represent the devices on the network as Eric suggested as you don't want to have the system showing more physical devices than what really exist.

It also allows the console to make some intelligent decisions. If it knows these are the same physical device then it doesn't have to send redundant requests for a lot of the common parameters to both Responder UID addresses. It knows it can get 90% of the info it needs by only asking one time instead of twice.

There is no expectation that devices will ONLY communicate through there primary responder port, as Eric said some messages HAVE to be sent to the secondary ports as the message is port specific (DMX_START_ADDRESS). I would expect that a good responder will allow you to equally communicate through any of it's responder ports.

Multiple Controller behavior is not inherently defined in this document, but it will be much more prominent in the E1.33 (RDMnet) standard. Responders designers with multiple ports are best to keep multiple controller behavior in mind. As you said, in your scenario the 2nd controller can still associate Ports C/D as being the same device even though it doesn't ever see Port A.
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote