|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
|
Thread Tools | Search this Thread | Display Modes |
September 29th, 2009 | #1 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
PID = SUPPORTED_PARAMTERS / PARAMTER_DESCRIPTION question
Hello
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 Bernt |
September 30th, 2009 | #2 | |
Administrator
|
Bernt,
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: Quote:
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
|
September 30th, 2009 | #3 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
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 ! regards Peter Willis Howard Eaton Lighting |
September 30th, 2009 | #4 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
> 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. 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. |
September 30th, 2009 | #5 |
Task Group Member
Join Date: May 2009
Location: Gothenburg
Posts: 40
|
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.
__________________
Michael Karlsson LumenRadio AB |
September 30th, 2009 | #6 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
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. Hmm... Kind regards Bernt |
September 30th, 2009 | #7 |
Administrator
|
Bernt,
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.
__________________
Scott M. Blair RDM Protocol Forums Admin |
October 1st, 2009 | #8 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
Bernt
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. Peter |
October 1st, 2009 | #9 |
Senior Member
Join Date: Jan 2008
Posts: 102
|
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 Bernt |
October 1st, 2009 | #10 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
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.
|
February 5th, 2015 | #11 |
Junior Member
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
|
About SUPPORTED_PARAMETERS pid
Hello!
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. |
February 5th, 2015 | #12 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
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. |
February 9th, 2015 | #13 |
Junior Member
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
|
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? |
February 9th, 2015 | #14 |
Task Group Member
Join Date: Aug 2008
Posts: 375
|
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. |
February 9th, 2015 | #15 | |
Administrator
|
Quote:
Controllers should DEFINITELY not crash if they see a PDL of 0x00.
__________________
Scott M. Blair RDM Protocol Forums Admin |
|
Bookmarks |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Mute Response Question | sondericker | RDM Interpretation Questions | 13 | January 21st, 2007 10:14 AM |