Device Models

[sblair]

Andy,

There's a little bit of fuzziness there. It was difficult conveying the full intent in that section.

All sub-devices must report the same list of Supported Parameters. However, it doesn't mean the values for those Parameters must be the same and there might not be cases where depending on the type of sub-device in a particular slot that it makes another parameter invalid for that slot.

Take the example of a dimmer rack. Each dimmer module is a sub-device and therefore reports the list of Supported Parameters for the dimmer modules. Each sub-device has the same list of Supported Parameters.

Now lets say I replace one of the dimmer modules with a non-dim, or even better a constant (i.e. a breaker hardwired to output..no electronics).

In those sub-devices some of the Parameters that applied to the dimmer modules won't apply or exist when that module changes from a dimmer to a non-dim. When that happens, that sub-device can send a NACK or respond however appropriate.

All the sub-devices have the same Supported Parameters list, which is the superset of all the sub-device supported parameter possibilities, but at any one time you might have certain sub devices that will have some PID's that will be invalid based on the type of module in that Sub-Device.

The trick is applying sub-devices in an appropriate way where the majority of the Supported Parameters apply to all with a few exceptions. Even with the Source 4 Rev or X.Spot example, you can have a list of Supported Parameters that applies across most all the sub-devices.

Hope this helps.

[Nigel Worsley]

As Scott has already mentioned in a separate thread, sub-devices where intended for dimmers, where each sub-device is identical ( or at least very similar, eg. non-dim or 2.5K/5K channels ). Where each sub-device is different, as with the moving light example, I don't think that it makes sense to use sub-devices.

It may be possible to implement both approaches in the product, and use 'Get/Set DMX512 Personality' to choose between them. The spec says "Many RDM parameters may be affected by changing personality.", but that doesn't necessarily mean that a controller will be expecting changes at such a fundamental level.


This could be a way round the optional modules scenario, provided there aren't too many permutations. The correct personality could be set automatically by the device to avoid too much brain strain of the user. Again, it is unclear how a controller would behave in this scenario, but it is definitely within spec so it ought to be able to deal with it.