E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old September 29th, 2009   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default 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
berntd is offline   Reply With Quote
Old September 30th, 2009   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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:
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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 30th, 2009   #3
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old September 30th, 2009   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> 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.
ericthegeek is offline   Reply With Quote
Old September 30th, 2009   #5
mike_k
Task Group Member
 
Join Date: May 2009
Location: Gothenburg
Posts: 40
Default

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
mike_k is offline   Reply With Quote
Old September 30th, 2009   #6
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old September 30th, 2009   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
sblair is offline   Reply With Quote
Old October 1st, 2009   #8
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old October 1st, 2009   #9
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

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
berntd is offline   Reply With Quote
Old October 1st, 2009   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old February 5th, 2015   #11
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
Default 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.
zano_villa is offline   Reply With Quote
Old February 5th, 2015   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old February 9th, 2015   #13
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
Default

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?
zano_villa is offline   Reply With Quote
Old February 9th, 2015   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

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.
ericthegeek is offline   Reply With Quote
Old February 9th, 2015   #15
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
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.
__________________
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
Mute Response Question sondericker RDM Interpretation Questions 13 January 21st, 2007 10:14 AM


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


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