Filling Device Labels to 32 chars is an error? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · May 6th, 2013

I see what you're talking about now: There's a responder that will accept any length Label in a SET command, but when the controller does a GET for the Label, the responder always returns 32 characters with the extra length padded out with ASCII Spaces.

Personally, I don't really like this behavior, and I think it's legitimate for the tests to flag it as an error. The test is sending specific data, and when it asks for the same data back it's getting something different. Even if this behavior is deliberate, it's something that the person running the tests would want to be aware of.

We can argue that perhaps this specific case should be a Warning and not an Error, but it's unusual behavior that should be highlighted.

If there are specific controllers out there that aren't handling strings properly, those controllers need to be fixed. One of the quirks of RDM that strings can be both length terminated, and null terminated. Some software developers (especially developers that are used to C-style strings) miss this detail.

hamish · May 7th, 2013

This is my take on it.
I see nothing in the book to mandate that a responder must return the same label as was set. To suggest this rule would cause problems with PIDs such as RESET_DEVICE. Also consider the multi-controller environment of E1.33.

No, this is categorically an Advisory condition.
In the good practice guide, I agree that the better implementation is to return a string length truncated to the capability of the responder. A truncated string should also be reported as an Advisory in a test condition.

Hamish

este_ · June 13th, 2013

Thanks all for your valuable comments.

I'd like to add another issue, which was this error message:

UnMuteDeviceWithData

UnMute device info with param data.
Category: Network Management
Result: Failed
Debug
Output:
DISCOVERY: pid: DISC_UNMUTE (0x0003), sub device: 0, data: 'x'
Response: RDMResponse:, NACK Format Error, PID = 0x0003

Failed: expected one of:
RDM_TIMEOUT,
RDM_PLUGIN_DISCOVERY_NOT_SUPPORTED

As you can see, I'm doing a NACK Format Error which should be right since the format of the command does not meet the requirements of the standard. Creating a Timeout instead would not even be the second best choice since we'd be losing valuable transmission time. Any suggestions?

hamish · June 13th, 2013

Hi Eckart

The information you require to answer your question can be found in table
Table 6-7: Response Type Field Allowable Values from Responder

May 7th, 2013	#2
hamish Member Join Date: Apr 2009 Location: Dartmoor, Devon, England Posts: 56	Advisory, not Error This is my take on it. I see nothing in the book to mandate that a responder must return the same label as was set. To suggest this rule would cause problems with PIDs such as RESET_DEVICE. Also consider the multi-controller environment of E1.33. No, this is categorically an Advisory condition. In the good practice guide, I agree that the better implementation is to return a string length truncated to the capability of the responder. A truncated string should also be reported as an Advisory in a test condition. Hamish __________________ ______________________________________________ Hamish Dumbreck

June 13th, 2013	#3
este_ Junior Member Join Date: Jan 2010 Location: Germany Posts: 24	Mute / Unmute to create a Timeout? Thanks all for your valuable comments. I'd like to add another issue, which was this error message: UnMuteDeviceWithData UnMute device info with param data. Category: Network Management Result: Failed Debug Output: DISCOVERY: pid: DISC_UNMUTE (0x0003), sub device: 0, data: 'x' Response: RDMResponse:, NACK Format Error, PID = 0x0003 Failed: expected one of: RDM_TIMEOUT, RDM_PLUGIN_DISCOVERY_NOT_SUPPORTED As you can see, I'm doing a NACK Format Error which should be right since the format of the command does not meet the requirements of the standard. Creating a Timeout instead would not even be the second best choice since we'd be losing valuable transmission time. Any suggestions?

June 13th, 2013	#4
hamish Member Join Date: Apr 2009 Location: Dartmoor, Devon, England Posts: 56	Allowed Responses Hi Eckart The information you require to answer your question can be found in table Table 6-7: Response Type Field Allowable Values from Responder __________________ ______________________________________________ Hamish Dumbreck

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Hybrid Mode Switch to Threaded Mode

May 6th, 2013	#1
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	I see what you're talking about now: There's a responder that will accept any length Label in a SET command, but when the controller does a GET for the Label, the responder always returns 32 characters with the extra length padded out with ASCII Spaces. Personally, I don't really like this behavior, and I think it's legitimate for the tests to flag it as an error. The test is sending specific data, and when it asks for the same data back it's getting something different. Even if this behavior is deliberate, it's something that the person running the tests would want to be aware of. We can argue that perhaps this specific case should be a Warning and not an Error, but it's unusual behavior that should be highlighted. If there are specific controllers out there that aren't handling strings properly, those controllers need to be fixed. One of the quirks of RDM that strings can be both length terminated, and null terminated. Some software developers (especially developers that are used to C-style strings) miss this detail.