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 January 7th, 2011   #1
R.Schladör
Junior Member
 
Join Date: Oct 2010
Posts: 2
Question Usage of PARAMETER_DESCRIPTION for manufacturer-specific PIDs

Hi!
I am trying to implement some manufacturer specific PIDs to my product but I ran in some trouble when I came to the PARAMETER_DESCRIPTION for these PIDs.

I would like to include my special PIDs in the SUPPORTED_PARAMETERS message and I also want to supply a PARAMETER_DESCRIPTION message for each PID to enable the user to work with the new functions.

My Problem:
The PARAMETER_DESCRIPTION response has a number of fields defined that should describe the details for the parameter. This will work if a single attribute with a defined value range shall be described.
But how do I describe more complex parameters with multiple attributes of different sizes (different data types) in the description?

For Example:
If I would like to implement a parameter with a similar structure as the SLOT_INFO PID, how can I represent such a data structure in the PARAMETER_DESCRIPTION response?

Another good example would be the PERSONALITY PID where GET and SET has a different number of attributes.
(GET_PERSONALITY responses with current Personality and number of Personalities, while SET_PERSONALITY has only the parameter (current) Personality)
R.Schladör is offline   Reply With Quote
Old January 7th, 2011   #2
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 179
Default

I concur with your view that the current PARAMETER_DESCRIPTION is basically broken and of limited use. I think we need to invent a new one and also seperate the TEXT description of the Manf Spec PID from the field descriptions. Often you only need the text description, so that the user can refer to the manual or manufacturer for the detail.

Peter
prwatE120 is offline   Reply With Quote
Old January 7th, 2011   #3
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 179
Default

I have rasied this in the past within the TASK GROUP section of this forum, but until we re-opne the main document for an unpgrade, there has been little interest in resolving this problem.

Peter
prwatE120 is offline   Reply With Quote
Old January 7th, 2011   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 353
Default

Unfortunately there's no way to come up with a description format that will work for every possible MFG specific PIDs. The PARAMETER_DESCRIPTION format works well for simple PIDs that have one, straightforward setting. There's enough information for a controller to put up a knob or slider that the user can adjust. When you get into any kind of packed data structure or complex setting it just won't work.

Your best bet, when possible, is to break your complex data structure down into several simpler PIDs that can be described within the structure available.

If you can't do that, then you just have to document it in the manual. The question then becomes do you include it in the list of supported parameters? If you include it, and implement PARAMETER_DESCRIPTION, you can at least send the human readable string. Unfortunately there's no "Not declared" option for the "PDL Size" field. If you don't mind violating the standard slightly you can put dummy values in, just enough to let the user read the string. But, some controllers that strictly enforce the values given in PARAMETER_DESCRIPTION may not let the user send what they need to send.

Last edited by ericthegeek; January 7th, 2011 at 11:19 AM. Reason: Spelling error
ericthegeek is offline   Reply With Quote
Old January 7th, 2011   #5
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 52
Send a message via Skype™ to hamish
Default Alternative suggestions?

Quote:
Originally Posted by ericthegeek View Post
But, some controllers that strictly enforce the values given in PARAMETER_DESCRIPTION may not let the user send what they need to send.
This is exactly the reason I've not implemented this. For every user of the control software that I'm aware, the facility for the vendor commands would become useless, not that I'd rate it as being user friendly in any case.

The upshot is that users have to write their commands in clingon (Hex to us). I'm actively looking at work rounds for this, based on a suggestion for data masking / input fields. If I get anything workable, I'll post it back here.


Hamish
hamish is offline   Reply With Quote
Old January 7th, 2011   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

As has been said, the current PARAMETER_DESCRIPTION PID was only intended to handle a single data value and even at that it is of limited use.

A reminder that you only need to use the PARAMETER_DESCRIPTION PID if you're trying to publicly expose a manufacturer-specific PID to others. If you are just creating it for your own use, then you don't even need to bother with trying to describe it as you'll already know the data structure for it.

If you're trying to make it publicly accessible to other controllers, then I'd try rethinking it and breaking it down into multiple PIDs that each handle a single data value.

Not the best solution, but those are the current workarounds.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old January 15th, 2011   #7
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

As a couple of you know I've come up with a different approach to this problem - the online PID definition index: http://rdm.openlighting.org/

This provides a structured way of describing a PID's format in a much richer way than the PARAMETER DESCRIPTION PID supports. Think of it as DDL for RDM.

The big advantage here is that the data format isn't tied to the RDM specification.

I'm happy to export the data in other formats (XML, JSON etc.) for other people to use in their controllers. Other programs can check the last update time by hitting http://rdm.openlighting.org/update_time

See you all in Dallas.

Simon
nomis52 is offline   Reply With Quote
Old May 30th, 2017   #8
zano_villa
Junior Member
 
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 11
Default

Hello everyone,
just a simple question: if I have implemented some Manufacturer Specific PIDs, how can I inform controller about these PIDs? I think with SUPPORTED_PARAMETERS pid.
So why on page 55 of standard is written: "Manufacturer-Specific PIDs may or may not be included in the response" ?
Thank you
zano_villa is offline   Reply With Quote
Old May 30th, 2017   #9
sblair
Administrator
 
Join Date: Feb 2006
Posts: 413
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Quote:
Originally Posted by zano_villa View Post
Hello everyone,
just a simple question: if I have implemented some Manufacturer Specific PIDs, how can I inform controller about these PIDs? I think with SUPPORTED_PARAMETERS pid.
So why on page 55 of standard is written: "Manufacturer-Specific PIDs may or may not be included in the response" ?
Thank you
In some cases you may not want to publicly report a manufacturer-specific PID in your product if it is intended for your own use only. If you intend for it to be private and that you only use it with your own controller then you don't include it in the SUPPORTED_PARAMETERS. If you intend for other controllers to be able to make use of this PID then you announce it in SUPPORTED_PARAMETERS for controllers to be aware of it.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old September 26th, 2018   #10
soundscu
Junior Member
 
Join Date: Apr 2008
Posts: 3
Default

The simple PARAMETER_DESCRIPTION format as defined will do what I need, I need to implement 3 or 4 very simple PIDs. So, to rephrase/reiterate my original question:

Are there any readily-available controllers that support PARAMETER_DESCRIPTION?

**

Knowing what my customers use, it would be great if the DMXcat supports it. Second choice would be a Fleenor DMXter4 RDM.

The controller my customers keep going to is the Swisson DMX tester, and right now is doesn't do subdevs or E1.37 dimmer PIDs, so it really doesn't matter if it does PARAMETER_DESCRIPTION, since I need those other things.

Jim
soundscu 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
Manufacturer Specific Pids berntd RDM General Implementation Discussion 4 November 29th, 2009 02:50 PM
PARAMETER_DESCRIPTION data type semantics tim_ecue RDM Interpretation Questions 4 October 14th, 2009 10:47 AM
PDL size and manufacturer specific parameter ID's jamie RDM General Implementation Discussion 5 July 13th, 2009 12:31 AM


All times are GMT -6. The time now is 01:45 PM.


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