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 December 20th, 2006   #1
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default 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.
prwatE120 is offline   Reply With Quote
Old December 26th, 2006   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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

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
sblair is offline   Reply With Quote
Old January 20th, 2007   #4
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 is offline   Reply With Quote
Old January 20th, 2007   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

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
prwatE120 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


All times are GMT -6. The time now is 09:02 AM.


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