SELF_TEST_DESCRIPTION index range - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · February 25th, 2011

All of the optimizations that you suggest are perfectly valid for an individual controller to do. I'm just uncomfortable mandating them as part of the standard.

If you're in a truly performance critical environment, you can cache the list between sessions. When the user brings up the self-test menu for a specific device, you can present them the cached list. While they're reading through the list, you can be querying the device to see if anything's changed in the background.

Further, I'd say it's reasonably safe to assume that responders with the same Model ID, Software Version ID, and Personality have the same list of self tests. Thus, if you have 100 responders of two different models, you can send a GET DEVICE_INFO to all of them, then query all 255 self-tests from one of each model. That's a total of 610 packets for 100 devices. It also scales well, because adding additional responders only requires one more DEVICE_INFO request.

If you're not in the middle of an active crossfade, you can drop back to one null startcode packet per second. It's perfectly reasonable to send 200 RDM requests a second if you're working with well-behaved responders. In a 4 universe system, you can do 800 requests a second. Thus, you could complete the query described above in about 3 seconds or less.

Architectural environments tend to change relatively infrequently. That gives lots of opportunities to cache data in the controller. Even if the initial setup takes a few minutes (even hours), subsequently a single GET DEVICE_INFO is enough to tell if the device is present, and if it's had new software installed.

February 25th, 2011	#17
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	All of the optimizations that you suggest are perfectly valid for an individual controller to do. I'm just uncomfortable mandating them as part of the standard. If you're in a truly performance critical environment, you can cache the list between sessions. When the user brings up the self-test menu for a specific device, you can present them the cached list. While they're reading through the list, you can be querying the device to see if anything's changed in the background. Further, I'd say it's reasonably safe to assume that responders with the same Model ID, Software Version ID, and Personality have the same list of self tests. Thus, if you have 100 responders of two different models, you can send a GET DEVICE_INFO to all of them, then query all 255 self-tests from one of each model. That's a total of 610 packets for 100 devices. It also scales well, because adding additional responders only requires one more DEVICE_INFO request. If you're not in the middle of an active crossfade, you can drop back to one null startcode packet per second. It's perfectly reasonable to send 200 RDM requests a second if you're working with well-behaved responders. In a 4 universe system, you can do 800 requests a second. Thus, you could complete the query described above in about 3 seconds or less. Architectural environments tend to change relatively infrequently. That gives lots of opportunities to cache data in the controller. Even if the initial setup takes a few minutes (even hours), subsequently a single GET DEVICE_INFO is enough to tell if the device is present, and if it's had new software installed.