Thread: Device Models
View Single Post
Old October 5th, 2006   #2
Join Date: Feb 2006
Posts: 430
Send a message via AIM to sblair Send a message via MSN to sblair


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 M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote