PID = SUPPORTED_PARAMTERS / PARAMTER_DESCRIPTION question

[berntd]

Hello

Table A-3 mentioned that these PIDs must only be supported if paramters beyond the min are supported by the device.

if this is the case, does the response to this then also have to include the min paramter descriptions or only the additional ones?

In other words: Does this command/response have to support the min paramter set at all or only extended / others?

Kind regards
Bernt

[sblair]

Bernt,

It's a good question and one we had come up at work. For the SUPPORTED_PARAMETERS message, only the PID's that are not included in the minimum support list shall be transmitted.

The key bit of text for this is located at the very end of Section 10.4.1:

PIDs that are included in the minimum support list, indicated by the “Required” column of Table A-3, shall not be reported.

The one PID that gets a little tricky here is DMX_START_ADDRESS. Since it is only "required" if the device consumes a DMX Slot. It is an edge case for the requirement since it is conditional on the device's function. For that reason I always include DMX_START_ADDRESS in my list of SUPPORTED_PARAMETERS even though one could argue I shouldn't.

The requirement in Section 10.4.1 is clear though when it comes not reporting the other required PID's.

[prwatE120]

Hi Bernt

We do not include DMX_START_ADDRESS, as we always treat it as "required PID".

Some of our products have multiple personalities, and only one of them might have a DMX footprint of 0, and I felt it was important that the list of SUPPORTED_PIDs was the same regardless of the current personality setting.


The PARAMATER_DESCRIPTION PID is only required if you are declaring support for Manufacturer specific PIDS. The test in section 10.4.2 is a bit weak, as it refers to "some" manufacturer-specific PIDs.

We have more of a problem with the construct of PID, as about the only thing you can properly describe about our particular Man-specific PIDS using the defined fields as per 10.4.2 is a text string. The rest of the structure of this PID cannot adequately describe the format requirements of our implementations.

Although you could argue that they are "non-compliant" products, I would not be that upset to see products that declared the existence of manufacturer specific PIDS in there list of SUPPORTED_PARAMETERS and did not support the PARAMATER_DESCRIPTION PID.

At least this way you know there is something that the manufacturer might allow you to control, and you ask them for more details !


regards

Peter Willis
Howard Eaton Lighting

[ericthegeek]

> Although you could argue that they are "non-compliant"
> products, I would not be that upset to see products that
> declared the existence of manufacturer specific PIDS in
> there list of SUPPORTED_PARAMETERS and did not support
> the PARAMATER_DESCRIPTION PID.

Per table A-3, a responder that reports a Manufacturer-Specific PID in the SUPPORTED_PARAMETERS message is required to support the PARAMETER_DESCRIPTION PID.

I agree that the format of the PARAMETER_DESCRIPTION message is somewhat limiting and can't describe every possible use case. Still, just having the human readable name string is valuable.

[mike_k]

I've seen quite a few products that replies with the minimum required set of PIDs included in the list, so even if responders are not supposed to do so the controllers should be able to handle all cases when subsets of the required PIDs are included or not.

[berntd]

Hello all,

Thanks for this. Those are the exact issues I have come up with here.

If DMX_START_ADDRESS is supported (because the device needs it then how is a controller supposed to know this unless it can detect it with the PARAMTER PIDs?

I would have to agree with Scott in that it should be treated as a NON mandatory pid and thus included in the SUPPORTED_PARAMTER -list.


Then again, one could argue that if the device does
not need DMX_START_ADDRESS, it should respond with a nack reason NR_UNKNOWN_PID.
The controller could then make a conclusion from that, in which case Peter's approach will work too.

:confused: Hmm...

Kind regards
Bernt

[sblair]

Bernt,

A controller can tell if it consumes a DMX Slot by looking at the footprint field in the DEVICE_INFO PID. If the footprint is zero then it is fairly safe to say that the DMX_START_ADDRESS is not used.

[prwatE120]

Bernt

In section 10.6.3 we clearly state that a GET:DMX_START_ADDRESS request sent to a root or sub-device that has a footprint of zero shall return a value of 0xFFFF.

One could argue that NACKing any GET/SET DMX_START_ADDRESS with a NR_DATA_OUT_OF_RANGE is still supporting the PID, and our definition in table A-17 is entirely consistent with having a footprint of zero.

(definition is "Value out of range or not supported)

This would be preferable to a NACK:NR_UNKNOWN_PID as it avoids any argument that you haven't supported what many expect to be a Mandatory Pid.

My preference would be for us to remove the "option" in Table A-3 and point people back to the "shall" statement in 10.6.3, and add clarification on how to NACK the SET: request.


Peter

[berntd]

Hi Peter,

I see what you mean and it does make sense. If the DMX_START_ADDRESS PID would be considered mandatory for all devices, then the issue would be resolved more consistently.


Kind regards
Bernt

[ericthegeek]

There are already responders in the wild that don't support the DMX_START_ADDRESS PID. Even if it were to be made mandatory in a future version of the document, controllers would still have to handle devices that don't support it.