Responders with multiple Responder Ports in a single Device. - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · February 8th, 2011

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.

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

February 8th, 2011	#6
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	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.