E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Interpretation Questions (http://www.rdmprotocol.org/forums/forumdisplay.php?f=5)
-   -   Filling Device Labels to 32 chars is an error? (http://www.rdmprotocol.org/forums/showthread.php?t=1161)

este_ May 3rd, 2013 04:42 AM

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 :confused:?
Eckart

ericthegeek May 3rd, 2013 08:23 AM

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.

Simon Aspland May 4th, 2013 05:36 PM

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.

este_ May 6th, 2013 03:03 AM

3 Attachment(s)
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.

nomis52 May 6th, 2013 10:25 AM

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)

ericthegeek May 6th, 2013 10:32 AM

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 10:19 AM

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

este_ June 13th, 2013 07:48 AM

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?

hamish June 13th, 2013 09:10 AM

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

ericthegeek June 13th, 2013 10:24 AM

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.

sblair June 13th, 2013 12:34 PM

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.

este_ June 13th, 2013 01:22 PM

"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.

sblair June 13th, 2013 02:08 PM

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*.

ericthegeek June 13th, 2013 02:17 PM

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

sblair June 13th, 2013 02:35 PM

Quote:

Originally Posted by ericthegeek (Post 2597)
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.


All times are GMT -6. The time now is 09:00 PM.

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