|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
|
Thread Tools | Search this Thread | Display Modes |
|
April 14th, 2014 | #1 |
Junior Member
Join Date: Apr 2014
Posts: 2
|
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. |
April 14th, 2014 | #2 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
April 14th, 2014 | #3 |
Junior Member
Join Date: Apr 2014
Posts: 2
|
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. |
April 14th, 2014 | #4 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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 15th, 2014 at 12:33 AM. |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sensor Defintion/Support Parameters | gthaliath | RDM General Implementation Discussion | 25 | September 1st, 2016 10:38 AM |