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 April 14th, 2014   #1
RenZO
Junior Member
 
Join Date: Apr 2014
Posts: 2
Default CURVE supported : implies CURVE_DESCRIPTION in supported parameters ?

Hello,

I have those PIDS in SUPPORTED_PARAMETERS:
CURVE
OUTPUT_RESPONSE_TIME

Then, I also have the PIDS :
CURVE_DESCRIPTION
OUTPUT_RESPONSE_TIME_DESCRIPTION

According the E1.37-1, as these are "required", do we need to add *_DESCRIPTION PIDS in SUPPORTED_PARAMETERS, or not ?

As said in another post, E1.20 says in 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.

But in E1.37-1 we have for example :
CURVE_DESCRIPTION
* Support required only if CURVE is supported.

So what to do please ?

Thanks,
RenZO.
RenZO is offline   Reply With Quote
Old April 14th, 2014   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

We run into this question with all of the PIDs that are "conditionally required" (DMX_START_ADDRESS, PARAMETER_DESCRIPTION, etc.). You can make a legitimate argument both ways.

In the real world, declaring extra PIDs in the list of supported parameters is unlikely to break any RDM Controllers. Controllers have to assume that new PIDs will be added in the future, so the extra information should just be ignored.

Thus I would suggest including the _DESCRIPTION PIDs in the list of supported parameters.
ericthegeek is offline   Reply With Quote
Old April 14th, 2014   #3
RenZO
Junior Member
 
Join Date: Apr 2014
Posts: 2
Default

Thank you ericthegeek, that makes sense
I would say it's the same for DMX_PERSONALITY_DESCRIPTION, which is not "conditionally required" in Table A-3 but should be, and I often see it in supported parameters.
RenZO is offline   Reply With Quote
Old April 14th, 2014   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

It is possible to support DMX_PERSONALITY without also supporting DMX_PERSONALITY_DESCRIPTION. This would be a poor design choice, and would require the user to lookup what each personality means in external documentation, but it is allowed by the the standard.

The reverse is also true, you can support DMX_PERSONALITY_DESCRIPTION without supporting DMX_PERSONALITY. This might be desirable it a responder that has only one personality and wants to give that personality a name (i.e. "Standard Mode").

I'd discourage implementers from using either of these corner cases (If you support one PID, you really should support the other), but those implementing controllers should consider this possibility.

Last edited by ericthegeek; April 14th, 2014 at 11:33 PM.
ericthegeek 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
Sensor Defintion/Support Parameters gthaliath RDM General Implementation Discussion 25 September 1st, 2016 09:38 AM


All times are GMT -6. The time now is 10:36 AM.


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