Must a device support 32 charecters in DEVICE_LABEL?

[p_richart]

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

[prwatE120]

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

[p_richart]

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.

[sblair]

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.

[prwatE120]

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

[sblair]

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.