View Single Post
Old June 25th, 2013   #4
Task Group Member
Join Date: Aug 2008
Posts: 363

I fear I'm being a bit dense and not fully understanding the problem.

You have a RDM responder that has both a Root device with a non-zero slot footprint, and also has Sub-Devices with a non-zero slot footprint. Say for example a dimmer rack with a "fan speed" slot on the root device, and 24 dimmers, each with its own sub-device and a slot footprint of one.

The standard says that if you issue a Block Address PID with an address of 11, that the 24 dimmer sub-devices should get addressed from 11 to 34, but the root's fan-speed address will remain unchanged.

The behavior you want is to set the root's fan speed slot to address 11, and then address the 24 dimmers from 12 to 35 when you receive the Block Address PID?

For any controller that does support Block Addressing, I think this would cause a problem. When the user tries to auto-patch, it will add up the number of slots used by every sub-device, and then try to patch it. If the controllers sees 12 slots worth of dimmer sub-devices, it will reserve a block of 12 slots during auto-patch. If the responder actually patches 13 slots (root + 12 sub-devices), you'll likely get an address conflict on the 13th slot.

The simple solution is don't support the Block Address PID. :-) Since it's not a required PID, controllers will have to work with responders that have sub-devices but don't support block addressing.

Here's a previous thread discussing sub-devices and the DEVICE_INFO PID.

My controller implementation requires that any sub-devices support the DEVICE_INFO PID. If the responder NACKs DEVICE_INFO, the controller displays and error and ignores the sub-device. Without DEVICE_INFO, you'd just got no place to start. Some of the information from DEVICE_INFO can be collected or inferred other ways, but none of them are 100% dependable (sending a GET SENSOR_DEFINITION to all possible sensors, etc).
ericthegeek is offline   Reply With Quote