DMX_PERSONALITY - E1.20 RDM (Remote Device Management) Protocol Forums

dj41354 · June 28th, 2017

I have 3 (different size & wattage) fixtures that have been successively developed over that last 5 years that I'm trying to keep as unified as possible as far features and firmware are concerned. Most recently we've added a couple of features that are "Personalities" to our newest family members.. but we're also working on 2nd generation version of the eariler fixtures to give them the ability of the latest features. My problem is that the newest fully capable hardware has 7 personalities.. but earlier versions are only capable of some of these. (Additionally, even on the newest platforms, one of the personalities is an "accessory" that can be "added" after the fixture has been shipped). I'm having difficulty reconciling the concept that Personality numbers must be contiguous.. as this leads to different Personality numbers FOR THE SAME FEATURE SET depending on the generation of the fixture (or family size of the fixture). I'm leaning towards standardizing on the Personality Numbers based on the features they represent.. but that means on some of the fixtures (that don't yet have all the hardware present) some of the Personalities are "NOT AVAILABLE". My current RDM implementation is exactly that, and reports PERSONALITY_DESCRIPTION as "NOT AVAILABLE" as necessary.. but it seems this is not an accepted practice. I'd like some help with this. It seems to me a standardized set of Personality Numbers (even if in some circumstances, on the fixture in question, not all of them are available) is a better solution than forcing different personality numbers for the same features over a family of products.

ericthegeek · June 29th, 2017

I can certainly understand why you'd like to keep the consistency between different generations of the hardware. But from an RDM standpoint, a different generation with different features would be considered a different model and thus could have different personality behavior.

Unfortunately there's no perfect solution here. Personalities have to be consecutively numbered, so controllers will not expect there to be gaps in the numbering. It's quite common for controllers to ask for the PERSONALITY_DESCRIPTION for every personality when the user starts to setup the fixture.

I suppose you could declare all seven personalities, but then NACK when the controller tries to set one that's not supported. If you also set the Description string to "Not Available", then at least the user will have some idea why it's not accepted.

dj41354 · June 30th, 2017

That's pretty much the conclusion I came to. Thanks Eric.

June 28th, 2017	#1
dj41354 Member Join Date: Nov 2015 Posts: 31	DMX_PERSONALITY I have 3 (different size & wattage) fixtures that have been successively developed over that last 5 years that I'm trying to keep as unified as possible as far features and firmware are concerned. Most recently we've added a couple of features that are "Personalities" to our newest family members.. but we're also working on 2nd generation version of the eariler fixtures to give them the ability of the latest features. My problem is that the newest fully capable hardware has 7 personalities.. but earlier versions are only capable of some of these. (Additionally, even on the newest platforms, one of the personalities is an "accessory" that can be "added" after the fixture has been shipped). I'm having difficulty reconciling the concept that Personality numbers must be contiguous.. as this leads to different Personality numbers FOR THE SAME FEATURE SET depending on the generation of the fixture (or family size of the fixture). I'm leaning towards standardizing on the Personality Numbers based on the features they represent.. but that means on some of the fixtures (that don't yet have all the hardware present) some of the Personalities are "NOT AVAILABLE". My current RDM implementation is exactly that, and reports PERSONALITY_DESCRIPTION as "NOT AVAILABLE" as necessary.. but it seems this is not an accepted practice. I'd like some help with this. It seems to me a standardized set of Personality Numbers (even if in some circumstances, on the fixture in question, not all of them are available) is a better solution than forcing different personality numbers for the same features over a family of products.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

June 29th, 2017	#2
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 378	I can certainly understand why you'd like to keep the consistency between different generations of the hardware. But from an RDM standpoint, a different generation with different features would be considered a different model and thus could have different personality behavior. Unfortunately there's no perfect solution here. Personalities have to be consecutively numbered, so controllers will not expect there to be gaps in the numbering. It's quite common for controllers to ask for the PERSONALITY_DESCRIPTION for every personality when the user starts to setup the fixture. I suppose you could declare all seven personalities, but then NACK when the controller tries to set one that's not supported. If you also set the Description string to "Not Available", then at least the user will have some idea why it's not accepted.

June 30th, 2017	#3
dj41354 Member Join Date: Nov 2015 Posts: 31	That's pretty much the conclusion I came to. Thanks Eric.