E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Responders with multiple Responder Ports in a single Device. (http://www.rdmprotocol.org/forums/showthread.php?t=1085)

swisson February 6th, 2011 11:47 PM

Responders with multiple Responder Ports in a single Device.
I have a question about Responders with multiple Responder Ports in a single Device.

If I have a single device with 4 responder ports, each responder port needs his own UID. So the device has 4 UIDs ?
In case a single controller is connected to all 4 responder ports, it will find “4 devices”. But based on the binding UID it knows which is the primary port, and will communicate only though this port?

Controller X -> Resp. Port A UIDa (Binding UIDa)
Controller X -> Resp. Port B UIDb (Binding UIDa)
Controller X -> Resp. Port C UIDc (Binding UIDa)
Controller X -> Resp. Port D UIDd (Binding UIDa)

What happened when the single device with 4 responder is connected to 2 Controllers?

Controller X -> Resp. Port A UIDa (Binding UIDa)
Controller X -> Resp. Port B UIDb (Binding UIDa)

Controller Y -> Resp. Port C UIDc (Binding UIDa)
Controller Y -> Resp. Port D UIDd (Binding UIDa)

In that example both controllers knows the primary port, but only controller x has access to it?

The controller Y knows that UIDc and UIDd have the same Binding UID so it knows that is one single device with multiple ports and communicate to one of the accessible UIDs (UIDc or UIDd) ?

Or do I completely misunderstand the idea behind multiple responder ports and binding UID?



ericthegeek February 7th, 2011 09:01 AM


Originally Posted by swisson (Post 2125)
But based on the binding UID it knows which is the primary port, and will communicate only though this port?

I don't think this is true. The RDM controller can communicate with *any* of the ports, not just the primary port. In fact, for a PID like DMX_START_ADDRESS, you must be able to send it to each port individually so that each port to be patched differently. You may want one port to start a slot 10, and another to start at 57.

The main reason for the binding UID mechanism is to permit the controller to understand that the four ports are all a single device if you're drawing a pretty system block diagram.

A responder could even have different personality settings for each port.

sblair February 7th, 2011 10:18 AM


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.

swisson February 8th, 2011 02:02 AM

Tanks for clarifying
Each port will act independently on RDM, they just may share some parameters.
If the controller will change a parameter which is shared on the device (per example: Label ) by using UIDa, on all others ports will be a message indicating that the label has changed.
So working with two or more controllers should work.

Should the primary port report a binding UID to itself or not?


sblair February 8th, 2011 09:48 AM


Originally Posted by swisson (Post 2130)
Should the primary port report a binding UID to itself or not?

Being the guy who wrote the Binding UID text I would say that is not required at least that is what my intent would have probably been. However, a strict reading of the language would require it.

The exact text reads:

If the device does contain multiple ports, then the Binding UID field shall contain the UID for the primary port on the device.
So that means you supposed to do it. Controllers would be smart to handle the primary port either way.

As far as working with multiple controllers, the bigger trick is the handling of Queued and Status messages. Unless you are able to do some cleverness you have the issue of which ever controller asks first gets those and the other controller doesn't get them.

If you have a way of knowing the controller is physically different then you can intelligently duplicate the report of the Status/Queued messages across the consoles. You don't want duplicate reports going to the same controller either, so it would probably require a couple configuration options of how to manage it or some better knowledge of the overall system architecture to make the right decisions on delivery of those messages.

ericthegeek February 8th, 2011 05:29 PM

A multi-port responder opens up a lot of issues that haven't been well explored. I don't know of any devices currently on the market that have multiple responder ports. Are you implementing an RDM controller that needs to deal with multi-port fixtures, or are you doing a multi-port responder?

I haven't really thought through all of the implications, so I'm mostly thinking out loud here.

There are a few different use cases:
1: A multi-port responder where all ports go to the same controller.

2: A multi-port responder where the ports go to different controllers, but each port controls a separate portion of the responder (like a dimmer rack where one port controls dimmers 1-12, and another controls 13-24).

3: A multi-port responder where the ports control the same things (such as an architectural and theater controller both controlling the house lights).

Arguably you'd want different behavior from the responder in each case. For case 1, you probably want all of the main setup PIDs to be shared across all ports (Device Label, identify, preset playback/record, etc) and for queued messages/status messages to be delivered to a single port.

For case 2 you'd probably want different setup PIDs for each port (so each system could give its own device label to the responder). It's probably best if queued messages/status messages are delivered to the port controlling that portion of the device, except for global status messages (like "status dimmer room flood") that would go to all ports.

Case 3 is a complicated mix of 1 and 2. Arguably this is an RDM Merger. The task group has discussed how to implement an RDM merger at length, and generally agreed to leave it up the individual manufacturer. If one port changed the device label, you probably want to queue a DEVICE_LABEL message on the other ports.

Were I implementing a multi-port responder I'd probably try to make each port act as much like a standalone responder as possible.

mike_k February 17th, 2011 12:50 AM

Our multi-universe transmitters have multiple responder ports, however I've chosen to not use the binding UID because at some point I ran into a controller that did not handle it (not just that it did not understand the binding UID, since few controllers do that, but it did not even manage du discover the device), yes it is a specific controller issue - but it ends up as a problem with my device as far as the user is concerned.
If any parameter is changed on one port that is common for all ports, it queues up a message on the other ports.

sblair February 17th, 2011 10:23 AM


It's best to get the Controller manufacturer to correct it. Binding UID usage is going to be critical in how E1.33 works so best to start getting folks to implement it properly!

mike_k February 17th, 2011 10:41 AM

Scott, yes of course the best would be to get everybody doing everything right. In the meanwhile unfortunately we'll have to do a lot of work-arounds. Especially for us doing in-line devices that is not transparent. We will always get the blame if something does not work, even if we do everything right.

All times are GMT -6. The time now is 07:43 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2021, vBulletin Solutions, Inc.