PID = SUPPORTED_PARAMTERS / PARAMTER_DESCRIPTION question - E1.20 RDM (Remote Device Management) Protocol Forums

prwatE120 · October 1st, 2009

Bernt

In section 10.6.3 we clearly state that a GET:DMX_START_ADDRESS request sent to a root or sub-device that has a footprint of zero shall return a value of 0xFFFF.

One could argue that NACKing any GET/SET DMX_START_ADDRESS with a NR_DATA_OUT_OF_RANGE is still supporting the PID, and our definition in table A-17 is entirely consistent with having a footprint of zero.

(definition is "Value out of range or not supported)

This would be preferable to a NACK:NR_UNKNOWN_PID as it avoids any argument that you haven't supported what many expect to be a Mandatory Pid.

My preference would be for us to remove the "option" in Table A-3 and point people back to the "shall" statement in 10.6.3, and add clarification on how to NACK the SET: request.

Peter

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Mute Response Question	sondericker	RDM Interpretation Questions	13	January 21st, 2007 10:14 AM

October 1st, 2009	#8
prwatE120 Task Group Member Join Date: Jun 2006 Posts: 181	Bernt In section 10.6.3 we clearly state that a GET:DMX_START_ADDRESS request sent to a root or sub-device that has a footprint of zero shall return a value of 0xFFFF. One could argue that NACKing any GET/SET DMX_START_ADDRESS with a NR_DATA_OUT_OF_RANGE is still supporting the PID, and our definition in table A-17 is entirely consistent with having a footprint of zero. (definition is "Value out of range or not supported) This would be preferable to a NACK:NR_UNKNOWN_PID as it avoids any argument that you haven't supported what many expect to be a Mandatory Pid. My preference would be for us to remove the "option" in Table A-3 and point people back to the "shall" statement in 10.6.3, and add clarification on how to NACK the SET: request. Peter