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)
-   -   RDM discover driving against dmx input (wrong cabling) (http://www.rdmprotocol.org/forums/showthread.php?t=1082)

MichaelStickel January 24th, 2011 03:03 AM

RDM discover driving against dmx input (wrong cabling)
 
Imaganing the following situation. You have a desk that speaks RDM

I have two consoles connected to each other with a bad cable (male-male) one (A) sending RDM+dmx intermixed and one (B) sending dmx only. What then happens is that the dmx driven by (B) is interpreted as RDM if (A) sends a discover request.

Such a situation can happen if I want to link one console to another and first make the physical connection and then switch the port from output+RDM to input.

If this happens before sending RDM, I can detect it by scanning the line when not sending dmx and muting RDM, when something is received, that did not come from me (A). But what can happen also is that someone plugs some console while I do a discover and then I misinterpret it as a collision and a very deep search is done.

Has someone expierienced the same problem?
Is there a common solution?

Kind regards,
Michael

ericthegeek January 25th, 2011 11:44 AM

What you are describing is not a valid configuration. You can only have a single RDM controller or DMX console on a DMX universe at any one time.

Just like DMX, RDM allows you to have multiple light fixtures (called Responders in RDM), but you can't have multiple consoles (called Controllers in RDM).

What are you trying to accomplish? If you need to have a main console, and a backup console you'll need a switch to choose between them.

MichaelStickel January 26th, 2011 03:30 AM

Yes, you are right, this is a wrong configuration.
But that is what can happen in the middle of a setup procedure.

Imagine following setup:
- One console (A) to which all lights are connected via dmx dmx-ports 1..3.
- Second console (B) connected to console (A) via 3 dmx universes to consoles dmx-ports 4..6.
- Console (A) controlls all the moving lights
- Console (B) controlls all the conventionals
[Console-B]--->[port4..6 | Console-A | port1..3] -----> Lights

and the following Workflow:
- Console (A) has all ports configured as output
- Console (B) has all outputs configured as outputs.
- The technican connects all the lights to port 1..3
- The technican connects three outputs of console (B) to ports 4..6 of console (A).
At this point the ports that connect the consoles are driving against each other.
- Now the operator configures the ports 4..6 of console (A) as inputs.
At this point anything is back to normal.

This is a situation that may happen. The duration depends on the time between connecting the two consoles and setting the right configuration.

sblair January 26th, 2011 09:39 AM

Michael,

This is the first time I've ever heard of this issue being raised. There's not a lot that can be done if two controllers are both driving the line at the same time. RDM runs on top of DMX so if DMX isn't even in a functional state then there isn't a huge amount that can be done.

If both consoles involved are your own, then you might investigate doing some intelligent monitoring of the line even during normal DMX transmission. If you read back your own data on the line as you are transmitting DMX and you see it getting corrupted then it is easy to determine that there is another controller driving the line as well and you can back off or alert the user in some intelligent way.

The controller doing RDM Discovery can also determine that something is horribly wrong too, when it gets to the bottom of the branch and finds it can't mute anything then it can abort discovery and give the user an appropriate error. Presumably if you have another controller driving the line then you are going to directly to the bottom of the very first branch and then stay there and nothing will be mutable so that would probably be a pretty easy scenario to detect.

Hope this helps.

Scott

ericthegeek January 26th, 2011 12:38 PM

There are several RDM hubs that do jabber detection. This would solve the problem that you are describing. It works by looking for activity on the line during the 176us turnaround period.

After an RDM request (DUB or Normal request), there is a 176 microsecond period before the response can start. If there is any activity on the line during that time there may be a jabbering device.

In the case of a hub, it can cut off the port that has the jabbering device for a few seconds. On a console, you could warn the user.


All times are GMT -6. The time now is 12:43 AM.

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