Real World Sub-Devices

[owaits]

We are scratching our heads here on how we should go about handling sub-devices. I will give you some scenarios and also mention how we intend to handle them. If anyone has a device which supports sub-devices then I would love to hear from you or meet at the plug fest.

Just a bit of background specific to our implementation. Due to the limitations of the RDM personality interrogation we instead resort to matching the fixture to a personality in our library. To identify the correct personality and mode we use the Manufacturer Id, Model Id, Personality/Mode, Software Version. This allows us to auto patch the fixture with a fully fledged personality. We are populating the personalities with the RDM info from the open lighting database.

Scenario 1

A dimmer has 24 channels, each channel could either be configured with a relay module or a dimmer module. Each channel is a separate sub-device in the dimmer fixture.

Problem 1

What data should the lighting console use to determine that the channel is a relay and not a 0-100% dimmer channel.

Solutions

1) Use a different personality/mode
2) Use a different model id
3) Use the product category
4) Use the personality description

Our Answer

It does not seem correct to use the mode since this is something you can change through RDM. The personality description could be used but it does not scale well as matching the correct personality would be difficult with more complex fixtures. You may also get duplicate matches. The product category whilst promising is too loosely defined to be usable. So we have resorted to using the model id. However this relies on manufacturers giving each sub device with a different personality a different model id. So we have no good solution.

Scenario 2

A media server with the following layer controls. Each layer can be assigned a different DMX address. The layers may span multiple universes.

Master Layer
Layer 1
Layer 2
Effects

Layers 1 and 2 all have the same personality but effects and master layer are different.

Problem 2A

What data should the lighting console use to determine whether it is a normal layer, master layer or effects. They must be separate devices as each can have its own DMX address.

Problem 2B

How does the console know that some sub-devices are on one universe and the rest are on a separate universe.

Solutions 2A

1) Use a different personality/mode
2) Use a different model id
3) Use the product category
4) Use the personality description

Solutions 2A

1) a device only reports the devices on that universe.

Our Answer

Each layer must have a seperate model id.

When the device is spilt over several universes then you will get the case where a device id appears on two ports. This will cause problems.

The problem we have is that for this all to work, all implementations of sub-devices must come to the same conclusion that each sub-device needs a different model id. I can not see this happening from people reading the spec. It is only when you see the problem that you will come to this solution.

So our conclusion is that this kind of functionality whilst hinted at through RDM is not practically possible when dealing with sub-devices. The only way it might work is for us to use the very basic personalities provided through RDM. Unfortunately this is not an option for us.

I am not sure where to go from here. I want to implement sub-devices as I think some of the behaviour is desirable. However there seem to be too many holes for it to be usable and compatible in a real world enviroment.

[sblair]

You've got some good questions. I think most of these are resolvable without resorting to a different Model ID, but I need a bit of sleep before I can respond with anything coherent.

Are you going to be at the London Plugfest in Gatwick? I'm already over here in London now for other meetings (hence the lack of sleep) and Simon Newton and some others will be over for the Plugfest so I'd really enjoy discussing these with you in person then if that is an option.

Thanks.
Scott

[owaits]

I will be at the plugfest on Thursday and Friday (maybe Saturday).

[sblair]

Perfect! I'll be there Thurs and Fri but not on Sat.

[ericthegeek]

For Scenario #1:
If you're implementing an RDM responder with different kinds of sub-device modules that can be installed, I'd probably take an "all of the above" strategy. I would give each different kind of module its own:

Model Id
Model Description
Product Category/Detail ID List

If the module behavior can be set in software (rather than requiring a hardware change), than it should use the personality/personality description mechanism.

If you're implementing a controller, then you can't depend in any one specific behavior from a responder. A controller will need to handle responder that use any or all of the mechanisms we've discussed.


For Scenario #2:
The case of having multiple universes should be straightforward. The RDM responder will have a separate UID for each responder port ("universe"), and use the "Binding UID" mechanism to tell the controller that this group of UIDs all correspond to the same piece of hardware.

Then, each responder port only advertises the layers that are patched to it. So, you could have a responder with the following structure:

DMX Port A: UID 454A:11111111
SubDev1: Master Layer
SubDev2: Layer 1

DMX Port B: UID 454A:22222222
SubDev1: Layer 2
SubDev2: Layer 3
SubDev3: Effects Layer

Port A would advertise 2 sub-devices, and port B would advertise 3 sub-devices.

Each different *kind* of layer should probably have its own Model ID/Model Description, but identical layers that are repeated several times can share a Model ID/Model Description.

For example:
Model ID 0001: Master Layer
Model ID 0002: Basic Video Layer
Model ID 0003: Advanced Video Layer
Model ID 0004: Mix Layer

A given configuration might advertise a Master Layer, 5 Basic Video Layers, and 2 Advanced Video Layers.


One limitation is that RDM does not have a standardized way to patch a Sub-Device to a universe. RDM assumes that universes are assigned by how the cables are run and not software assigned. If you wanted the ability to move a sub-device from one responder port to another you'd need to use manufacturer specific PIDs.


One final thought: If you truly end up in a bind, and it's simply impossible to describe the behavior you need using Sub-Devices, you always have the option to have the media server act as a proxy rather then a root device with sub-devices. In this scheme, the media server advertises itself as a Managed Proxy. You would then give each layer its own UID, and advertise it through the "Proxied Devices" mechanism. Each layer now acts like a separate fixture. The downside of this is it may not be obvious to the user which layers belong to the same media server depending on how the controller's user interface handles proxies.

[owaits]

Each different *kind* of layer should probably have its own Model ID/Model Description, but identical layers that are repeated several times can share a Model ID/Model Description.

This is the approach we have gone for at the moment. The media server sends a different model ID for each different type of layer. The console then uses the Manufacturer Id, Model Id, Personality/Mode, Software Version to identify the correct personality for the layers.

My concern as a console manufacturer is that this works well with a media server we have control over. However if someone was to implement a media server and not give it different model IDs for each type of layer it wont work correctly. They would be within the RDM protocol but not work fully with our console. In fact it would patch incorrectly giving each layer the same personality.

I have this working in our console software using the model id.

[ericthegeek]

Unfortunately, RDM will probably never provide enough information to eliminate the need for console personality libraries, especially for something as complex as a media server. Conceptually, it's the same problem as trying to define a universal library format: How do you define one data model that can describe every conceivable kind of control data in a way that is meaningful to both the controller, and the responder?

Since consoles will still have personality libraries, you may want to extend the library data for your controller to include information on how to recognize each kind of fixture via RDM. You're unlikely to find one library matching technique that will work for all cases. As you suggested, using Model ID is probably the best case provided that the responder implements it this way. When the responder has different behavior, you may have to resort to string matching within the various _DESCRIPTION PIDs in combination with other techniques.

As a last resort for poorly implemented responders, there's always the option to present the user with a "I've found a Type X media server with 6 layers. Please choose a library for each layer" message. Giving the user 4 or 5 layer types to pick from is still better than having to manually patch everything from scratch that you have to do without RDM. Sadly, this is already required for some responders. For example, some models of the SeaChanger use the same model ID for the CMY+Green version and the CMY+Fader version, so there's no way to differentiate between them in software. It's always a bit of a shock the first time you try to dim a fixture and it goes bright green...

[owaits]

I realise we have to match our personalities and as said we store extra info in the personality to do this.

I am just trying to point out that there is a possibility that certain types of implementations with sub-fixtures may be un-recognisable depending on how they are implemented. Maybe we are happy with this. I personally am not and I suspect a user won't be when it goes wrong and they have to manually select a personality.

[ericthegeek]

Definitely something to be aware of. This is the kind of knowledge that falls in the realm of "Best Practices". Hopefully most RDM developers will find and read this forum at some point in their development cycle.

One related issue I've run into that we haven't discussed in this thread is how to differentiate between multi-port responders that allow the same element to be controlled by two different inputs, and a responder that uses more than one input to control different elements.

For example, if you discover a dimmer rack with two responder ports and each responder port advertises 48 sub-devices: Is it a 48-way dimmer rack that can control each dimmer from two different consoles, or is it a 96-way rack with half of the dimmers controlled by each input (or some other more complex mapping)? There's no reliable way to tell the difference.

[owaits]

I think things would fall apart very rapidly if you allowed a device to have the same ID across multiple ports. How would you know when you received the DeviceInfo that it was not an update, change or movement of the device to that port. I can not see how it would work unless they have different IDs for each port/line.

My implementation certainly does not allow a device with one ID to have multiple DeviceInfo states. Not sure whether it should. It will allow the same device to be on multiple ports though.

I also have to allow for the device to be across multiple transports. You may get the same device on DMX, ArtNet or RDMNet. We have added a software router which works out the best way to send the RDM message with each transport getting a different weight.