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)
-   -   CURVE supported : implies CURVE_DESCRIPTION in supported parameters ? (http://www.rdmprotocol.org/forums/showthread.php?t=1205)

RenZO April 14th, 2014 03:04 AM

CURVE supported : implies CURVE_DESCRIPTION in supported parameters ?


Then, I also have the PIDS :

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 :
* Support required only if CURVE is supported.

So what to do please ?


ericthegeek April 14th, 2014 10:36 AM

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.

RenZO April 14th, 2014 02:24 PM

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.

ericthegeek April 14th, 2014 04:29 PM

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.

All times are GMT -6. The time now is 08:46 PM.

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