RDM merger

[sessiondrummer]

Hi guys.

 

I've seen a lot of RDM splitters on the market, but no mergers.

 

Do they exist?

 

and if so who manufactures them??

 

Hope someone can end this mystery for me

 

Ben

[Woofy]

Well I hate to say it can't be done because someone is bound to find a way, but I don't see how an RDM merger is even possible - at least not without placing a lot restrictions on the operator. RDM discovery would fail if both desks tried to do it at the same time.

 

It might be possible to do a switch with just one RDM controller in operation at a time, such as when using a second desk as a backup.

[J Pearce]

It might also prove possible to have an RDM compatible merger, so that one feed is full RDM, the other just DMX data.

 

This could be useful where RDM is used in an install to monitor lamp life/temperature/faults etc, but visiting companies want to tap into the DMX with their desk.

[Brian]

...because someone is bound to find a way, but I don't see how an RDM merger is even possible...

Discovery is carried out by the merger itself which builds an internal database of connected devices. Incoming discovery messages from attached consoles are then responded to by the merger from its virtual device pool.

[Woofy]

...because someone is bound to find a way, but I don't see how an RDM merger is even possible...

Discovery is carried out by the merger itself which builds an internal database of connected devices. Incoming discovery messages from attached consoles are then responded to by the merger from its virtual device pool.

 

If you go that route, you may as well make the merger a proxy. The desk(s) can then use the proxy management commands to retrieve the responder list instead of doing a second full discovery sequence. However this is taking responsibility for discovery (and rediscovery) away from the desk.

 

There are other issues involving interleaving DMX & RDM streams as well, which could potentially put a huge burden on the system.

 

Jon's suggestion seems more practicable but,

Ben, what are you trying to achieve here? Do you have a real problem or is it just an idle query?

[sessiondrummer]

Hi guys,

 

was just a thought going through my head as I just thought a merger might operate for RDM in the same way as for DMX. For the install I am designing that incorporates RDM,I want to have multiple access points to the DMX system. I've decided to use RJ45 and a patch panel to achieve this now.

 

I guess an idle question is a blunt way to put it woofy but I thought it was valid none the less.

 

Ben

[Woofy]

I guess an idle question is a blunt way to put it woofy but I thought it was valid none the less.

 

Ben

 

Hi Ben, its a perfectly valid question. No bluntness was intended, my appologies for giving that impression. I used the word "idle" as in "pondering the issue in a quite moment". I was just wondering if you were working on a problem or if it was curiosity.

 

It seems Jon's suggestion would do the trick, merging DMX streams with a single RDM channel is reasonably easy. Its merging multiple RDM channels that's difficult to do in a usable way.

 

In any case, lacking any hardware out there your patch panel is as good as any.

 

Regards,

Gerry.

[peternewman]

Firstly I should probably say I've not seen the RDM spec/used RDM kit myself, I've just read what Wikipedia has to say, and done a number of networking courses over the years and fiddled about with a variety of protocols. I am however curious.

 

Woofy do I take it that the spec includes a special proxy command to retrieve the full list of devices from a proxy, Wikipedia is a bit vague on this part and seems to imply the proxy would just spoof the responses of the individual devices during discovery, which I imagine could only possibly offer a marginal speed up by not colliding/replying for so long, compared to the obvious speed benefit of just being able to request/send a full list.

 

I'm assuming the RDM packets feature the intended recipient or similar, in which case could you not do a NAT like implementation to solve the issue of actual data after the discovery section. What would appear to be more of an issue would be keeping the two devices which want RDM in sync. It's no good if they both want to try and set DMX addresses at the same time, however for say a desk and some monitoring kit it might work okay, so one does all the control stuff and the other is only really interested in polling to see what's broken. I guess Wybron and the like might be worth a look, as I assume they do this or a similar solution for their products anyway.

 

As to your actual problem, if you could guarantee there would only ever be one desk plugged in, it feels like you should be able to do something with a DMX merger for the data flow from desk to fixtures, and an RDM splitter running backwards and then tweak the electronics a bit to make it all work. Perhaps just remove the receive side of those chips and parallel up with the splitter. Come to think of it, and again I'm lacking info on the spec here, would simply running an RDM splitter in reverse not be sufficient (unless it does some clever state based stuff that waits for what would normally be the desk to transmit). It would see input from the desk plugged into one output (be it DMX or RDM data) and send this out of the input to the fixtures, replies from the fixtures would reach the input and be sent to any connected desks. Although I guess if the splitter did some simple collision avoidance by only allowing the first device on an output to transmit, and blocking the others from reaching the input until it had stopped, then plugging another desk (RDM or not) into another output might cause issues.

 

Your's curiously...

 

Hopefully I'm not too far off the mark/haven't muddied the waters too much.

[Woofy]

Peter, yes there are a couple of specific proxy commands to get the proxied device count and the proxied devices. In addition to that the standard dicovery mute and unmute messages can contain optional 16 bit control field and binding ID. A proxied device can inform the controller it is proxied and pass the UID of the proxy. The controller can then go directly to the proxy and get all proxied devices without searching for them.

 

RDM packets do contain source and destination UID's, I'm not sure how NAT would help here though.

Athough there is provision in the RDM protocol for inline devices such as splitters, there is no provision for collisions between multiple controllers. RDM timing, which is tightly controlled compared to DMX, does not easily allow for an inline device to service two masters.

[peternewman]

I've been informed that some/most RDM splitters deal with the discovery themselves, presumably acting as a proxy, so my running backwards idea might not work, the issue with "clever" technology I guess.

 

NAT in the sense of if the incoming packets had the same ID (however I'm guessing UID is unique ID, so this might not be an issue), you could do some trickery so they wouldn't both try and contact a device at the same time. So not true network NAT, but a similar idea implemented on an RS485 network. Queueing requests up, or only sending them back to the requesting controller, so the other one doesn't get confused. I'd imagine this would mean you could stop collisions on the fixture side of the merge (only send packets from one at a time), and on the controller side by queuing/routing to the correct port. However I'm assuming your timing comment is related to delays/response time/fitting in the break or similar, which may make all my ideas somewhat irrelevant/impossible.

[Tomo]

Each physical RDM device is supposed to have a Globally-Unique ID.

- This is done the same way as MAC addresses, whereby ESTA assign a 'manufacturer code' to each fixture manufacturer, which is the 'prefix' to their devices.

It's then the manufacturer's responsibility to ensure that everything they make has a unique ID, using any technique that works for them.

 

(There are a couple of 'R&D' manufacturer codes for initial development work of course)

 

RDM timing is absolutely critical - the bus must turn around in a very short period of time, and Discovery actually *requires* that collisions happen, so proxies are pretty much the only way of implementing splitters.

 

ETC handles multiple controllers by doing all RDM in the Net3 DMX/RDM Gateway, then using ACN to communicate with multiple consoles.

This works pretty well as ACN is designed to handle multiple data sources and data sinks within one system.

 

So really, this is the only RDM Merger that exists - it doesn't really do RDM merging, instead it changes RDM into ACN.

[Woofy]

Discovery actually *requires* that collisions happen,

Discovery allows for collisions, but does not actually require them.

 

so proxies are pretty much the only way of implementing splitters.

While splitters can be proxies its not required, if all you want is a splitter it will work fine without being a proxy.

[jpk]

ETC handles multiple controllers by doing all RDM in the Net3 DMX/RDM Gateway, then using ACN to communicate with multiple consoles.

This works pretty well as ACN is designed to handle multiple data sources and data sinks within one system.

 

So really, this is the only RDM Merger that exists - it doesn't really do RDM merging, instead it changes RDM into ACN.

 

I have an ArtNet RDM capable merge unit under development. I note on the ETC site there is mention of Net3 being documented for public use. Supporting ACN is something I'm very keen on, however at present that can only be E1.31

 

Jason