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 July 10th, 2014   #1
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default 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.
este_ is offline   Reply With Quote
Old July 21st, 2014   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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)?
ericthegeek is offline   Reply With Quote
Old July 28th, 2014   #3
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 179
Default

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.
prwatE120 is offline   Reply With Quote
Old August 1st, 2014   #4
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

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".
este_ is offline   Reply With Quote
Old August 11th, 2014   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

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.
ericthegeek is offline   Reply With Quote
Old August 14th, 2014   #6
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

Eric,

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




looks much better when adapted to the specific needs:




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:



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

Last edited by este_; August 14th, 2014 at 09:30 AM.
este_ 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
Filling Device Labels to 32 chars is an error? este_ RDM Interpretation Questions 14 June 13th, 2013 02:35 PM
Refreshing "parameter_description" ? theguenni RDM General Implementation Discussion 7 March 3rd, 2012 08:06 PM
Refreshing "parameter_description" ? theguenni RDM General Implementation Discussion 0 February 29th, 2012 02:36 PM
Slot Label Code anstein RDM General Implementation Discussion 1 August 10th, 2006 02:06 PM


All times are GMT -6. The time now is 02:52 AM.


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