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 May 3rd, 2013   #1
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default Filling Device Labels to 32 chars is an error?

When applying the RDM responder tests, I get an error message when filling the DEVICE_LABEL with spaces until 32 chars are reached (SET "label" will then produce a GET "label ". Since spaces are ASCII chars and E1-20 does not mandate to cut trailing spaces I cannot see any reason why this implementation should conflict with the existing standard. We found filling labels with spaces extremely helpful since some controllers do not manage their text windows properly and this surely prevents displaying "lost" characters from previous longer labels. The added transmission time is neglegible.

Did I miss something ?
Eckart
este_ is offline   Reply With Quote
Old May 3rd, 2013   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

Are you referring to the OLA RDM Responder Tests? Can you post the exact error message you're getting, including the relevant log files?

Filling a label with all spaces is permissible.
ericthegeek is offline   Reply With Quote
Old May 4th, 2013   #3
Simon Aspland
Junior Member
 
Join Date: Apr 2012
Posts: 1
Default

If I understand correctly, your device is changing the label it receives in a set command, and padding it out to 32 characters with spaces?

This would cause an issue in the Responder tests as it will be checking that it gets the same label from the device that it set it to.
To the Responder tests, the label with extra spaces wouldn't match what it sent, and it would assume the device is not storing it correctly.

As someone programming a controller I'd rather have the label returned unchanged, as extra spaces on the end would mess up the display of the label for me.

If other controller manufacturers are having issues with displaying labels less than 32 characters long, it might be worth contacting them to ask them to sort that out.
Simon Aspland is offline   Reply With Quote
Old May 6th, 2013   #4
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

Yes, I am referring to the OLA RDM responder tests. Enclosed pls find the report for said test (file:screenshot.jpg).

Again, I object this should be rated as error. Looking at the entries of a slot label with and without padded spaces, here are the results (see fig1.png) and I bet, you will not be able to guess which one comes with extra spaces. To the user, it's the same- that is, what counts. It's not up to me to please the computer, the computer has to please me!

The test should reveal "Passed", eventually add a note "format changed".

When "extra spaces on the end mess up the display of the label" there may be room for improvement on your side. A responder should be able to handle the worst data packets generated by a controller at all times- in terms of timing, formatting and data contents. This is our guideline to build robust and reliable equipment. On the other hand, I expect a controller to accept any type of response conforming to the existing standard - and I cannot see any reason to distinguish between an ASCII character being a space and an ASCII character not being a space. High-level languages have predefined functions to truncate text; microprocessors come with enough computing power to do so. Ty to build your application to be as generous as possible and to accept all styles!

The OLA RDM responder test is a wonderful time-saving application; thanks to anybody involved to make this possible. As it's getting to be accepted as some sort of standard test we should sort out edges like this text issue to make it even better.
Attached Images
File Type: jpg screenshot.jpg (72.7 KB, 4392 views)
File Type: jpg Fig1.jpg (18.3 KB, 4269 views)
File Type: jpg Fig2.jpg (19.6 KB, 4247 views)
este_ is offline   Reply With Quote
Old May 6th, 2013   #5
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

A responder shouldn't be manipulating the labels set by a controller (except for truncating which is allowed by the standard). Spaces may or may not be significant when the label is shown to the user - it depends on how the controller presents the data.

este_ : I realize you're trying to work around a bug in a controller, but in doing so you're likely to trigger strange behavior in other consoles. It would be better just to try and fix the first one.

Simon N
(Author of the RDM Responder Test)
nomis52 is offline   Reply With Quote
Old May 6th, 2013   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

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.
ericthegeek is offline   Reply With Quote
Old May 7th, 2013   #7
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default 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
hamish is offline   Reply With Quote
Old June 13th, 2013   #8
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default 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?
este_ is offline   Reply With Quote
Old June 13th, 2013   #9
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 56
Send a message via Skype™ to hamish
Default 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
hamish is offline   Reply With Quote
Old June 13th, 2013   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

Hamish is right. Because of the way the language in the standard is written, you can't "NACK" a request with a Discovery Command Class. NACK can only be used with GET and SET requests.

Also, this means that you can't NACK a request with an unknown command class.

This wasn't really the intent. The intent of the standard was to simplify discovery by requiring that a responder always handle discovery requests immediately and not be slowed down/complicated by NACK, ACK_TIMER or ACK_OVERFLOW responses. But because of the way the standard is written, it effectively means you can't NACK a corrupt discovery request. Your only valid choice is to ignore the request.

It's common to see responders that will NACK invalid discovery requests, so controllers should be able to handle that condition. But if you stick with the language as it's written in the standard, NACKs are not allowed.
ericthegeek is offline   Reply With Quote
Old June 13th, 2013   #11
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Hamish and Eric are correct. I'm really not even sure why there should be a case you would need to NACK any of the Discovery commands.

ACK_TIMER is absolultely out for Discovery Commands. No good would come from allowing that.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 13th, 2013   #12
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

"I'm really not even sure why there should be a case you would need to NACK any of the Discovery commands." -> This might be the only way to let the controller know something was incorrectly formatted.

"It's common to see responders that will NACK invalid discovery requests, so controllers should be able to handle that condition." Yes!

"The intent of the standard was to simplify discovery... and not be slowed down by NACK responses." Right, but generating a less than 2ms response will not slow down the discovery process, when compared to a timeout.

"Table 6-7: Response Type Field Allowable Values from Responder". That's convincing. My resolution is simple: I'll let the controller talk rubbish and shut up.
este_ is offline   Reply With Quote
Old June 13th, 2013   #13
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Have you seen a controller actually sending improperly formatted Discovery commands? Specifically a Mute/UnMute? (There is no way a Branch message could ever be NACK'd)

If a Mute/UnMute is improperly formatted I'm not sure how it would ever be able to discover *anything*.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 13th, 2013   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 379
Default

> Right, but generating a less than 2ms response will
> not slow down the discovery process, when compared
> to a timeout.

When I talk about speeding up discovery, it's not a really matter of saving a millisecond or so on a timeout vs. a short response. It's about the responder always being ready and able to handle discovery requests. Having to deal with an ACK_TIMER or a BUFFER_FULL condition would really complicate discovery on a large rig. That was the intent anyway.

The way it was written, the text also disallows NACK'ing invalid or corrupt packets (as you might see if there is noise on the DMX wire). If should have been written another way to better reflect the intent, and to allow NACK'ing invalid requests, but at this point we're kinda stuck with it as it's written.

Fortunately, it's a non-issue from what I've seen in real-world systems. Many people first discover this issue when they run the OLA Responder Tests...
ericthegeek is offline   Reply With Quote
Old June 13th, 2013   #15
sblair
Administrator
 
Join Date: Feb 2006
Posts: 438
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by ericthegeek View Post
If should have been written another way to better reflect the intent, and to allow NACK'ing invalid requests, but at this point we're kinda stuck with it as it's written.

Fortunately, it's a non-issue from what I've seen in real-world systems. Many people first discover this issue when they run the OLA Responder Tests...
We're only talking about Mute/UnMute here since it really isn't possible to NACK a BRANCH even if we wanted to.

Since Discovery works on a positive acknowledgement system if the controller doesn't get an ACK back to a Mute/UnMute then it sends it again. That covers the noise/corrupt message issue and is even written into the pseudo-code in the standard to try multiple times before moving on.

If the controller is sending improperly formatted messages it's likely not going to work right with anything as the Mute/UnMute commands coming from the console are identical for all devices.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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 01:14 AM.


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