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 March 1st, 2012   #1
theguenni
Junior Member
 
Join Date: Feb 2011
Posts: 2
Question Refreshing "parameter_description" ?

Hi all,

is it somehow possible to refresh a/the parameter description of the manufacture-specific PID at runtime.
I've tried many ways e.g. with queued messages and so on, but nothing works. Even a reset of the device doesn't work,
because the controller keeps this data. Is there any way to solve this issue?

thanx, Marcus
[COLOR=#000000 ! important][/COLOR][COLOR=#000000 ! important][/COLOR]
theguenni is offline   Reply With Quote
Old March 1st, 2012   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Can you give a more specific example of the exact issue and also what products you might be working with if they aren't ones you are developing?
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old March 2nd, 2012   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

Although the standard doesn't explicitly require it, many RDM implementations will assume that the response to GET PARAMETER_DESCRIPTION for a given PID will be constant throughout the life of a given responder.

The exact behavior will depend on the specific controllers and responders that you are working with. Some controllers will request PARAMETER_DESCRIPTION for all manufacturer specific PIDs upon initialization, while others will only get the information when needed.

Your best option is to find a way to implement the functionality you need in a way that doesn't require changing the PARAMETER_DESCRIPTION response. You could use multiple PIDs, or some other method.

To give any more detailed advice, we'll need more information about what you're trying to accomplish.

As a side note: Make sure you've read section 6.2.10.2 of the E1.20-2010 document. Manufacturer specific PIDs have to have the same "meaning" across all products from a given manufacturer.
ericthegeek is offline   Reply With Quote
Old March 2nd, 2012   #4
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

I second Eric's recommendation not to do this. I haven't seen a controller that supports the definition of a manufacturer specific PID changing without requiring human intervention.

Also the PID index (http://rdm.openlighting.org/) won't support dynamic definitions.

Simon
nomis52 is offline   Reply With Quote
Old March 3rd, 2012   #5
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 180
Default

Changing the meaning of any PID at run time is a recipe for confusion and a total absence of interoperability. I would desist!
prwatE120 is offline   Reply With Quote
Old March 3rd, 2012   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

This did get me thinking about the behavior of PARAMETER_DESCRIPTION. Because of the section 6.2.10.2 language, I'd previously said that to save time, you could send a GET PARAMETER_DESCRIPTION to one responder in the rig, and apply the response to all fixtures from the same manufacturer that declare support for that PID.

But the text only requires that they have the same "meaning", not the identical response. Different fixtures could have the same meaning, but have different values for Min/Max or similar.
ericthegeek is offline   Reply With Quote
Old March 3rd, 2012   #7
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by ericthegeek View Post
But the text only requires that they have the same "meaning", not the identical response. Different fixtures could have the same meaning, but have different values for Min/Max or similar.

When we reopen E1.20 and clean up the PARAMETER_DESCRIPTION PID we should fix this. Scott can you add it to the TODO list?

Simon
nomis52 is offline   Reply With Quote
Old March 3rd, 2012   #8
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

It's been on the list. What will happen is we will likely add a new PID to one of the E1.37 docs and then just deprecate the original one. We really can't do much in changing the existing one at all as it would break existing usage. Best thing to do is create a new one and deprecate the old.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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
Usage of PARAMETER_DESCRIPTION for manufacturer-specific PIDs R.Schladör RDM General Implementation Discussion 9 September 26th, 2018 12:04 PM
Refreshing "parameter_description" ? theguenni RDM General Implementation Discussion 0 February 29th, 2012 02:36 PM
Refreshing of paramters need Queued Messages? berntd RDM General Implementation Discussion 33 May 25th, 2010 02:09 PM
PARAMETER_DESCRIPTION data type semantics tim_ecue RDM Interpretation Questions 4 October 14th, 2009 10:47 AM


All times are GMT -6. The time now is 10:29 AM.


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