|
RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard. |
|
Thread Tools | Search this Thread | Display Modes |
December 20th, 2006 | #1 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
Get_Parameter_Description 10.4.2
In the response to this we require a declaration of the "type" of data described by the specified PID as enumerated by Table A-12.
But Table A-12 is clearly labelled as associated with SENSORS. Why are we using Table A-12 if my specified PID (which I am trying to describe) has nothing to do with Sensors. What do we think the required entry should be if my PID sets/gets data for an internal configuration location in my EEprom? I have posted this firstly to the task group to avoid confusing the masses - once we have a task group view it may be better to make this thread public. |
December 26th, 2006 | #2 |
Administrator
|
I'm not sure why it points to A-12. I would say just set it to SENS_OTHER or use something from the Proprietary range.
__________________
Scott M. Blair RDM Protocol Forums Admin |
January 19th, 2007 | #3 |
Administrator
|
There was no logical reason the Task Group can determine that this field was in this PID. The best option is to set that field to SENS_OTHER as it is fairly meaningless in the context of PARAMETER_DESCRIPTION.
__________________
Scott M. Blair RDM Protocol Forums Admin |
January 20th, 2007 | #4 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
Just a note that this was discussed at the Jan 19th 2007 Task group meeting in Dallas and that Scott's response reflected the consensus of the group at that time.
Peter Willis |
January 20th, 2007 | #5 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
The use of this PID is likely to be rather limited, as it currently cannot properly describe a very simple PID.
For example : we have added to our responders the ability to control the state of a POWERON_SELFTEST feature -a flag held in non-volatile storage and requiring user selection. The GET: PID has no need for any data and so has a PDL=0x00 It retrieves the current state of the flag. The SET: PID has a one byte argument 0 or 1 to act as the state selection, so the PDL is 0x01, and the allowed data is 0 or 1. This is similar to many standard PIDs already featured in the standard. Unfortunately the fields associated with the current PARAMATER_DESCRIPTION PID do not allow for different GET/SET PDL declarations. In my view we should withdraw this PID and replace it with one that allows declaration of (a) whether it supports GETs and SETs as per Table A-16 (b) the GET:PDL and GET: Data Type as per Table A-15 (c) the SET:PDL and SET: Data Type as per Table A-15 (d) and optional MAX GET and MAX SET Data value (32bit) to be used ONLY if declared data type is Byte/Word or DWord as per Table A-15 (e) an optional text string description. Peter Willis |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|