E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   PDL size and manufacturer specific parameter ID's (http://www.rdmprotocol.org/forums/showthread.php?t=1017)

jamie July 10th, 2009 12:59 AM

PDL size and manufacturer specific parameter ID's

This is a question regarding an RDM controller generating GET and SET messages for manufacturer specific parameter ID's, based on the information obtained from using the PARAMETER_DESCRIPTION command.

The response to a PARAMETER_DESCRIPTION command includes the "PDL Size" field, which corresponds to GET_RESPONSE and SET PDL sizes, but what about GET and SET_RESPONSE PDL sizes??

Get/Set DMX Curve command
GET takes in channel (PDL size = 1)
GET_RESPONSE replies with channel and curve (PDL size = 2)
SET takes in channel and curve (PDL size = 2)
SET_RESPONSE replies with no data (PDL size = 0)

So the PDL size field under PARAMETER_DESCRIPTION would be 2 to match GET_RESPONSE and SET, but there is no indication as to how much data to use with GET.

Has anyone come up with a solution/workaround for this?? Note that the controller I'm developing is hand-held with limited firmware, so it's not feasible storing the required information for manufacturer specific id's.

One possible workaround I've thought about is first attempting GET with a PDL size the same as GET_RESPONSE/SET (after allowing the user to set as many data fields as they like up to the GET_RESPONSE/SET PDL size), and if a NACK is received, keep reducing the PDL size of GET until an ACK is received.

Any thoughts on this would be greatly appreciated.

Creative Lighting

sblair July 10th, 2009 01:57 PM


The intent of the PARAMETER_DESCRIPTION message was for it to only be used to describe very basic GET/SET parameters for a single function as these are very common and easy to understand. Every manufacturer tends to have those menu settings that are specific to their product, so this was an attempt at addressing that.

As a consequence of that this message was intended to be used where there are no other modifiers in the GET request or the SET response message that would need to be specified. For the situation you describe where you want to get/set curves for individual dimmer channels then it would make the most sense for the dimmers to be implemented as sub-devices. The sub-device number would then be used to specify which "channel" rather than putting it in the PD area as well.

Hope this helps clarify.

jamie July 12th, 2009 07:08 PM

Thanks for your answer scott.

Unfortunately not all manufacturers think the same way you do, otherwise things would be easier!

To get around the problem, I'll just require the user to select how many bytes they want to send with a manufacturer specific GET command. It's not the best solution, but at least it's generic and should work with most devices.


sblair July 12th, 2009 09:27 PM


Is there a particular manufacturer that you're running into this with? If so, I'd suggest they go the sub-device route as that is what they are designed for.

jamie July 12th, 2009 10:50 PM

At the moment I only have access to a 6-channel dimmer (we're only just starting to implement RDM in our controllers and responders, so we don't have access to much equipment yet) and it's implemented as a single device with no sub-devices.

Do the majority of devices out there use sub-devices?

sblair July 13th, 2009 12:31 AM

I'm starting to see more implementations as sub-devices happening. Sub-devices were really intended specifically for dimmers, but of course can be used in many different types of products.

The best place to get access to a variety of RDM gear is during the Plugfests being sponsered by ESTA. It gives everyone a good chance to share best practices as well as debug their gear against a wide variety of other gear out there.

All times are GMT -6. The time now is 05:03 AM.

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