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)
-   -   Refreshing "parameter_description" ? (http://www.rdmprotocol.org/forums/showthread.php?t=1133)

theguenni March 1st, 2012 04:05 PM

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]

sblair March 1st, 2012 04:32 PM

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?

ericthegeek March 2nd, 2012 09:22 AM

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.

nomis52 March 2nd, 2012 09:50 PM

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

prwatE120 March 3rd, 2012 02:52 AM

Changing the meaning of any PID at run time is a recipe for confusion and a total absence of interoperability. I would desist!

ericthegeek March 3rd, 2012 09:38 AM

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.

nomis52 March 3rd, 2012 06:00 PM

Quote:

Originally Posted by ericthegeek (Post 2335)
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

sblair March 3rd, 2012 08:06 PM

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.


All times are GMT -6. The time now is 05:21 AM.

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