E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old June 3rd, 2015   #1
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default Non-ASCII Characters

When a responder is sent a string (for example DEVICE_LABEL) that contains a non-ASCII or non-printable character what should it do?

I can see several possible approaches: NACK it, accept it as is, filter out the non-printable characters.

Any thoughts on the best approach?
ericthegeek is offline   Reply With Quote
Old June 4th, 2015   #2
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default

My thoughts are more practical than conformal. Technically, I would suggest that it should respond with DATA_OUT_OF_RANGE. Having said, null character terminators are prevalent, and IMO, as a matter of practicality, should be handled as a special case.

In the case that a responder accepts 8 bit characters, then it then becomes non conformant, as it may either modify the data or return the same out of range data.

Null values apart, modifying the data is least desirable. NACK the most conformant, accepting as it, the most practical.
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old July 22nd, 2016   #3
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default

Hello, just a simple question about Text fields use.

In CURVE_DESCRIPTION pid and similar ones, can I send a string with always 32 characters and a NULL as a terminator instead of using the actual number of string characters in PDL?

Thank you
zano_villa is offline   Reply With Quote
Old July 22nd, 2016   #4
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default

A NULL is a character, so 32 + a NULL is not allowed in any situation.
One on the problems created by using a NULL, is that on sending 32 characters, your NULL will be lost which then generates inconsistency.

The correct answer is to send the correct string length, without any null termination.
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old July 22nd, 2016   #5
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default

Thank you for quick answer but I suppose I was not clear in my question, so I will report an example:

let's say that I want send the string "QUADRATIC" which has 9 characters.
I can send a message with the string "QUADRATIC" and PDL = 9 and it would be certainly ok.
Or I could send a message with the string "QUADRATIC",<0x00>,"abcdefghijklmnopqrstuv" and PDL = 32.
What about this second choice (see 10.1 of standard)?

Thank you
zano_villa is offline   Reply With Quote
Old July 22nd, 2016   #6
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default Corresponding to the Parameter Data Length

Section 10.1 states:
The Parameter Data Length shall accordingly be set to match the actual size of the text string being sent.

The statement covering what shall be done in the case that a NULL is encountered, as I often see, does not qualify the use of NULL characters as appropriate.

In my responder implimentations, I use null values to determine stored string length when shorter than 32, however, there is no need to return more characters that are available before the first NULL.
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old July 22nd, 2016   #7
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Yes, null termination of strings is allowed.

10.1 says:
Text fields shall terminate based on Parameter Data Length, however if a NULL is encountered then that shall also act as a terminator for the text field.

So, in your "QUADRATIC",<0x00>,"abcdefghijklmnopqrstuv" example, the receiver should display "QUADRATIC" properly.

Personally, I don't like null termination, I think length termination is more in keeping with the spirit of RDM. But given the number of C programmers in the world that are more comfortable with null termination, there's nothing wrong with using it.
ericthegeek is offline   Reply With Quote
Old July 22nd, 2016   #8
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default

Not sure I'm quite on the same page, the standard, as it is written, may not be entierly expicit.

If as is suggested, null termination is generally acceptable, then I would expect the relevant text to read something akin to

Text fields shall either terminate based on Parameter Data Length or when a NULL is encountered.

IMO The standard states that string lengths shall be PDL determined,
this being the correct approach. It then ads a caveat with the statement however, determining the appropriate treatment, in the case of a null character being encountered.

By using PDL length determined strings, there is no doubt that the implimentation will be compliant with the standard.
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old July 22nd, 2016   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I'd say Hamish is more correct here. There are requirements in 10.1 on both the Responder and the Controller.

This first sentence is the requirement for the Responder:

<QUOTE>
The Parameter Data Length shall accordingly be set to match the actual size of the text string being sent.
</QUOTE>

That clearly states that a Responder shall set it to the PDL.

The next part here is the requirements on a Controller:

<QUOTE>
Parsing of the string shall be length terminated corresponding to the Parameter Data Length field. Text fields shall terminate based on Parameter Data Length, however if a NULL is encountered then that shall also act as a terminator for the text field.
</QUOTE>

This clearly states that the controller receiving it shall expect it to be length terminated, but if it does happen to encounter a NULL then that shall also terminate it. This is meant to be more as an exception. Many controllers may handle it fine if you always send as 32 chars and Null terminate, however I'm certain that there will be some that will handle it incorrectly.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 22nd, 2016   #10
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

I'd say Hamish is more correct here. There are requirements in 10.1 on both the Responder and the Controller.

This first sentence is the requirement for the Responder:

Quote:

The Parameter Data Length shall accordingly be set to match the actual size of the text string being sent.
That clearly states that a Responder shall set it to the PDL.

The next part here is the requirements on a Controller:

Quote:

Parsing of the string shall be length terminated corresponding to the Parameter Data Length field. Text fields shall terminate based on Parameter Data Length, however if a NULL is encountered then that shall also act as a terminator for the text field.
This clearly states that the controller receiving it shall expect it to be length terminated, but if it does happen to encounter a NULL then that shall also terminate it. This is meant to be more as an exception. Many controllers may handle it fine if you always send as 32 chars and Null terminate, however I'm certain that there will be some that will handle it incorrectly.
__________________
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 03:43 PM.


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