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 November 6th, 2008   #1
p_richart
Junior Member
 
Join Date: Sep 2006
Location: Colorado Springs
Posts: 6
Default Must a device support 32 charecters in DEVICE_LABEL?

Hello,

Please verify or correct my interpretation of the PD field in DEVICE_LABEL.

I think if a device supports DEVICE_LABEL it must be able to accept and store no less than 32 characters.

OR

A controller must send a GET DEVICE_LABEL after a SET to see what was retained.

On p. 62, the spec states that the data fields for both GET and SET DEVICE_LABEL commands are variable up to 32 characters but does not state that a device must accept 32 characters.

I have encountered an actual implementation where the device will only save 16 characters. (perhaps a hold over from a draft version of the spec?) If it receives a SET DEVICE_LABEL with more than 16 characters it truncates the text and replies with an ACK. This response marginally valid since the device did store some of the data and there is no way for it to tell the controller how large a text label it does support. I don't think a NACK NR_PACKET_SIZE_UNSUPPORTED response is valid here since the buffer for RDM messages is not the limitation, just the amount of memory allocated for a device label. No other NACK reason seems to fit unless the controller sends a field with more than 32 characters to which the NACK NR_FORMAT_ERROR would apply.

Thanks - Patrick
p_richart is offline   Reply With Quote
Old November 6th, 2008   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Patrick

This sounds like out RDMLabpack - I guess you found the solo unit.

I must admit I thought I might have resonded with NACK - Data out of Range, but will have to check.

Please contact me directly for further details

Peter Willis
prwatE120 is offline   Reply With Quote
Old November 6th, 2008   #3
p_richart
Junior Member
 
Join Date: Sep 2006
Location: Colorado Springs
Posts: 6
Default

Actually it was not the Labpack. I found the solo but have not put it through all of it's paces yet.

The NACK with NR_DATA_OUT_OF_RANGE response has the benefit that the controller knows that the command was not entirely successful. However, the controller still must iterate with progressively fewer characters until the message is accepted and then remember how much each device type can handle.
p_richart is offline   Reply With Quote
Old November 6th, 2008   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Patrick,

Different draft versions handled this in different ways with different maximum numbers of characters until we finally settled on 32.

Some draft versions did max out on some text strings at 16 chars, so this could be a hold over from that which you found in someones implementation.

Strictly speaking if a device supports the message they are supposed to handle up to 32 chars. There will likely be cases such as you have found where they don't fully implement it.

As always, a Controller that is somewhat flexible and can roll with the punches will obviously be a more successful product in the marketplace.

One thing you might try when getting a NACK out of range response is to do a GET: DEVICE_LABEL and see if it stored the portion that it could fit. I could see an implementation where someone couldn't fit it all but stored what they could anyway and then still sent a NACK back since it didn't store it all. Would be interesting to see how exactly it was implemented.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old November 7th, 2008   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

I cannot find anywhere in the standard where we mandate a requirement to support 32 characters for a SET:DEVICE_LABEL.

I dont disagree that it would be nice from a controllers point of view for all devices to act the same, and accept the full number of characters - but that is not yet in the standard!

The RDMLabpack only accepts a 16character device label, and uses NACK_DATA_OUT_OF_RANGE to reject larger strings. Some of our other products behave in a similar manner because of restricted non-volatile memory.

I would envisage supporting the 32characters whereever possible, but I would not personally recommend ACK'ing a message unless I was going to save exactly what I had been given.


Peter Willis
prwatE120 is offline   Reply With Quote
Old November 7th, 2008   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Peter, the SET message states that the range is from 0-32 characters. There is no provision or warning in the text anywhere that the device may accept less than that.

As I said there will be devices out there that probably can't handle the full 32 chars for whatever reason and a good controller implementation should be flexible to roll with the punches.
__________________
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

Similar Threads
Thread Thread Starter Forum Replies Last Post
DMX/RDM support in new SBC tracyu RDM Marketplace Discussion 0 June 2nd, 2008 05:57 PM
Broadcasting to a device model sjackman RDM General Implementation Discussion 3 January 21st, 2008 12:30 PM
Device Models Andy Macdonald RDM Interpretation Questions 4 October 17th, 2006 05:57 AM


All times are GMT -6. The time now is 04:45 AM.


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