Refreshing "parameter_description" ?

[theguenni]

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]

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]

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]

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]

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

[ericthegeek]

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]

Originally Posted by ericthegeek

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]

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.