RDM on DMX ports

as far as i know, at the moment, rdm is only supported by net3 nodes, but not the local ports. the hardwire ports have been prepared with a firmware update to support rdm, but the software function hasn't been implemented yet.

Hmm interesting,

I am trying to troubleshoot my hazer and was looking at the splitters.  They are seeing RDM messages from the board.   Very odd if not active yet.

RDM on the native ports is scheduled for 2.1.  It may seem weird that it isn't supported now, but it's completely different hardware than the gateways.

Hope that helps.

a

Thanks Anne,

Just found it odd the pathway splitter was still able to pick up some RDM via hard DMX if not supported until 2.1.

 I am loving the GIO.  As a general question, we currently go hard dmx to the stage with the Gio and our RPU where the DMX gets merged for uni A & B.  When Lowell was out for our demo he was leaning towards having a net3 gateway do the work between the desks and then send the DMX out to the stage.  I have been playing with the mergers and they have not been perfect when testing switching DMX signal in a test setting simulating a failure.  Is the Gateway method truly the preferred way when you have a backup setup? 

Hi Brendan... well, networked distribution is easier as there is less gear involved --- no DMX mergers or worries about switching.   So, yes, it is generally recommended to go with gateways when possible when working in a primary/backup environment.   

?

a

Thanks Anne.  That may be the better way to go.  

Can I also ask the reason the GIO (as per the manual) is set as the backup unit when used with an ION RPU as primary?  I found it odd the GIO processor, which I assume has more power, would not actually be running the show, but just being used as a program surface.  Is there any reason why the Gio could not be set as Primary?   I understand the manual notes that if the RPU as primary went down you would still have the Gio surface, but I do not see the difference even if the GIO was primary.  If the RPU goes down as the backup unit I still have the Gio.

Thanks Again,

i think where you went wrong is here: RPU=main, Gio=backup. main goes down, you still have buttons. but when Gio=Main and RPU=backup and the Main goes down, you have no buttons to press. i assume, the main is more likely (albeit still very rarely) to fail than the backup, independent if the main is an RPU or a Gio. the question is, do you have a surviving controller that you can handle easily (i.e. with buttons) or not...

i think where you went wrong is here: RPU=main, Gio=backup. main goes down, you still have buttons. but when Gio=Main and RPU=backup and the Main goes down, you have no buttons to press. i assume, the main is more likely (albeit still very rarely) to fail than the backup, independent if the main is an RPU or a Gio. the question is, do you have a surviving controller that you can handle easily (i.e. with buttons) or not...

I think I do. The RPU has 20 buttons on the front and we have a mouse, keyboard, and screen attached to it via a switcher.  So I can switch to the RPU and control it without an issue in a pinch.  Not as easy to program, but for hitting go and stop it should not be an problem.  So, based on this I am just wanting to know if there is any other reason why the GIO could not play as Primary?

there is no reason, i'm aware of.

in my personal modification of murphy's law it says that crap on crappy days travels in groups. so in the same show when the master fails, something else is prone to go wrong and i'd  be glad to have a real facepanel instead of 20 buttons, a keyboard and a mouse...

i know, call me paranoid ;)

True, but if it is the backup that goes down, are you not in the same boat having to use your RPU Primary?

absolutely. but i think the working theory is that the master is more likely to fail because it's doing all the work and is being exposed to all the triggers.

so what do we conclude? you want to have a console for both backup and master. and at least another one as client as well ;)