|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
February 5th, 2009 | #1 |
Junior Member
Join Date: Sep 2006
Location: London
Posts: 6
|
Uniquely defining the RDM response of devices
If a controller discovers two devices which respond with the same
- Manufacturer ID - RDM protocol version - Device Model ID - Software Version ID - DMX512 Personality is it correct to say that they must have identical responses to all other PIDs, other than "real time" status responses - DMX start address, device hours, lamp state, and so on. All other responses must be the same (Product detail IDs, Device Model Description, slot info, slot description, sensor definition, Supported Parameters etc). Do these five parameters uniquely define how a device must respond? Are there any other fields that should be on the list to make it a complete set? |
February 5th, 2009 | #2 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
While that's likely a reasonable assumption for many cases, it's not guaranteed by the standard. There are a few cases where the standard's text requires "identical" responses, that's all you can count on.
For example: two dimmer racks with different modules installed could legitimately have different responses to GET SLOT_DESCRIPTION. |
February 5th, 2009 | #3 |
Junior Member
Join Date: Sep 2006
Location: London
Posts: 6
|
Thanks for the reply. I agree that it's not laid down in the spec (at least I couldn't find it anywhere), but I'm trying to find a solution to the following:
After discovering all the fixtures in a rig, does a controller have to interrogate every single fixture to get their detailed parameters? When can it decide that two fixtures have identical RDM properties? When faced with a rig of 50 of one type of fixture and 50 of another it has to go through the descovery process to find all 100 fixtures. Does it then need to cross examine all 100 fixtures to find out the detailed information about what they can do, what parameters they support, what sensors they have, what their slot descriptions are and so on, or can it just interrogate one fixture of each type and then know with certainty that the others are all the same? This could presumably have a significant effect on the amount of RDM traffic (and presumably time) required for a console to become aware of the properties of all the fixtures on its network. |
February 5th, 2009 | #4 |
Task Group Member
Join Date: Aug 2008
Posts: 378
|
It entirely depends on how conservative you want to be. You can probably make some reasonable assumptions and cut down your traffic significantly. But in the worst case, you may have to query every parameter of everything.
If you detect a Wigglepro100ZX, and your system already knows how to control Wigglepro100ZXs, then GET DEVICE_INFO is all you'll need. Load the appropriate profile and move on. If you see a figure that you know nothing about and have never seen before than the controller can build a basic profile with the information that's avilable over RDM. On a large rig, this can indeed take a while, but it's still "Faster than a stagehand with a ladder", or in this case: Faster than typing it in yourself. For most RDM devices, I'd expect you can get all the information you need in a second or two per fixture. |
February 5th, 2009 | #5 | ||||
Administrator
|
Andy,
This was something that was discussed a lot during development and we did try to put some hard rules in place where we could. Section 10.4.1 states the following: Quote:
That is one big reduction there. This eliminates asking every device for supported parameter lists. Slot descriptions could be different obviously depending on protocol mode but also on model ID or sub-device related info. Imagine an X-Spot with different modules in it for example. 10.5.1 also states: Quote:
While not out-right stating it, it does appear pretty clear here that for the same Device Model ID you should get the same text description back. In the same section: Quote:
In Section 10.5.4: Quote:
This is another reduction for getting the same information from all the devices. Hopefully these help some, please let me know if there are any other specific ones that are in question also.
__________________
Scott M. Blair RDM Protocol Forums Admin |
||||
February 6th, 2009 | #6 |
Junior Member
Join Date: Sep 2006
Location: London
Posts: 6
|
Eric,
I completely agree that you can make assumptions, and that if you're just trying to select the correct fixture personality you won't need to know the software version or RDM protocol version either. I'm just trying to establish when we can guarantee that two fixtures are the same, and when we can only say that they are similar. Scott, OK, I admit that I'd completely forgotten about 10.4.1 which yes, does reduce the amount of information significantly. I'm trying to work out how to record the RDM capabilities of fixtures within fixture personalities, and in particular how best it should be structured. Thanks to both of you for taking the time to answer. Andy |
February 9th, 2009 | #7 |
Administrator
|
Andy,
It's a good and important discussion, as intelligently managing the wire will provide the best user experience. Please let us know of any other questions as they arise.
__________________
Scott M. Blair RDM Protocol Forums Admin |
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Multi-devices or sub-devices | Fokko | RDM Interpretation Questions | 4 | December 1st, 2006 11:10 AM |