Device Models

[Andy Macdonald]

This may seem a little obvious, but I wanted to check what people understand by the term "Model" in an RDM context? It's not mentioned in Appendix D (Definitions). I ask because of the requirement in section 10.5.1 for different models to have different Device Model IDs.

While say a Mac 250 spot and a Mac 250 wash are clearly different models, what about fixtures with different hardware options such as the Mac 2000 Wash (which can have either a dimmer wheel or a second colour wheel fitted) or the X-Spot, or fixtures which can take optional modules, such as the Source 4 Revolution? Should different physical variants of a fixture alwayd be treated as different models in RDM, or could, for example, the two variants of the Mac 2000 Wash both return the same Model ID?

Personally, I believe that different hardware means different models, with different model IDs, but do not believe this has been defined in the spec. Have I missed something? How do other people see it? And I guess most importantly, how do fixture manufacturers see it?

Cheers

Andy

[sblair]

Andy,

It's one of those many areas where it is impossible to completely legislate exactly what defines a model and at the end of the day it is really up to the manufacturer to decide how to classify their products in a way that makes the most sense.

What we have is specified the consequences and purpose of the Model ID field. The 3rd paragraph in Section 10.4.1 specifies that devices with the same Manufacturer ID, Model ID, and Software Version ID must report an identical list of SUPPORTED_PARAMETERS.

The Model ID allows the controller to:

• Determine which descriptive name to display for the device.
• Reduce overall communication to identical devices. This means if I have a rig of 100 Studio Beam fixtures with the same software version I only have to communicate with 1 unit to determine what PID's are supported and I can assume all the others are the same.

X.Spot was always a great example in discussions during RDM Development because of it's modular nature. It could be implemented in several ways. Given the modular nature, the modules could certainly be implemented as Sub-devices. While Sub-Devices are best suited for arrays of devices like dimmer modules, or even color scrollers, the concept could be applied to fixtures like the X.Spot or S4 Revolution.

They could also be represented as different Model ID's depending on which modules are installed. With the original concept and roadmap for X.Spot it would have been easier to implement as Sub-Devices, in reality though since we only offered a couple module options and they could only go in specific slots it would actually be easier to implement as different Model ID's in practice.

Hope this gives some guidance.

Scott

[Andy Macdonald]

Scott,

Thanks for your reply, and apologies for the delay in following it up.

Para 9.2.3 of the spec says "all sub-devices shall report an identical list for SUPPORTED_PARAMETERS". I presume this means that if a fixture has two positions to fit modules (eg Source 4 Revolution) then you could only treat them as sub-devices if either one slot was empty, or if both slots contained the same type of module. If, for example, one slot had a gobo wheel module fitted and the other had an iris module then you would need some other way to distinguish them.

Or does 9.2.3 mean that you can have two different modules fitted, as long as they can both respond to the same requests for information? If one module/sub device can respond to a Get SLOT_INFO request then they both must, even though they would respond with different number of slots and different slot types for those slots?

Is the latter how I should be interpreting the spec therefore?

Thanks

Andy

[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.