E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old January 14th, 2010   #1
Mark_C
Junior Member
 
Join Date: Dec 2009
Posts: 5
Default DMX Addressing when Footprint is Zero

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
Mark_C is offline   Reply With Quote
Old January 14th, 2010   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 14th, 2010   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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.
ericthegeek is offline   Reply With Quote
Old January 14th, 2010   #4
Mark_C
Junior Member
 
Join Date: Dec 2009
Posts: 5
Default

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
Mark_C is offline   Reply With Quote
Old January 14th, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

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.
ericthegeek is offline   Reply With Quote
Old January 14th, 2010   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 15th, 2010   #7
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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.
__________________
Michael Karlsson
LumenRadio AB
mike_k is offline   Reply With Quote
Old January 17th, 2010   #8
Mark_C
Junior Member
 
Join Date: Dec 2009
Posts: 5
Default

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
Mark_C is offline   Reply With Quote
Old January 17th, 2010   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Auto DMX Addressing via RDM ?! chamber RDM General Implementation Discussion 12 November 11th, 2009 01:47 PM


All times are GMT -6. The time now is 09:50 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.