E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Subdevice labelling question (http://www.rdmprotocol.org/forums/showthread.php?t=1170)

berntd July 30th, 2013 07:53 PM

Subdevice labelling question
I hope this forum is still active...

I have a device with subdevices (channels of the root device).

The root supports DEVICE_LABEL (GET SET) but my subdevices do not support that.

The subdevices support DEVICE_MODEL_DESCRIPTION which is basically "Sub1" "Sub2" etc.

I have now noticed that on an ETC console, they correctly find the root as well as the subdevices but in the list, there is no visible link between the root and subdevices so it become really difficult to identify which subdevice belongs to which root. They do not seem to display it a root/sub tree but rather as a long list.

I would like to improve my device and I have the following ideas but I am not sure if those are the best way.

1) I can start supporting DEVICE_LABEL for the subdevices with GET only and give the same label as for the root.

I am not sure if I can have it as GET only as the spec wants GET and SET for that PID.

2) I could massage the DEVICE_MODEL_DESCRIPTION for each subdevice to have a merged version of the root DEVICE_LABEL + "Sub1" etc.

The problem there is that the total string length can exceed the allowed characters.

Maybe someone else has someinput or a good suggestion?

Best regards

sblair July 30th, 2013 08:10 PM


We're still alive and kicking here! First off, you can implement a GET_COMMAND only without allowing a SET_COMMAND for a given PID. You'll notice Table A-3 states "Get Allowed / Set Allowed", not required.

Given you're trying to overcome the limitations of someone else's implementation I would probably go that route rather than changing the Device Model Description, as what you suggested there would go against the requirements in the standard that for a given Device Model ID that the Device Model Description is always identical. The intent with that is that we explicitly didn't want to have controllers pulling redundant messages from every device on the network when they are all the same.

I would also suggest getting in contact with the folks at ETC on what would help make their implementation more usable. I'm not certain how they are dealing with the same issue themselves as it would seem they would have the same challenges with representing their own products.

berntd July 30th, 2013 09:06 PM


Thanks for the reply!
Good to see that things are still active!
It has been quite a while since I worked on RDM so everything has gone rusty

It has been so long that I can't even remember your name - sorry :eek:

Now, how does the controller get told that I will only supporting GET for a command?

I know I have to respond with UNSUPPORTED_COMMAND_CLASS for SET but I can't remember if I have to tell the controller somewhere that I only support GET?

Best regards

sblair July 30th, 2013 09:14 PM

There's nothing you need to do to alert the controller in advance. As you mentioned you just NACK any SET_COMMANDs with the UNSUPPORTED COMMAND CLASS reason.


berntd July 30th, 2013 09:16 PM

Thanks Scott.

We will also be contacting ETC to see what they think.

Best regards

ericthegeek August 1st, 2013 10:18 AM

I have seen a number of responders that support GET for DEVICE_LABEL on Sub-Devices, but that don't allow you to SET it.

For example, the Root has a Label that can be both GET and SET, but each sub-device has a Label like "Channel 1" that can only bet read with GET. When you try to SET the Sub-Devices's label it will "NACK Unsupported Command Class"

berntd August 1st, 2013 04:24 PM


I have added the support for DEVICE_LABEL on GET with the subdevices.

I am interested in what Eric wrote in that he has seen the labels being "Channel 1" etc. I have this but I have used the DEVICE_MODEL_DESCRIPTION for that purpose.

I now wonder if I should change again and move the "Sub1" etc to the subedevice label rather than the model description and merge it with the root label?

More concerning is that another manufacturer does not support subdevices at all and now one of our users is unhappy that he can't use our unit on their controller :-(

To fix it from our side, I would have to redo the complete RDM implementation and not use subdevices at all. I have no idea how to do that as we need individual control of the parameters of each channel ie DMX personalities etc.

Best regards

sblair August 1st, 2013 04:44 PM

Best thing to do is put pressure on the controller manufacturer to implement sub-device support!

Does each channel have a different DEVICE_MODEL_ID if the DEVICE_MODEL_DESCRIPTION is different? It's really not a good idea to have different labels for the same ID.

berntd August 1st, 2013 05:16 PM

Hi Scott

There is only 1 single model ID for the whole unit.HOwever, the DEVICE_MODEL_DESCRIPTION is different for each subdevice at the moment.

Should I change it?
I could stop supporting DEVICE_MODEL_DESCRIPTION for the subdevices and move that infor into the DEVICE_LABEL as mentioned before.


sblair August 1st, 2013 05:21 PM

I would move it to DEVICE_LABEL. There is an expectation that for a given Model ID# for a root or a sub-device that the Device Model Description will always be the same. This would cause problems for you because a controller would fetch the DEVICE_INFO for the subdevices and see they are all the same Model ID# and then only fetch a single Device Model Description assuming them all to be the same.

There is no expectation with Device Label of any two ever being the same.

berntd August 1st, 2013 05:31 PM

Thanks Scott

Whould the model ID for each subdevice be the same as for the root device?

berntd August 1st, 2013 05:53 PM

Hi again

Ok, I have changed it so the MODEL_DESCRIPTION is not the same for all subdevices and the DEVICE_LABEL differs.

Now, the Enttech USB Pro shows me the same MODEL_DESCRIPTION as expected but it also shows the same DEVICE_LABEL for all as the root.

Now I can't see any difference at all from subdevice to subdevice.

Oh Man!:confused:


sblair August 2nd, 2013 12:33 AM


The Enttech RDM Controller software is useful for some things when doing development, but it is far from being a benchmark controller implementation.

The important thing here is going to be how it behaves in regards to the controllers you're most likely to encounter with customers....

berntd August 15th, 2013 11:13 PM

Hello again

One more question...

My subdevice labels (DEVICE_LABEL) are linked to the root label + some extension.
Do I need to generate QUEUED_MESSAGE for each subdevice DEVICE_LABEL when the root label has been changed by the controller?

In additon, how do queued messages from subdevices work?
Does the controller requesst a GET QUEUED_MESSAGE adressed to the root (Sub-Device = 0x0000) and then in the reply, the device set the Sub-Device to the subdevice that has queued the message?

Best regards

All times are GMT -6. The time now is 05:14 PM.

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