E1.20 RDM (Remote Device Management) Protocol Forums - View Single Post

tim_ecue · February 23rd, 2011

Dear RDM friends,

I am somewhat unhappy with implementing the SELF_TEST_DESCRIPTION parameter.

The problem is, that in my understanding the current spec provides no indication of the potential index range for tests other than 1-254. It is not defined that the tests need to be consecutively ordered and there is no mechanism for determining the number of available tests.

Thus, it seems any fully complient implementation ends up enumerating all possible values. This requires 254 requests and takes about 9 seconds alone at 30 updates per second. This is really bad, particularly for large installations where you might need to poll hundreds of fixtures on a single DMX line, wich is unfortunately very realistic for me. Even for just 100 fixtures (thats just a normally populated one line of RGBW faders) this takes 15 minutes for fetching that damn thing alone. Customers hate it.

Eventually, I decided to simply default in the software to assume consecutively ordered numbers and allow an override for "deep" search, but I am not happy with it.

So after all that text: did I miss something or is it that bad ? Wouldnt it be useful to require consecutively ordered tests as for DMX personalities?

Best,
Tim

February 23rd, 2011	#1
tim_ecue Junior Member Join Date: Oct 2009 Posts: 12	SELF_TEST_DESCRIPTION index range Dear RDM friends, I am somewhat unhappy with implementing the SELF_TEST_DESCRIPTION parameter. The problem is, that in my understanding the current spec provides no indication of the potential index range for tests other than 1-254. It is not defined that the tests need to be consecutively ordered and there is no mechanism for determining the number of available tests. Thus, it seems any fully complient implementation ends up enumerating all possible values. This requires 254 requests and takes about 9 seconds alone at 30 updates per second. This is really bad, particularly for large installations where you might need to poll hundreds of fixtures on a single DMX line, wich is unfortunately very realistic for me. Even for just 100 fixtures (thats just a normally populated one line of RGBW faders) this takes 15 minutes for fetching that damn thing alone. Customers hate it. Eventually, I decided to simply default in the software to assume consecutively ordered numbers and allow an override for "deep" search, but I am not happy with it. So after all that text: did I miss something or is it that bad ? Wouldnt it be useful to require consecutively ordered tests as for DMX personalities? Best, Tim