E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM General Implementation Discussion

RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product.

Reply
 
Thread Tools Search this Thread Display Modes
Old October 6th, 2009   #1
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default How should I best implement a dimmer?

Hello,

I am struggling here becasue there seem to be many ways to implement things with RDM.

I have a device with channels that can be configured in 4 modes On, Off, DmxDim, DmxSwitch.

I also have endless many settings that can be retrieved and set in the unit.

All this has to run via RDM. I looked at the avalable PIDs etc. and although there are things for Lamp striking etc I see no directly suitable ones for what I am doing.

Unless the slot description is to be used somehow for all this?

I could simply make custom PIDs but if there is a more "standard" way to do all this, I would rather use that.
It swould be really great if this could all work with "any" controller with standard implementations.

Is there an application note perhaps on how controllers handle devices and what PIDs they prefer for this type of stuff?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 7th, 2009   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Slot description isn't going to be much help. It will let the responder describe itself to the controller, but the Slot Description PIDs don't allow you to configure the device.

I would implement what you're describing with personalities and sub-devices. Present a sub-device for each channel. Each of those sub-devices would have 4 personalities to define its behavior (On, Off, Dim, and Switch). The advantage of doing it this way is that almost all controllers allow you to set the personality of a responder, and you can give each personality a human-readable name string that makes it clear what each one does.
ericthegeek is offline   Reply With Quote
Old October 7th, 2009   #3
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hello

Thanks for that. It realy helps me a lot asI would not have thought of this.

If I understand this correct then:

Discovery Mute/Unmute needs to report a sub device flag(Bit1) = 1

DEVICE_INFO reports how many sub-devices are present.

SUPPORTED_PARAMTERS reports the paramters for the root (subdevice = 0) device AND if addressed to subdevice x, different paramters as per the subdevice.

For each subdevice, DMX_PERSONALITY / PERSONALITY_DESCRIPTION are then used to set the different modes.


I suppose I then do not need SLOT_DESCRIPTION / SLOT_INFO at all?

Anything else required to make this work for the controllers out there?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 7th, 2009   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> DEVICE_INFO reports how many sub-devices are present.

Correct. DEVICE_INFO will also need to respond with different data when the GET DEVICE_INFO PID is sent to a sub-device than it does for the root. The E1.20 document doesn't officially require that sub-devices support the DEVICE_INFO PID, but practically I think it is required. A controller would have a hard time getting all the information it needs from a sub-device without it.

If you use sub-devices, than you'll probably also want to support patching on a per-device basis. That means for a 6 channel pack, you'd have a root device with a DMX footprint of zero, and six sub-devices each with a DMX footprint of one. You don't have to do it this way, you could patch using the root, and set personalities using the sub-device, but this would be an unusual configuration and might not work with some controllers.

> SUPPORTED_PARAMTERS reports the paramters for the
> root (subdevice = 0) device AND if addressed to
> subdevice x, different paramters as per the subdevice.

Correct. Make sure you follow the requirement in section 10.4.1 that "All Sub-Devices of a single Root Device shall report identical parameter lists although all parameters need not be implemented in each sub-device."

So, the Root can have different SUPPORTED_PARAMETERS than the sub-devices, but all sub-devices must have the same list at the other sub-devices.

> For each subdevice, DMX_PERSONALITY /
> PERSONALITY_DESCRIPTION are then used to set
> the different modes.

Yes

> I suppose I then do not need SLOT_DESCRIPTION
> / SLOT_INFO at all?

You don't need them. You may want to support them anyway, but they are not required.

> Anything else required to make this work for
> the controllers out there?

Just make sure the controller you're using supports sub-devices. Most of them will work just fine with sub-devices, but there are a few that don't.
ericthegeek is offline   Reply With Quote
Old October 7th, 2009   #5
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hi Eric,

This leads me to the next question: Do all subdevices also have to support the minimum mandatory PIDs?

Because of various constraints (front panel etc etc), this unit can only ever have consequetive dmx slots ie 1 single DMX start address.
I would have to go with te "unusual configuration" then?

Unless of course there is still a completely different way of doing all this without sub-devices?

Could the root have DMX_PERSONALITY settings for all the channels and modes as well?

I am worried when you mentioned that some controllers will not handle this.
I can just see the support calls srteaming in

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 7th, 2009   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> This leads me to the next question: Do all subdevices
> also have to support the minimum mandatory PIDs?

There's no mandate that sub-devices have to support all of the other required PIDs. Per section 9.2.3, the only PID that a sub-device must support is SUPPORTED_PARAMETERS. In fact, the discovery PIDs are explicity root-only, thus are can't be mandatory for the sub-devices.

PIDs like DEVICE_INFO and IDENTIFY_DEVICE might be valuable in many cases, and it can't hurt to support SOFTWARE_VERSION_LABEL. If the sub-devices have separate software, report that version number for SOFTWARE_VERSION_LABEL, or just report the same version as the root.

As I've said before, I think DEVICE_INFO is effectively required (even though it's not stated in the standard) since there is some information in DEVICE_INFO that isn't available anywhere else. (Such as sensor count and the DMX Footprint for a device that doesn't support personalities.)

> Unless of course there is still a completely different way
> of doing all this without sub-devices?
...
> Could the root have DMX_PERSONALITY settings for all
> the channels and modes as well?

There are several ways you could do it.
You could have several dozen different personalities for the root device, each with a different combination of modes. If you have 6 outputs in your device, you could have a personalities for "6 dimmers", "5 dimmers+1 switch", "4 dimmers+2 switches", "3 dimmers+1 switch+2 off" and so on. But there is a maximum of 255 personalities, soif you have more than 4 outputs there are not enough personalities to allow every possible permutation.

There's always manufacturer specific PIDs, but these will be even less compatible than the "unusual configuration".

In my opinion, personalities and sub-devices are the right way to handle it.

Are you sure you can't support patching on the sub-device level? I've seen one dimmer that does a great job of handling per-sub-device patching using four 7-segment displays and 4 buttons for the front panel UI.

> I am worried when you mentioned that some controllers
> will not handle this. I can just see the support calls
> srteaming in

What we're discussing is a corner case that the controller should be able to handle. But, it's not very helpful to tell someone that their controller is the problem when they're calling you for support.
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #7
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hello again.

I have implemented subdevices et all and I am testing with Enttech USB pro as well as Wybron gateway 4200 with Infogate 2.11.

Results are devastating so far.

The Enttech does detect everything quite well and the subdevices seem to funtion ok. Footprint on each subdevice is 1 and it shows the correct DMX address for each subdevice.
All my sensors also come up and I can see the values.
My root device seems to identify fine as well

The Infogate detects the device and 12 subdevices.
It however shows the the DMX address for each subdevice as 0 and also the DMX footprint. On the paramter button, it only comes up with "Remove DEvice from list"

The sensors all come up as SEnsor #1 with no units or anything showing and after a little while that box goes blank and locks up.

Identify device, if clicked identifyes for a split secong and then it reverts although the tick box remains ticked.

Sofrtware version does not show for subdevices

No paramters work when pressing the paramter button

I also note that it keeps issuing a Get DMX_PERSONALITY_DESCRIPTION command although this is not supported by the root device and is then NACK with "Unknown PID"

All in all, a disaster and very much unusable.

It appears that the controller(s) expect certain non mandatory PIDs to be supported in a specific way but without more information.
I am not sure how to proceed?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 13th, 2009   #8
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

> Footprint on each subdevice is 1

I suspect this is part of your problem. Because you implemented the patching on the root device, then you'll need to declare the root device to have a footprint of 12 (assuming 12 dimmers in your device).

Here's how I'd do it:
Root:
-0 personalities
-12 slot footprint

Sub-Devs
-4 personalities
-0 slot footprint (for all 4 personalities)

IDENTIFY_DEVICE must be supported on the Root device, but It's not mandatory for the Sub-devs.
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #9
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
> Footprint on each subdevice is 1

I suspect this is part of your problem. Because you implemented the patching on the root device, then you'll need to declare the root device to have a footprint of 12 (assuming 12 dimmers in your device).

Here's how I'd do it:
Root:
-0 personalities
-12 slot footprint

Sub-Devs
-4 personalities
-0 slot footprint (for all 4 personalities)

IDENTIFY_DEVICE must be supported on the Root device, but It's not mandatory for the Sub-devs.

Hi Eric,

I have it exactly like you mentioned.
The root device does have a footprint of 12.

Also, I did have 0 personalities on root but have now changed to 1 because either the Wybron or Enttech did not function when I had it as 0. I think it greyed out the DMX footprint and/or Base address. I forget now but it appears that I MUST support 1 personality - Weird.

Also, If I do give the subdevices footprint = 0, I am unable to display / edit andy personalities on the Enttech.

I have now changed to have a footprint of 1 for the subdevices. That should (??) be ok and for the DMX_BASE_ADDRESS I do only support Get for the subdevices.

Regards
Bernt

Last edited by berntd; October 13th, 2009 at 06:10 PM.
berntd is offline   Reply With Quote
Old October 13th, 2009   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

The general consensus is that you must have at least 1 personality. A device that doesn't support personalities should report 1 or 1, instead of 0 of 0.

> Also, If I do give the subdevices footprint = 0, I am unable
> to display / edit andy personalities on the Enttech.

I would argue that this is a bug in the controller. It's perfectly possible to have a device that has personalities, but doesn't use a DMX slot. (Consider an opto-splitter where you set the mode of the splitter via personalities).

Can you post your DEVICE_INFO response for both the root and the sub-devs?
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #11
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
The general consensus is that you must have at least 1 personality. A device that doesn't support personalities should report 1 or 1, instead of 0 of 0.

> Also, If I do give the subdevices footprint = 0, I am unable
> to display / edit andy personalities on the Enttech.

I would argue that this is a bug in the controller. It's perfectly possible to have a device that has personalities, but doesn't use a DMX slot. (Consider an opto-splitter where you set the mode of the splitter via personalities).

Can you post your DEVICE_INFO response for both the root and the sub-devs?
Hi Eric,

I agree. Further I have just found that, the Enttech will currently not show or allow changing of DMX_PERSONALITY if DMX_PERONALUITY_DESCRIPTION is not supported.
Hence my original statement that these controllers must have support for certain non mandatory PIDs and without me knwoing what they are, I am at a loos.

Device_Info responce root:
CC 01 2B 12 34 00 00 00 FF 00 00 00 00 00 01 0C 00 00 00 00 21 00 60 13
01 00
00 01
05 01
00 00 02 00
00 0C
01 01
00 01
00 0C
04
03 B2

From subdevice 1:
CC 01 2B 12 34 00 00 00 FF 00 00 00 00 00 01 00 00 00 00 00 21 00 60 13
01 00
00 01
05 01
00 00 02 00
00 01
01 04
00 01
00 00
00
03 8E

(I had to edit out the MID so checksum will be incorrect)


Kind regards
Bernt

berntd is offline   Reply With Quote
Old October 13th, 2009   #12
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Couple of things I notice:
The Sub-Device should report 12 sub-devices (Section 10.5.1 - Sub-Device Count).

I'd really rather see the sub-device have a footprint of zero and a starting address of 0xFFFF. (FFFF means not-supported). Otherwise the controller could think the devices needs 24 slots (12 for the root and 1 for each sub-device). Sounds like some controllers aren't happy with this though.

I've generally assumed that a device that supports Personalities also must support PERSONALITY_DESCRIPTION. It's not in the document, but it'd be hard for a controller to know what to do without it. Give the manufacturer a call, they can probably tell you what PIDs they require.
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #13
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Hi Eric,

I interpreted this by stating that stating that a subdevice has NO subdevices. Hence I report 0 for subdevices in the subdevice info. I just noticed that this is a WRONG assumption as p 59 states that this must alwasy report the subdevice count.
My mistake!

In my opinion, personalities can and should function without a description by simply showing them as the personality number.

The spec does not seem to mandate that DMX_PERSONALITY_DESCRIPTION must be supported if DMX_PERSONALITY is supported.

Perhaps we need to clarify this further?

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 13th, 2009   #14
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

So what's working and not working at this point? Are your sensors behaving?

> In my opinion, personalities can and should function
> without a description by simply showing them as the
> personality number.

I'd agree with you, the controller should function that without it. But, you can't guarantee every controller will be properly written, and having PERSONALITY_DESCRIPTION will make things work better with some controllers. And practically speaking, PERSONALITY_DESCRIPTION is useful enough you'll probably want to implement it even if you don't have to. Having the text string available is *very* handy for the end user.
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #15
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by ericthegeek View Post
So what's working and not working at this point? Are your sensors behaving?
Hi Eric,

With reporting 12 for subdevices, nothing has changed at all.
Infogate still shows DMX address and footprint = 0 for all subdevices.
Sensors are still showing "Sensor#1" as before (no values)
and identify also has not improved.
Still can't see anything under "Paramters".

Enttech Rdm sniffer shows that controller is sneding a round robin set of commands
SUPPORTED_PARAMTERS (subdev8)
Set IDENTIFY (root off)
Get DMX_START_ADDRESS (root)
SUPPORTED_PARAMTERS (subdev7)
Set IDENTIFY (root off)
Get DMX_START_ADDRESS (root)
SUPPORTED_PARAMTERS (subdev9)
Set IDENTIFY (root off)
Get DMX_START_ADDRESS (root)
SUPPORTED_PARAMTERS (subdev5)
Set IDENTIFY (root off)
Get DMX_START_ADDRESS (root)
SUPPORTED_PARAMTERS (subdev8)
and so on.

In addition to our discussion here, I am trying to contact the manufacturer.

Enttec USB_Pro controller:
Comes up ok. Show sensors immediately with correct headings and values.
Shows all the supported parameters.
All over not too bad.

Kind regards
Bernt
berntd is offline   Reply With Quote
Old October 13th, 2009   #16
sblair
Administrator
 
Join Date: Feb 2006
Posts: 433
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Bernt,

Wybron is fairly good to work with if you contact them directly. I've done a lot of debugging of the Infogate for them in the past. If you need any help getting in touch with them let me know.

You can of course send your product to them with a check for $250 and they'll test the compliance of it to the standard and get it "IFE Certified"

http://www.fbexcellence.org/

This is why I'm a strong supporter of what we are doing with the ESTA RDM Plugfests and a critic of the "IFE" effort as compliance really only means it works with their product and not correctly to the standard. It's like a Microsoft standard in that regard.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old October 13th, 2009   #17
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 375
Default

Not sure what else to tell you. The big thing that bothers me is that your Sub-Devices have to lie and claim they have a DMX footprint when they don't, and claim to have a DMX address when they don't. This may cause as many problems as it solves.

Now that you have the personality stuff cleaned up, what works and what fails if you have the sub-device with a footprint of zero and a starting address of 0xFFFF? I know you tried this earlier, but I think it was before PERSONALITY_DESCRIPTION was added.

Anyway, have a good night, I'm off to bed. I've been staring at code all night and I've had enough...
ericthegeek is offline   Reply With Quote
Old October 13th, 2009   #18
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default

Quote:
Originally Posted by sblair View Post
Bernt,

This is why I'm a strong supporter of what we are doing with the ESTA RDM Plugfests and a critic of the "IFE" effort as compliance really only means it works with their product and not correctly to the standard. It's like a Microsoft standard in that regard.
I agree fully. Certifications should be done by test houses.
berntd is offline   Reply With Quote
Old October 14th, 2009   #19
berntd
Senior Member
 
Join Date: Jan 2008
Posts: 102
Default SLOT_INFO ?

Hello all,

Should I implement SLOT_INFO for my subdevices?
With my current setup of 1 subdevice per channel, should they be ST_PRIMARY or ST_UNDEFINED and also, I am thinkink of making the ID = SD_UNDEFINED for the sub-devices.

In the root, I support this command as ST_PRIMARY and ST_INTENSITY.

What is the most "correct" way? :-)

Regards
Bernt
berntd is offline   Reply With Quote
Old October 19th, 2009   #20
prwatE120
Task Group Member
 
Join Date: Jun 2006
Posts: 181
Default

Berntd

I see from your earlier posts that you are using Wybron Infotrace v2.11.

The current version is 2.2, and may well have addressed a nimber of the issues you have been discussing.
prwatE120 is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the basic requirement to implement RDM? wcai_cypress RDM Physical Layer/Hardware Discussion 24 July 8th, 2009 08:26 PM
Simple dimmer error reporting Milton Davis RDM General Implementation Discussion 3 November 7th, 2008 11:15 AM


All times are GMT -6. The time now is 12:30 PM.


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