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)
-   -   New PID "Slot Labels" (http://www.rdmprotocol.org/forums/showthread.php?t=1207)

este_ July 10th, 2014 01:56 PM

New PID "Slot Labels"
I'd like to ask for a PID SLOT LABELS. Wie can change The device Label, but we Can not set Individual Slot labels. This may Not be of interest for a moving light, but for contactors, Protocol converters and more. Simply allow a SET for The Existing PID 0121. See our implementation (PID 8121) on our Website http://www.soundlight.de/techtips/dm...m_commands.htm.

ericthegeek July 21st, 2014 10:57 AM

I'm uncomfortable re-defining the behavior or SLOT_LABEL.

Could this be handled by using sub-devices and DEVICE_LABEL (which is already user settable)?

prwatE120 July 28th, 2014 10:12 PM

On our products, SLOT_LABELS are dependent on the currently selected PERSONALITY.

I have no issue with a new command to SET: SLOT_LABEL_USERTEXT.

It should take as arguments both the slot offset AND the personality that the text was to apply to.

I would prefer that the usertext was returned in response to an ordinary GET:SLOT_LABEL if it had been set, but if not, a default text was returned, as you would get with the existing GET:SLOT_LABEL PID

I can see the application on our general purpose relay drivers : we provide default text as Output1,Output2 etc, but once the card is applied to a specific task, the user would like to see Relay1, Fan2, Lamp3 etc.

Eric - I would prefer NOT to require the use of sub-devices in order to allow this feature.

este_ August 1st, 2014 12:07 PM

Peter, thanks for your comments which I appreciate.

You're right, choosing sub-device labels to circumvent this issue is not just a workaround; as soon a sub-device is using more than one slot it would no longer be possible to do it this way. The goal is to create a fader label, not a device label. I'm uncomfortable using sub-devices; that's why we disable sub-devices by default and let the user enable them (using our PID FF0F) when he feels this might make sense in his installation. Enabling sub-devices by default will always call for BLOCK_ADDRESS, which is badly supported (see the PID popularity contest, http://www.rdmprotocol.org/rdm-pid-popularity/ ) and cannot replace the START_ADDRESS PID. And: I know some guys, who even "don't like the BLOCK_ADDRESS PID".

You're also right, that slot labels could differ when the personality is changed. But there is no need to give the personality number when writing slot labels; simply set the personality, write the slot label and re-set the personality if needed. The responder should be smart enough to write personality-specific slot labels associated to a specific personality (or personalities..) if the responder supports this. Thus I do not feel there is a need to make things more complicated by adding additional parameters.

It would be enough to allow a SET for SLOT_LABELS.

Basically, there is no new command needed.
There is no new syntax needed.
There is no new format needed.

In case the responder does not feature write capabilities, it should NACK the request. That's all. If responders can't do that (because they did not know a SET SLOT_LABELS was possible), the command will time out. Same result.

I can't see any problem. So "let's make the world a little bit smarter".

ericthegeek August 11th, 2014 07:57 PM

From my perspective, setting something like slot labels is done by the system integrator or other technically competent person, and it's done only a few times in the product's life. It really belongs in the manufacturer-specific PID range. Then, the manufacturer can do whatever makes sense for their product and add extra parameters as needed.

You could also argue that the manufacturer's name should be settable since one company may install a driver board from another company. Again, this is not an end user function. As the end user sees it, these parameters are read-only to describe the fixture you are working with.

este_ August 14th, 2014 09:26 AM


you name the problem: you are talking of fixtures, I'm not talking of fixtures at all. I am talking of multifunctional responders, such as dimmer packs, LED drivers, relays etc.

When talking about fixtures, you're right: slot use will be defined by the manufacturer. At last, a gobo wheel will be a gobo wheel and a strobe will be a strobe.

With multifunction devices, things are different. It's the system integrator or it's even user, who defines the slot function.

The standard layout

http://www.soundlight.de/intern/Relay Fader unnamed.png
http://www.rdmprotocol.org/forums/f:...er unnamed.png

looks much better when adapted to the specific needs:

http://www.soundlight.de/intern/Relay Fader named.png
http://www.rdmprotocol.org/forums/f:...ader named.png

and a 4-channel LED driver, labelled SLOT1 / SLOT2 / SLOT3 / SLOT4 will be more user-friendly when labelled RED / GREEN / BLUE / WHITE. Unfortunatele there are uses which would require
R / G / B / A, or WARM WHITE / COLD WHITE, or else. In a museum, it could make sense to label the slots "VITRINE", "BACKLIGHT", "PICTURE", "FRAME". We have other uses, e.g. in planetariums, requiring other labels. It may be impossible for a manufacturer to provide all possible combinations, and on the other hand it may not be the best solution to use manufacturer-specific commands to do so (we can, we have a PID), but we feel it's a general problem and should not be solved individually, but generally.

Even the often cited dimmer pack labelled DIMMER1 / 2 / 3 / 4 / 5 / 6 may look much more user-friendly if you can read:

http://www.rdmprotocol.org/forums/f:...ader named.pnghttp://www.soundlight.de/intern/Dimmer Fader named.png

In former times, individual labelling was done using gaffa tape glued onto the light console. Now that RDM can do away with the ladder, I suggest we give it a chance to do away with gaffa as well.

Eckart :)

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

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