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 June 27th, 2010   #1
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default Relative frequency of UID set changes to RDM messages events

Hi,

I'd like someone to validate an assumption I've made while writing an RDM implementation or tell me that I'm completely wrong .

I'm looking for the relative frequency of UID set changes to RDM message events (get/set pid). My gut feeling is that this will be at least 1:100, i.e. on average for every time this UID set changes (one or more UIDs added/remove) there will be 100 or more RDM messages sent.

Does that sound about right?

Thanks,

Simon
nomis52 is offline   Reply With Quote
Old June 27th, 2010   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Hey Simon,

I'm not certain if I'm fully following you here. Are you asking the relative ratio of RDM GET_COMMAND messages to SET_COMMAND messages?

If so, I would say that yes you will many more GET messages than SET messages occuring. There are times (configuring/patching a rig) where the number of SET messages will dramatically increase.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 5th, 2010   #3
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Ah sorry, reading my post I've realized it's ambiguous. By 'UID set' I mean the group of UIDs that were discovered for a universe.

So I'm asking for the relative frequency of these two events:

i) The Ongoing Device Discovery process noticing a change in available UIDs
ii) Any GET/SET command being sent.
nomis52 is offline   Reply With Quote
Old July 5th, 2010   #4
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Ahh, I see what you are asking now. There isn't any specific requirements concerning the frequency of these.

You want the ongoing discovery to happen fast enough that it appears to be semi real-time...i.e. within a minute or so ideally.

When a new device is discovered there are only a couple messages it should need to fire off to get just enough info in order to put it in a display and then it can drill and get the remaining info as needed.

From a practical standpoint, the speed is going to be determined by the number of devices on the data link. The fewer the devices the faster the controller can get around to querying them all. Unless a controller is in the middle of a crossfade, then doing a 1-1 interleave with RDM and NSC packets is pretty typical.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old July 5th, 2010   #5
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 359
Default

I don't think there's any way to answer that question. During rig setup or wring-out, you could see the UID list change several times in a minute. Someone unplugs one branch from the RDM hub and 20 devices disappear. They fix a cable problem, plug it back in thirty seconds later and new devices come online. A loose connection could cause the list of reachable devices to change from second to second.

In other situations, the rig won't change for months on end.

Can you be more specific about the problem you're trying to solve? A DUB request+response is slightly more expensive time-wise than most GET/SET request+response pairs, but only by a few milliseconds.
ericthegeek is offline   Reply With Quote
Old July 6th, 2010   #6
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by ericthegeek View Post
Can you be more specific about the problem you're trying to solve? A DUB request+response is slightly more expensive time-wise than most GET/SET request+response pairs, but only by a few milliseconds.
I building a multi input -> multi output rdm message router (which leads to other interesting problems) and I'm trying to decide if I optimize the UID -> output port data structure. I can make the lookups more efficient by increasing the complexity of building the structure when the set of UIDs change.
nomis52 is offline   Reply With Quote
Old July 6th, 2010   #7
sblair
Administrator
 
Join Date: Feb 2006
Posts: 419
Send a message via AIM to sblair Send a message via MSN to sblair
Default

When a system is up and running you'll find that it is very stable with few UID changes.

There are two major points where you'll see a lot of UID change chaos happening though:

1. When a system is getting powered up for the day, as each part a system is powered on you'll see a lot of UID list changes. This also includes setting up a system for a one-off show.

2. When troubleshooting a system. At that point you'll see cables being swapped around and plugged in and out, so that will result in a massive amount of UID's coming off and online.

Hope this helps.
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair 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 01:01 PM
DISC_UNIQUE_BRANCH dest UID (section 7.3) berntd RDM Interpretation Questions 5 October 15th, 2008 10:06 PM
Sub-device response to SET/GET DMX512 start address p_richart RDM Interpretation Questions 2 September 29th, 2006 10:27 AM


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


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