E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Uniquely defining the RDM response of devices (http://www.rdmprotocol.org/forums/showthread.php?t=1001)

Andy Macdonald February 5th, 2009 06:40 AM

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?

ericthegeek February 5th, 2009 09:49 AM

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.

Andy Macdonald February 5th, 2009 10:18 AM

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.

ericthegeek February 5th, 2009 11:13 AM

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.

sblair February 5th, 2009 11:14 AM

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:

Devices with the same Manufacturer ID, Device Model ID, and Software Version ID response for the DEVICE_INFO parameter shall report an identical list for the SUPPORTED_PARAMETERS message. This allows the controller to reduce the quantity of information stored for identical devices.




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:


Device Model ID:

This field identifies the Device Model ID of the Root Device or the Sub-Device. The Manufacturer shall not use the same ID to represent more than one unique model type.

A text description for the Device Model ID can be retrieved from the device using the DEVICE_MODEL_DESCRIPTION Parameter.



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:


Any devices from the same manufacturer with differing software shall not report back the same Software Version ID.



In Section 10.5.4:
Quote:

10.5.4 Get Manufacturer Label (MANUFACTURER_LABEL)


This parameter provides an ASCII text response with the Manufacturer name for the device of up to 32 characters. The Manufacturer name must be consistent between all products manufactured within an ESTA Manufacturer ID.

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.






Andy Macdonald February 6th, 2009 02:35 PM

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

sblair February 9th, 2009 02:24 PM

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.


All times are GMT -6. The time now is 05:48 PM.

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