E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Interpretation Questions

RDM Interpretation Questions Discussion and questions relating to interpreting and understanding the E1.20 RDM Standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old June 25th, 2013   #1
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default DMX_BLOCK_ADDRESS (Set)

In E1.37 Section 3.3, the final statement reads:
This message shall not have any effect on the DMX512 Start Address for the root device, only the sub-devices.


Any of you wise folk out there able to enlighten me on the rationale of this statement?

I have a fundamental problem with this, in as far as that root devices, when contiguosly addressed, may not be represented on the root device without falling fowl of this directive. The upshot of this, is that any responder implementing Block Addressing will undoubtedly hit the otherwise avoidable limitations of many controllers.


Take into account also, as was discussed at the last plugfest in April, it was suggested that sub-devices* do not have to support DEVICE_INFO.
If any one can't see where I'm going with this, I can elaborate...

*Edited, did read root-device
__________________
______________________________________________
Hamish Dumbreck

Last edited by hamish; June 25th, 2013 at 12:28 PM. Reason: referential error to root-device
hamish is offline   Reply With Quote
Old June 25th, 2013   #2
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

I've never really liked the block address PID. I feel that any kind of block addressing should be handled as a for() loop in the controller rather than in the responder.

The DEVICE_INFO PID is required for root devices.

On sub-devices, there's nothing in the text that requires DEVICE_INFO, but my conclusion is that practically speaking you have to implement it for sub-devices. Otherwise there's no way to find out how many sensors a sub-device has.
ericthegeek is offline   Reply With Quote
Old June 25th, 2013   #3
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default

Eric.

Thanks for pointing out the error in my last, referring to a root device when I really meant a sub-device

I'm trying to figure out what trap I'm going to fall in to if I drive a coach and horses through the standard by wilfully disregarding the shall statement. Usually, there is a good reason that I've not considered...
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old June 25th, 2013   #4
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 358
Default

I fear I'm being a bit dense and not fully understanding the problem.

You have a RDM responder that has both a Root device with a non-zero slot footprint, and also has Sub-Devices with a non-zero slot footprint. Say for example a dimmer rack with a "fan speed" slot on the root device, and 24 dimmers, each with its own sub-device and a slot footprint of one.

The standard says that if you issue a Block Address PID with an address of 11, that the 24 dimmer sub-devices should get addressed from 11 to 34, but the root's fan-speed address will remain unchanged.

The behavior you want is to set the root's fan speed slot to address 11, and then address the 24 dimmers from 12 to 35 when you receive the Block Address PID?

For any controller that does support Block Addressing, I think this would cause a problem. When the user tries to auto-patch, it will add up the number of slots used by every sub-device, and then try to patch it. If the controllers sees 12 slots worth of dimmer sub-devices, it will reserve a block of 12 slots during auto-patch. If the responder actually patches 13 slots (root + 12 sub-devices), you'll likely get an address conflict on the 13th slot.

The simple solution is don't support the Block Address PID. :-) Since it's not a required PID, controllers will have to work with responders that have sub-devices but don't support block addressing.


Here's a previous thread discussing sub-devices and the DEVICE_INFO PID.
http://www.rdmprotocol.org/forums/showthread.php?t=1136

My controller implementation requires that any sub-devices support the DEVICE_INFO PID. If the responder NACKs DEVICE_INFO, the controller displays and error and ignores the sub-device. Without DEVICE_INFO, you'd just got no place to start. Some of the information from DEVICE_INFO can be collected or inferred other ways, but none of them are 100% dependable (sending a GET SENSOR_DEFINITION to all possible sensors, etc).
ericthegeek is offline   Reply With Quote
Old June 25th, 2013   #5
hamish
Member
 
hamish's Avatar
 
Join Date: Apr 2009
Location: Dartmoor, Devon, England
Posts: 54
Send a message via Skype™ to hamish
Default

Quote:
Originally Posted by ericthegeek View Post
The behavior you want is to set the root's fan speed slot to address 11, and then address the 24 dimmers from 12 to 35 when you receive the Block Address PID?.
The problem domain is a little less complicated than that. The Root device has no real DMX slots, just virtual ones that represent the sub-devices, but only when the sub devices are contiguous. So:

When contiguous, Root DMX address = sub device DMX address and root foot print = sum total of sub device slots.

For example, if there are 10 sub-devices from 13 to 22, contigouosly adrressed. Root DEVICE_INFO reports DMX Address 13, footprint of 10.

Sub device 5 address is changed from 17 to 2.
The responder is no-longer contiguously adressed.
Root DEVICE_INFO reports DMX Address FFFF, footprint of 0.

The shall rule is not explicitly violated as the DMX address is the same, the footprint has changed.

Now we set the BLOCK_ADDRESS to 1
Root DEVICE_INFO reports DMX Address 1, footprint of 10.
The shall rule may be technically violated but is of no consequence to a controller, more important is that the footpring has changed which is not prohibited by the standard.

Next we set the BLOCK_ADDRESS to 2.
Root DEVICE_INFO reports DMX Address 2, footprint of 10.
The shall rule has been explicitly violated as the root DMX address has now changed.

The Idea of allowing the flexibility to remain while contiguous, is to enable the many controllers that don't really do sub-devices to change the BLOCK_ADDRESS (providing that the responder is already contguously addressed) by using the setting the root DMX Address, which I see nothing in the standard to counter...

If one is not able to track the other, it makes a nonsense of the whole scheme.
__________________
______________________________________________
Hamish Dumbreck
hamish is offline   Reply With Quote
Old June 25th, 2013   #6
sblair
Administrator
 
Join Date: Feb 2006
Posts: 417
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Hamish,

I may just be getting sleepy here but I'm not too offended with what you're proposing there. The Block Address PID was created because there were some folks doing some very bad things with the normal DMX Start Address PID with 0 and values above 512 for crude Block Addressing.

As Eric said one of the main things we didn't want is strange things happening with the root device address when using the Block Address PID. We also were trying to be clear so that it wasn't ambiguous if the Block Address PID would include the root device or not include the root device where it would be a guessing game for a controller. In your implementation you don't really have a root device slot, they are just virtual. The main thing I would say is that when you change modes like that you need to at least send out QUEUED messages alerting the controller that the footprint has changed...
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old June 26th, 2013   #7
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

I like the idea as reporting contiguous sub-devices as virtual rootdevice, but then I see the problem of identifying this as "virtual" root device.

Going with Hamish' example, "Now we set the BLOCK_ADDRESS to 1.
Root DEVICE_INFO reports DMX Address 1, footprint of 10.
"

What will occur? When reading the device info, it will tell me:

- I have a root device with a start address and I have 10 slots used. Reading the subdevice count field, I see that I have (additional) Sub-Devices present. So I read all the Sub-Devices and find, there are ten more slots (so now I have a total of 20 slots used), and I find, the subdevice addresses conflict with what I have already read for the "virtual" root (overlap).

Wrong or right?

Thus I would assume, reporting a start address and footprint for a "virtual" root device is not possible at all without creating additional confusion... We should separate rootdevice info and subdevice info as much as possible.

I would like to offer two solutions for the problem "to enable the many controllers that don't really do sub-devices":
- add additional functionality to the controllers under review, or
- make using subdevices optional.

We have chosen the latter option. Units are shipped as root devices having a start address and a number of slots used. User can activate subdevice functionality calling a manufacturer function called "ENABLE SUBDEVICES". When done, the unit identifies itself as rootdevice using no slots and so start address, but features a number of subdevices instead. BLOCK ADDRESS will only affect subdevice addressing, and never report to rootdevice data.

Comments welcome.
este_ is offline   Reply With Quote
Old June 26th, 2013   #8
pkirkup
Task Group Member
 
pkirkup's Avatar
 
Join Date: Feb 2009
Posts: 4
Send a message via Skype™ to pkirkup
Default

I tend to agree with Eckart - a controller will almost certainly see and treat the subdevices as additional to the root device, rather than assuming the virtual link. Therefore when discovering your scenario above, the controller would see 20 slots occupied, with a start address conflict.

One solution would be to report a root address but a zero footprint, but that would conflict with:
Code:
If the Device or Sub-Device does not utilize Null Start Code packets for any control or functionality then it shall report a Footprint of 0x0000
Code:
If the Device or Sub-Device that this message is directed to has a DMX512 Footprint of 0, then this field (DMX512 Start Address) shall be set to 0xFFFF.
Maybe an addendum to E1.37-1 which defines a footprint of 0xFFFF as 'virtual start address'?
__________________
Peter Kirkup
VP Entertainment - LumenRadio AB
peter.kirkup@lumenradio.com
pkirkup 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
ACT_TIMER to Set messages nic123 RDM Interpretation Questions 3 April 18th, 2014 12:01 PM
Relative frequency of UID set changes to RDM messages events nomis52 RDM General Implementation Discussion 6 July 6th, 2010 10:02 PM
Sub-device response to SET/GET DMX512 start address p_richart RDM Interpretation Questions 2 September 29th, 2006 09:27 AM


All times are GMT -6. The time now is 11:57 AM.


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