|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
July 10th, 2014 | #1 |
Junior Member
Join Date: Jan 2010
Location: Germany
Posts: 24
|
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.
|
July 21st, 2014 | #2 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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)? |
July 28th, 2014 | #3 |
Task Group Member
Join Date: Jun 2006
Posts: 181
|
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. |
August 1st, 2014 | #4 |
Junior Member
Join Date: Jan 2010
Location: Germany
Posts: 24
|
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". |
August 11th, 2014 | #5 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
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. |
August 14th, 2014 | #6 |
Junior Member
Join Date: Jan 2010
Location: Germany
Posts: 24
|
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 10:30 AM. |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
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 03:35 PM |
Refreshing "parameter_description" ? | theguenni | RDM General Implementation Discussion | 7 | March 3rd, 2012 09:06 PM |
Refreshing "parameter_description" ? | theguenni | RDM General Implementation Discussion | 0 | February 29th, 2012 03:36 PM |
Slot Label Code | anstein | RDM General Implementation Discussion | 1 | August 10th, 2006 03:06 PM |