E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old October 5th, 2006   #1
Andy Macdonald
Junior Member
 
Join Date: Sep 2006
Location: London
Posts: 6
Default Device Models

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
__________________
Andy Macdonald
Carallon Ltd
www.carallon.com

Last edited by Andy Macdonald; October 5th, 2006 at 05:33 PM.
Andy Macdonald is offline   Reply With Quote
Old October 5th, 2006   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 16th, 2006   #3
Andy Macdonald
Junior Member
 
Join Date: Sep 2006
Location: London
Posts: 6
Default

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
__________________
Andy Macdonald
Carallon Ltd
www.carallon.com

Last edited by Andy Macdonald; October 16th, 2006 at 10:35 AM.
Andy Macdonald is offline   Reply With Quote
Old October 16th, 2006   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

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.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 17th, 2006   #5
Nigel Worsley
Junior Member
 
Join Date: Jun 2006
Location: London
Posts: 13
Default

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.

Last edited by Nigel Worsley; October 17th, 2006 at 09:30 AM.
Nigel Worsley is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Must a device support 32 charecters in DEVICE_LABEL? p_richart RDM Interpretation Questions 5 November 7th, 2008 01:02 PM
Broadcasting to a device model sjackman RDM General Implementation Discussion 3 January 21st, 2008 12:30 PM


All times are GMT -6. The time now is 05:29 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.