E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   PID = SUPPORTED_PARAMTERS / PARAMTER_DESCRIPTION question (http://www.rdmprotocol.org/forums/showthread.php?t=1022)

berntd September 29th, 2009 09:54 PM


Table A-3 mentioned that these PIDs must only be supported if paramters beyond the min are supported by the device.

if this is the case, does the response to this then also have to include the min paramter descriptions or only the additional ones?

In other words: Does this command/response have to support the min paramter set at all or only extended / others?

Kind regards

sblair September 30th, 2009 12:28 AM


It's a good question and one we had come up at work. For the SUPPORTED_PARAMETERS message, only the PID's that are not included in the minimum support list shall be transmitted.

The key bit of text for this is located at the very end of Section 10.4.1:


PIDs that are included in the minimum support list, indicated by the “Required” column of Table A-3, shall not be reported.

The one PID that gets a little tricky here is DMX_START_ADDRESS. Since it is only "required" if the device consumes a DMX Slot. It is an edge case for the requirement since it is conditional on the device's function. For that reason I always include DMX_START_ADDRESS in my list of SUPPORTED_PARAMETERS even though one could argue I shouldn't.

The requirement in Section 10.4.1 is clear though when it comes not reporting the other required PID's.

prwatE120 September 30th, 2009 01:48 AM

Hi Bernt

We do not include DMX_START_ADDRESS, as we always treat it as "required PID".

Some of our products have multiple personalities, and only one of them might have a DMX footprint of 0, and I felt it was important that the list of SUPPORTED_PIDs was the same regardless of the current personality setting.

The PARAMATER_DESCRIPTION PID is only required if you are declaring support for Manufacturer specific PIDS. The test in section 10.4.2 is a bit weak, as it refers to "some" manufacturer-specific PIDs.

We have more of a problem with the construct of PID, as about the only thing you can properly describe about our particular Man-specific PIDS using the defined fields as per 10.4.2 is a text string. The rest of the structure of this PID cannot adequately describe the format requirements of our implementations.

Although you could argue that they are "non-compliant" products, I would not be that upset to see products that declared the existence of manufacturer specific PIDS in there list of SUPPORTED_PARAMETERS and did not support the PARAMATER_DESCRIPTION PID.

At least this way you know there is something that the manufacturer might allow you to control, and you ask them for more details !


Peter Willis
Howard Eaton Lighting

ericthegeek September 30th, 2009 09:30 AM

> Although you could argue that they are "non-compliant"
> products, I would not be that upset to see products that
> declared the existence of manufacturer specific PIDS in
> there list of SUPPORTED_PARAMETERS and did not support

Per table A-3, a responder that reports a Manufacturer-Specific PID in the SUPPORTED_PARAMETERS message is required to support the PARAMETER_DESCRIPTION PID.

I agree that the format of the PARAMETER_DESCRIPTION message is somewhat limiting and can't describe every possible use case. Still, just having the human readable name string is valuable.

mike_k September 30th, 2009 01:41 PM

I've seen quite a few products that replies with the minimum required set of PIDs included in the list, so even if responders are not supposed to do so the controllers should be able to handle all cases when subsets of the required PIDs are included or not.

berntd September 30th, 2009 06:02 PM

Hello all,

Thanks for this. Those are the exact issues I have come up with here.

If DMX_START_ADDRESS is supported (because the device needs it then how is a controller supposed to know this unless it can detect it with the PARAMTER PIDs?

I would have to agree with Scott in that it should be treated as a NON mandatory pid and thus included in the SUPPORTED_PARAMTER -list.

Then again, one could argue that if the device does
not need DMX_START_ADDRESS, it should respond with a nack reason NR_UNKNOWN_PID.
The controller could then make a conclusion from that, in which case Peter's approach will work too.

:confused: Hmm...

Kind regards

sblair September 30th, 2009 06:06 PM


A controller can tell if it consumes a DMX Slot by looking at the footprint field in the DEVICE_INFO PID. If the footprint is zero then it is fairly safe to say that the DMX_START_ADDRESS is not used.

prwatE120 October 1st, 2009 03:27 AM


In section 10.6.3 we clearly state that a GET:DMX_START_ADDRESS request sent to a root or sub-device that has a footprint of zero shall return a value of 0xFFFF.

One could argue that NACKing any GET/SET DMX_START_ADDRESS with a NR_DATA_OUT_OF_RANGE is still supporting the PID, and our definition in table A-17 is entirely consistent with having a footprint of zero.

(definition is "Value out of range or not supported)

This would be preferable to a NACK:NR_UNKNOWN_PID as it avoids any argument that you haven't supported what many expect to be a Mandatory Pid.

My preference would be for us to remove the "option" in Table A-3 and point people back to the "shall" statement in 10.6.3, and add clarification on how to NACK the SET: request.


berntd October 1st, 2009 05:54 PM

Hi Peter,

I see what you mean and it does make sense. If the DMX_START_ADDRESS PID would be considered mandatory for all devices, then the issue would be resolved more consistently.

Kind regards

ericthegeek October 1st, 2009 09:57 PM

There are already responders in the wild that don't support the DMX_START_ADDRESS PID. Even if it were to be made mandatory in a future version of the document, controllers would still have to handle devices that don't support it.

zano_villa February 5th, 2015 08:23 AM

I have a doubt: if I have only required parameters in my RDM implementation, do I have to respond to a GET_COMMAND SUPPORTED_PARAMETERS request from controller?

And if the answer is YES, is this the reason for 0x00 in PDL (page 54 of standard)?

Thank you.

ericthegeek February 5th, 2015 10:30 AM

Table A-3 in E1.20 makes it clear that if you only support the required PIDs you do not have to support SUPPORTED_PARAMETERS.

That being said, I'd strongly encourage you to support DEVICE_MODEL_DESCRIPTION, MANUFACTURER_LABEL, and SOFTWARE_VERSION_LABEL. These should be easy to implement for most responders because you don't have to calculate anything on the fly, all they do is return a string.

zano_villa February 9th, 2015 07:19 AM

Thank you,

about SOFTWARE_VERSION_LABEL it is mandatory so I have to implement it in any case....about other two PIDs I agree with you.

But what is the meaning of SUPPORTED_PARAMETERS response with PDL = 0x00 ?
Can you explain please?

ericthegeek February 9th, 2015 09:32 AM

A SUPPORTED_PARAMETERS response with a PDL of 0x00 is really a corner case. Most of the time you won't need it.

Arguably you could respond with 0x00 if you don't support any of the optional PIDs.

Also, there might be situations where you want to Queue a SUPPORTED_PARAMETERS response. For example, if the user does something at the responder's local menu that causes it to change the set of PIDs it supports.

Don't read too much in to it... Nearly ever real-world responder will have a non-zero length response to GET SUPPORTED_PARAMETERS. Controllers should probably not crash if they get a response with a PDL of zero, but you won't see it very often.

sblair February 9th, 2015 03:54 PM


Controllers should probably not crash if they get a response with a PDL of zero, but you won't see it very often.
Normally I have a hard time finding something to disagree with Eric on, but I'm gonna say here that I disagree with his use of "probably".

Controllers should DEFINITELY not crash if they see a PDL of 0x00. :)

All times are GMT -6. The time now is 03:57 PM.

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