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)
-   -   2 sets of personality (http://www.rdmprotocol.org/forums/showthread.php?t=1268)

majid November 3rd, 2017 03:06 AM

2 sets of personality
 
hi everyone

I m new to RDM, trying to design RDM-DMX LED fixture.
I have read old posts and found answers for most of my questions.

planning to make LED array fixture with 2 sets of personalities:
1: LED/pixel: {1 LED/pixel, 3/LED/pixel, ...}
2: Color: {RGB(3channel), RG(2ch), R(1ch) , ...}

seems it is not possible to have more than 1 set of personalities.
shall I do it using Manufacture specific PIDs?
or is there better approach ?

sblair November 3rd, 2017 10:10 AM

Majid, Welcome to the forums!

Yes, there is only 1 set of personalities. I would take caution in how you implement this as having a large number of combinations/personalities will make it much more difficult for you to get support from lighting consoles as they may only choose to implement a couple of the personalities and not all 23 of them... DMX channels are relatively cheap these days so having lots of complex combinations just to save on DMX channels may not be actually saving you that much.

majid November 3rd, 2017 12:00 PM

Thank you scott
:)
I m happy joned the forum!

I understand, I have already implemented LED/pixel yet, its amzing for me!
I think its better to avoid Slot/pixel, it seems useless

Thanks

prwatE120 December 14th, 2017 03:45 AM

Majid

Scott's answer may have been over cautious. There are plenty of fixtures with multiple personalities to allow the user to select the best slot allocation for their application and DMX footprint. That said, I suggest exceeding 15-20 is excessive, and may result in some (poorly implemented IMHO) controlllers not allowing access to all your options.

I would restrict the use of Manufacturer specific PIDs where possible - as many of the current controllers so NOT allow access to them in any form. Again, a controller limitation that will reduce in time. Man Spec PIDS are ideal for things like calibration and current settings that the end user is not normally expected to tamper with.

Since you are developing a responder, I would commend the RDMIntegrity package to you - it is a compregensive toolset for verifying RDM responder implementations.

PM me if you would like more information.

Peter

majid December 16th, 2017 01:37 AM

I agree the "keep it simple" principle and try not to mess with special PIDs unless its really needed
For my current project, standard PIDs satisfy requirements,

Actually I need a verification to unveil hidden bugs, faults
Thanks

ArdenCro August 11th, 2018 05:54 AM

Quote:

Originally Posted by majid (Post 3136)
I agree with this excellent Zippyloan review so "keep it simple" principle and try not to mess with special PIDs unless its really needed
For my current project, standard PIDs satisfy requirements,

Actually I need a verification to unveil hidden bugs, faults
Thanks

Would RDMIntegrity package be something you'd expect to beginner users with similar needs as Majid or is there a simpler option but maybe not as powerful?


All times are GMT -6. The time now is 03:27 AM.

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