Usage of PARAMETER_DESCRIPTION for manufacturer-specific PIDs

[R.Schladör]

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)

[prwatE120]

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]

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

[ericthegeek]

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.

[hamish]

Originally Posted by ericthegeek

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

[sblair]

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.

[nomis52]

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

[zano_villa]

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

[sblair]

Originally Posted by zano_villa

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.

[soundscu]

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