DMX Addressing when Footprint is Zero

[Mark_C]

Greeings,

How would you handle DMX addressing if your product is made up of all sub-devices and the root has a zero footprint? Right now our product is made up of 16 LED pixels (3 channels each, RGB) and each pixel is implemented as a sub-device (so 16 sub-devices of 3 channels each). So the entire product takes up 48 slots. The product is addressed as a singe unit, meaning that all the DMX addresses are sequential starting with the assigned DMX address.

My question specifically is, should the DMX_START_ADDRESS command be implemented at the root level even though the root has no slots? Or should it be implemented at the sub-device level - even though you cannot set a sub-device's address? How will a controller expect to change my DMX address in a configuration like this?

Thanks in advance for any clarification someone can give me!!!

Mark

[sblair]

Mark,

This has been a subject that has been given a lot of debate recently. We are in the process of adding a number of new PID's to RDM to expand capabilities for dimmer racks and sub-devices in general. Your question hit on one of the main issues we are dealing with there.

There will be a Public Review document coming soon with these new PID's so you can review and comment on them. In a nutshell, we are adding another PID that allows you to do "block addressing" from the root device for all the sub-devices to make addressing simplier.

There are a number of other workarounds that are currently being used by people even though they fall outside of the current standard. One of these includes implementing DMX_START_ADDRESS at the root level to effectively block address the sub-devices.

Others on here have all had to deal with this issue, so I'll let them comment on their current solutions/workarounds to this issue.

Scott

[ericthegeek]

If the sub-devices cannot be addressed individually, then I'd argue you should have the root declare a 48 slot footprint, and give each sub-device a footprint of zero. This will offer the most compatibility.

The enhancements Scott talks about are to simplify block-addressing a device when there are multiple sub-devices that can be addressed individually. I don't think that will apply in your case.

You'll also want to support any personality and SLOT_DESCRIPTION parameters on the root, since that is where the controller will expect to find them.

You can still use sub-devices for things like sensors. Although, if you're not going to allow any settings to be changed on a per-sub-device basis, it's probably easier all-around to not use sub-devices and have it act like a single 48 slot fixture.

Even better, allow the DMX address, Personality, etc to be set for each sub-device. This is the most flexible option and gives your users the most control. It will also help the control console understand that it is 16 repeating units rather than one giant device.

[Mark_C]

Thanks for the suggestions. I actually started down the path of putting all of the channels at the root level. But the SLOT_INFO message only has room to describe 46 channels (230 bytes / 5 bytes). I guess SLOT_INFO is an optional message so maybe I wouldn't need to support it??? Would that be a valid approach?

Mark

[ericthegeek]

You don't have to support SLOT_INFO. But, it's a good PID to have since it helps the controller understand what it's dealing with.

You are limited to 230 bytes in single packet, but you can use the ACK_OVERFLOW mechanism to deliver arbitrarily large responses. With ACK_OVERFLOW, you send as many responses as you can in a single packet, but you replace the ACK with an ACK_OVERFLOW. That tells the controller that there is more data, and it should issue a GET SLOT_INFO again to get the rest of it. You send as many ACK_OVERFLOW packets as you need, and then go back to ACK for the final packet.

[sblair]

Mark,

Eric is correct on using setting the DMX start address at the root level. I read your message too quickly and missed the part that you don't support DMX addressing at the sub-device level, so you would declare the footprint and DMX start address as a property of the root device and not include those PID's for the sub-devices.

[mike_k]

I agree with Eric and Scott.

As you describe it, you should set the root device to having a footprint of 48 and the sub-devices to have a footprint of 0.
You don't have to support SLOT_INFO, but I would recommend it. As Eric mentioned, you can use the ACK_OVERFLOW mechanism. This mechanism can be used whenever your response is longer that what you can return in one transfer.
For instance, if your transmit buffer only allows you to have a parameter data length of 50, then you can use it as well. Your device doesn't have to support the largest possible response length, it could split the responses. This is common in devices with very limited memory resources.

[Mark_C]

Thanks guys, this was very helpful. I've done it both ways, so modifying the firmware as you suggest - and using the ACK_OVERFLOW should be no problem.

This is a great forum, and you guys are very helpful for people trying to figure out the nuances. I believe RDM is an invaluable addition to DMX and we're moving full speed to implement it in all our products.

Thanks for your help!

Mark

[sblair]

Mark,

Thanks for the kind words. That's exactly why we set the forums up was to be able to help clear up questions as people are implementing the protocol.

Let us know if you think you'll be able to attend the Plugfest in Dallas next weekend. We'd love to have you there.

Scott