E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old February 6th, 2011   #1
swisson
Junior Member
 
Join Date: Sep 2006
Posts: 2
Default 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?


Thanks

Robert
swisson is offline   Reply With Quote
Old February 7th, 2011   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Quote:
Originally Posted by swisson View Post
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.
ericthegeek is offline   Reply With Quote
Old February 7th, 2011   #3
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Robert,

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
Old February 8th, 2011   #4
swisson
Junior Member
 
Join Date: Sep 2006
Posts: 2
Default

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.
Right?



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



Robert
swisson is offline   Reply With Quote
Old February 8th, 2011   #5
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by swisson View Post
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:
Quote:
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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old February 8th, 2011   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old February 17th, 2011   #7
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Old February 17th, 2011   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Michael,

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!
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old February 17th, 2011   #9
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
3.2.1 Responder Packet Timings prwatE120 RDM Timing Discussion 6 May 23rd, 2009 08:32 AM
Any RDM Responder Devices out there yet? sblair RDM Marketplace Discussion 8 September 20th, 2006 06:03 AM


All times are GMT -6. The time now is 06:38 AM.


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