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)
-   -   DMX_PERSONALITY (http://www.rdmprotocol.org/forums/showthread.php?t=1260)

dj41354 June 28th, 2017 02:15 PM

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.

ericthegeek June 29th, 2017 08:18 PM

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 05:20 AM

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


All times are GMT -6. The time now is 01:09 PM.

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