DMX_BLOCK_ADDRESS (Set)

[hamish]

In E1.37 Section 3.3, the final statement reads:
This message shall not have any effect on the DMX512 Start Address for the root device, only the sub-devices.


Any of you wise folk out there able to enlighten me on the rationale of this statement?

I have a fundamental problem with this, in as far as that root devices, when contiguosly addressed, may not be represented on the root device without falling fowl of this directive. The upshot of this, is that any responder implementing Block Addressing will undoubtedly hit the otherwise avoidable limitations of many controllers.

Take into account also, as was discussed at the last plugfest in April, it was suggested that sub-devices* do not have to support DEVICE_INFO.
If any one can't see where I'm going with this, I can elaborate...

*Edited, did read root-device

[ericthegeek]

I've never really liked the block address PID. I feel that any kind of block addressing should be handled as a for() loop in the controller rather than in the responder.

The DEVICE_INFO PID is required for root devices.

On sub-devices, there's nothing in the text that requires DEVICE_INFO, but my conclusion is that practically speaking you have to implement it for sub-devices. Otherwise there's no way to find out how many sensors a sub-device has.

[hamish]

Eric.

Thanks for pointing out the error in my last, referring to a root device when I really meant a sub-device

I'm trying to figure out what trap I'm going to fall in to if I drive a coach and horses through the standard by wilfully disregarding the shall statement. Usually, there is a good reason that I've not considered...

[ericthegeek]

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.
http://www.rdmprotocol.org/forums/showthread.php?t=1136

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).

[hamish]

Originally Posted by ericthegeek

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

The problem domain is a little less complicated than that. The Root device has no real DMX slots, just virtual ones that represent the sub-devices, but only when the sub devices are contiguous. So:

When contiguous, Root DMX address = sub device DMX address and root foot print = sum total of sub device slots.

For example, if there are 10 sub-devices from 13 to 22, contigouosly adrressed. Root DEVICE_INFO reports DMX Address 13, footprint of 10.

Sub device 5 address is changed from 17 to 2.
The responder is no-longer contiguously adressed.
Root DEVICE_INFO reports DMX Address FFFF, footprint of 0.

The shall rule is not explicitly violated as the DMX address is the same, the footprint has changed.

Now we set the BLOCK_ADDRESS to 1
Root DEVICE_INFO reports DMX Address 1, footprint of 10.
The shall rule may be technically violated but is of no consequence to a controller, more important is that the footpring has changed which is not prohibited by the standard.

Next we set the BLOCK_ADDRESS to 2.
Root DEVICE_INFO reports DMX Address 2, footprint of 10.
The shall rule has been explicitly violated as the root DMX address has now changed.

The Idea of allowing the flexibility to remain while contiguous, is to enable the many controllers that don't really do sub-devices to change the BLOCK_ADDRESS (providing that the responder is already contguously addressed) by using the setting the root DMX Address, which I see nothing in the standard to counter...

If one is not able to track the other, it makes a nonsense of the whole scheme.

[sblair]

Hamish,

I may just be getting sleepy here but I'm not too offended with what you're proposing there. The Block Address PID was created because there were some folks doing some very bad things with the normal DMX Start Address PID with 0 and values above 512 for crude Block Addressing.

As Eric said one of the main things we didn't want is strange things happening with the root device address when using the Block Address PID. We also were trying to be clear so that it wasn't ambiguous if the Block Address PID would include the root device or not include the root device where it would be a guessing game for a controller. In your implementation you don't really have a root device slot, they are just virtual. The main thing I would say is that when you change modes like that you need to at least send out QUEUED messages alerting the controller that the footprint has changed...

[este_]

I like the idea as reporting contiguous sub-devices as virtual rootdevice, but then I see the problem of identifying this as "virtual" root device.

Going with Hamish' example, "Now we set the BLOCK_ADDRESS to 1.
Root DEVICE_INFO reports DMX Address 1, footprint of 10."

What will occur? When reading the device info, it will tell me:

- I have a root device with a start address and I have 10 slots used. Reading the subdevice count field, I see that I have (additional) Sub-Devices present. So I read all the Sub-Devices and find, there are ten more slots (so now I have a total of 20 slots used), and I find, the subdevice addresses conflict with what I have already read for the "virtual" root (overlap).

Wrong or right?

Thus I would assume, reporting a start address and footprint for a "virtual" root device is not possible at all without creating additional confusion... We should separate rootdevice info and subdevice info as much as possible.

I would like to offer two solutions for the problem "to enable the many controllers that don't really do sub-devices":
- add additional functionality to the controllers under review, or
- make using subdevices optional.

We have chosen the latter option. Units are shipped as root devices having a start address and a number of slots used. User can activate subdevice functionality calling a manufacturer function called "ENABLE SUBDEVICES". When done, the unit identifies itself as rootdevice using no slots and so start address, but features a number of subdevices instead. BLOCK ADDRESS will only affect subdevice addressing, and never report to rootdevice data.

Comments welcome.

[pkirkup]

I tend to agree with Eckart - a controller will almost certainly see and treat the subdevices as additional to the root device, rather than assuming the virtual link. Therefore when discovering your scenario above, the controller would see 20 slots occupied, with a start address conflict.

One solution would be to report a root address but a zero footprint, but that would conflict with:

If the Device or Sub-Device does not utilize Null Start Code packets for any control or functionality then it shall report a Footprint of 0x0000

If the Device or Sub-Device that this message is directed to has a DMX512 Footprint of 0, then this field (DMX512 Start Address) shall be set to 0xFFFF.

Maybe an addendum to E1.37-1 which defines a footprint of 0xFFFF as 'virtual start address'?