Responders with multiple Responder Ports in a single Device.

[swisson]

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

[sblair]

Originally Posted by swisson

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.