EOS and RDM

Todd

2 Question for you.  Are you using the gateways in Net3 Mode?  Is RDM enabled on the Net3 Gateways?

P-

Yes, the gateways were in Net 3 mode (set from the GCE) and RDM was enabled on the outputs.  I was able to see the # of discovered devices on the GCE for each output.  I was also able to see RDM activity on the EOS Diagnostic screen.

-Todd

Todd,

Do you have RDM checked (enabled) in the Shell?  Settings>Network>Advanced Features

Once that is enabled in the Shell, start the application and go to Patch.  Press the [RDM Discovery] button to Enable it.  Eos will then get all of the RDM information from the gateway.  If you view Patch by Address (pressing [Format] to switch between Address and Channel) with a Flexi mode of Patched Address, that is the easiest way to see if Eos discovered any RDM devices.

Hope that helps.  If you have any more questions, let me know.

Steven,

I did have RDM enabled in the Shell on our EOS console (backup)- I'm not sure about on the RPU (master).  I'll have to check next time I'm in the booth.  I was seeing RDM messages in the Diagnostics tab, so I know it was communicating with the devices and changing addresses from the console.

I did not try viewing patch by address to see if the devices were listed.  I will give that a try.

I did have some issues with the Seachangers that may be RDM related or not- since I only have 2 Net3 gateways but a bunch of Net2 nodes, our system is a hybrid of Net3 and Net2 devices.  I had 3 Seachangers plugged into a Net3 gateway and sitting in no color (open white).  I noticed that about every minute or so, one of them would change color and then go back to open white- sort of a color bump.  This wasn't happening with the Seachangers that were plugged into Net2 nodes.  I didn't have time to track down the problem, so I set the Net3 gateway to Net2 mode and the problem went away.

Could this be an issue with RDM interfering with the DMX stream?  I don't think RDM discovery was on when I noticed the problem.  I also read that RDM requires termination on the data line- I'm guilty of not terminating short runs of DMX unless there's a bunch of devices on the line and I notice problems.

 Any ideas?

Thanks,

Todd

Hi Todd-

RDM is indeed much more picky about termination.

It would be interesting and useful to know:

a) Does anything change with termination?

b) Does anything change with RDM turned off on the ports in Net3/ACN mode?

-luke-

Also, do you recall the DMX addresses of the SeaChangers that did this?

Okay, I finally had some dark time to test RDM in a "real-world" scenario yesterday:

• EOS console (backup), RPU (master), s/w  ver. 1.7, RDM enabled in shell on both
• 1x Net3 4-port gateway, s/w version 2.0.0.9.0.14, all output ports set as Univ 4 w/ RDM enabled, RDM discovery enabled, 1000ms refresh
• 3x Seachanger XG model A451-01-03, DOM 4/2/08, s/w version 2.10
• data path: RPU to gateway via ACN -> 100' DMX cable from port 1 on gw to 1st Seachanger -> 25' DMX to 2nd Seachanger -> 25' DMX to 3rd Seachanger -> DMX terminator.

1. Did a deep clear of both console and RPU.  Started EOS on RPU and console- used console for all input.
2. Powered up the seachangers, went  to Patch and turned on RDM discovery. Changed view to patch by address and found the Seachangers at addresses 1573, 1579 and 1585.  Patched them to channels 1 thru 3.  Patched the lamp circuits into part 2 of channels 1 thru 3.
3. Brought up the intensity on channels 1 thru 3.  Lamps come up and color shifts progressivly greener with intensity.  [color][home] has no effect, color picker shows dot at white.  Discovered that the EOS chose the fixture profile of Seachanger_6ch, not Seachanger_XG_6ch, so the green wheel was linked to intensity.
4. Repatched 1 thru 3 to correct fixture profile.  Output is now open white.  Every so often (5-20 seconds), one of the color wheels in a Seachanger will bump to full intensity, then back to open.  This happens on all three Seachangers, but not at the same time.
5. I checked ACN levels with SACN viewer- levels are not changing.  Checked DMX output at the end of DMX line- levels are not changing.
6. Turned off RDM discovery on EOS patch screen- no change.
7. Using GCE, turned off RDM discovery on all ports of gateway-  no change.
8. Disabled RDM on port 1 of gateway- color wheels stop moving and fixtures stay in open white.

So there appears to be some sort of incompatibility with RDM and the Seachangers.  I'm not sure which part of the system is causing the problem- the ETC implementation of RDM or the Seachanger implementation.  I'm going to contact Ocean Optics and see what they say about this.

A few other things I tried with RDM (ignoring the color bump issue) and some observations:

• I wanted to see how easy it was to remotely change addressing on the Seachanger addressed at 1573.  By going to [live] [about] [address] 1573, then choosing {device details}, I was easily able to change the address to 1537 (4/1).  The fixture did not need to be patched to a channel to do this.
• I then tried to overlap addressing to see what would happen.  I remotely changed the start address on another Seachanger from 1579 to 1541 (4/5), which overlaps with the address range of the first Seachanger (4/1 to 4/6).  EOS did not give any error message about overlapping ranges.  The Seachanger that was addressed at 1537 (4/1) disappeared from the patch screen and the second Seachanger appeared at address 1541.  I was still able to access the first Seachanger if I did [about] [address] 1537, so I changed its start address to 1556 (4/20) and it re-appeared on the patch screen at that address.
• Next, I wanted to test to see how it handled 2 devices with the same address.  I changed the start address for the first Seachanger from 1556 to 1541 so that it matched the second Seachanger.  Once again there was no error message from EOS about the overlapping addressing.  The patch screen only showed one device at address 1541- there was no indication that there were multiple devices with the same address.  I was able to change address on  one of the Seachangers by doing [about] [addresss] 1541 {device details}, then noting the device ID (67791), changing the address to 1537 (4/1) and checking to see that the Seachanger that appeared at address 1537 had the same device ID. The other Seachanger that stayed at address 1541, so the patch screen showed two devices, one at 1537 and one at 1541.

My comments:

• It appears that the Seachangers are not reporting accurate enough information to the console to enable it to choose the correct fixture profile.  I think the Seachanger implementation of RDM is very basic and perhaps too generic and not model specific.  With our Wybron Coloram IT's, the information that was reported was much more complete.
• You have to be in the Patch by address format to see the discovered RDM devices.
• There is no indication that fixture addresses overlap- if you have devices with overlapping address ranges, one of the devices is simply not shown on the patch screen.
• The console doesn't provide an easy way to see the unique RDM identifier for a device- to access a device you have to use its DMX address, which is not a fixed value.  This adds the potential for a lot of confusion when trying to sort out overlapping addresses, or when trying to re-address a whole rig of fixtures that are all addressed to 001.
• There is no feedback at the console for the number of discovered devices, no display of the progress of discovery.  The devices just silently appear on the patch screen if they are discovered.  There is also no feedback if the downstream devices aren't enabled for RDM- it would be great if the console would let you know that the Net 3 gateway is RDM capable but the RDM function is turned off- would you like to enable it for discovery?
• This would be a great topic for the Wiki- I think more and more people will see the benefits of RDM and start to use it.

So in summary, I'm excited that RDM works as well as it does- it's certainly functional, but still a bit of "voodoo".  I'm not trying to complain, just posting my experience for other's benefit and adding my constructive ideas.  As with any new technology, things are evolving.

Please discuss...

-Todd

Okay, I finally had some dark time to test RDM in a "real-world" scenario yesterday:

• EOS console (backup), RPU (master), s/w  ver. 1.7, RDM enabled in shell on both
• 1x Net3 4-port gateway, s/w version 2.0.0.9.0.14, all output ports set as Univ 4 w/ RDM enabled, RDM discovery enabled, 1000ms refresh
• 3x Seachanger XG model A451-01-03, DOM 4/2/08, s/w version 2.10
• data path: RPU to gateway via ACN -> 100' DMX cable from port 1 on gw to 1st Seachanger -> 25' DMX to 2nd Seachanger -> 25' DMX to 3rd Seachanger -> DMX terminator.

1. Did a deep clear of both console and RPU.  Started EOS on RPU and console- used console for all input.
2. Powered up the seachangers, went  to Patch and turned on RDM discovery. Changed view to patch by address and found the Seachangers at addresses 1573, 1579 and 1585.  Patched them to channels 1 thru 3.  Patched the lamp circuits into part 2 of channels 1 thru 3.
3. Brought up the intensity on channels 1 thru 3.  Lamps come up and color shifts progressivly greener with intensity.  [color][home] has no effect, color picker shows dot at white.  Discovered that the EOS chose the fixture profile of Seachanger_6ch, not Seachanger_XG_6ch, so the green wheel was linked to intensity.
4. Repatched 1 thru 3 to correct fixture profile.  Output is now open white.  Every so often (5-20 seconds), one of the color wheels in a Seachanger will bump to full intensity, then back to open.  This happens on all three Seachangers, but not at the same time.
5. I checked ACN levels with SACN viewer- levels are not changing.  Checked DMX output at the end of DMX line- levels are not changing.
6. Turned off RDM discovery on EOS patch screen- no change.
7. Using GCE, turned off RDM discovery on all ports of gateway-  no change.
8. Disabled RDM on port 1 of gateway- color wheels stop moving and fixtures stay in open white.

So there appears to be some sort of incompatibility with RDM and the Seachangers.  I'm not sure which part of the system is causing the problem- the ETC implementation of RDM or the Seachanger implementation.  I'm going to contact Ocean Optics and see what they say about this.

A few other things I tried with RDM (ignoring the color bump issue) and some observations:

• I wanted to see how easy it was to remotely change addressing on the Seachanger addressed at 1573.  By going to [live] [about] [address] 1573, then choosing {device details}, I was easily able to change the address to 1537 (4/1).  The fixture did not need to be patched to a channel to do this.
• I then tried to overlap addressing to see what would happen.  I remotely changed the start address on another Seachanger from 1579 to 1541 (4/5), which overlaps with the address range of the first Seachanger (4/1 to 4/6).  EOS did not give any error message about overlapping ranges.  The Seachanger that was addressed at 1537 (4/1) disappeared from the patch screen and the second Seachanger appeared at address 1541.  I was still able to access the first Seachanger if I did [about] [address] 1537, so I changed its start address to 1556 (4/20) and it re-appeared on the patch screen at that address.
• Next, I wanted to test to see how it handled 2 devices with the same address.  I changed the start address for the first Seachanger from 1556 to 1541 so that it matched the second Seachanger.  Once again there was no error message from EOS about the overlapping addressing.  The patch screen only showed one device at address 1541- there was no indication that there were multiple devices with the same address.  I was able to change address on  one of the Seachangers by doing [about] [addresss] 1541 {device details}, then noting the device ID (67791), changing the address to 1537 (4/1) and checking to see that the Seachanger that appeared at address 1537 had the same device ID. The other Seachanger that stayed at address 1541, so the patch screen showed two devices, one at 1537 and one at 1541.

My comments:

• It appears that the Seachangers are not reporting accurate enough information to the console to enable it to choose the correct fixture profile.  I think the Seachanger implementation of RDM is very basic and perhaps too generic and not model specific.  With our Wybron Coloram IT's, the information that was reported was much more complete.
• You have to be in the Patch by address format to see the discovered RDM devices.
• There is no indication that fixture addresses overlap- if you have devices with overlapping address ranges, one of the devices is simply not shown on the patch screen.
• The console doesn't provide an easy way to see the unique RDM identifier for a device- to access a device you have to use its DMX address, which is not a fixed value.  This adds the potential for a lot of confusion when trying to sort out overlapping addresses, or when trying to re-address a whole rig of fixtures that are all addressed to 001.
• There is no feedback at the console for the number of discovered devices, no display of the progress of discovery.  The devices just silently appear on the patch screen if they are discovered.  There is also no feedback if the downstream devices aren't enabled for RDM- it would be great if the console would let you know that the Net 3 gateway is RDM capable but the RDM function is turned off- would you like to enable it for discovery?
• This would be a great topic for the Wiki- I think more and more people will see the benefits of RDM and start to use it.

So in summary, I'm excited that RDM works as well as it does- it's certainly functional, but still a bit of "voodoo".  I'm not trying to complain, just posting my experience for other's benefit and adding my constructive ideas.  As with any new technology, things are evolving.

Please discuss...

-Todd

tdrga said:

Okay, I finally had some dark time to test RDM in a "real-world" scenario yesterday:

...

So in summary, I'm excited that RDM works as well as it does- it's certainly functional, but still a bit of "voodoo".  I'm not trying to complain, just posting my experience for other's benefit and adding my constructive ideas.  As with any new technology, things are evolving.

Please discuss...

-Todd 

The RDM integration in EOS is a definitely a bit “voodoo”. It should get better as the feature gets more use and RDM devices become more standard. I hope the following comments explain what EOS is doing with your RDM devices.

SEACHANGER

I had access to one Seachanger for a while developing the EOS – RDM integration. With the firmware that was in it, very little data was exposed via RDM. I was getting a valid ESTA manufacturer ID (5343), and a good DMX footprint, but that was about it. (Model ID was 1, but no model name) Currently, when EOS does not recognize the model ID for an RDM device, then it makes a guess. EOS will pick the first fixture it finds with the right manufacturer and footprint in the fixture library. As you found, it gets close. We are trying to get more RDM model IDs to make better matches in fixture releases.

While RDM is enabled on a port, the gateway will periodically poll status from the discovered RDM devices. It would appear your Seachangers are having problems with this status request I did not see that with mine.

PATCHING

There are two interfaces in EOS to patch RDM devices: “about”, and “patch”. While in the “patch” interface all the standard patch rules should apply. However, these rules are not all implemented from the “about” interface. After patching an RDM device in “address” format of the “patch” display, press format to return the “channel” format. From here you can change the address of a patched RDM device like you would any other fixture. The “patch” display will continue to enforce its rules and you should see warnings about overlapping addresses and the like. Changing the address in the “about” is purely sending RDM commands. The EOS patch updates as a side effect of the RDM command interpreting.

EOS patch currently does not support multiple patches to a single address. The patch enforces rules to make sure the user can not create multiple channels that control a single address. However, using RDM (and CEM+ integration) multiple devices can be discovered at the same address. EOS currently will only show one. The recommended procedure here is to re-patch the RDM device that is displayed so that you can see the hidden one (as you have reported). Not displaying multiple discovered devices (or CEM+ dimmers) at the same address is a bug with the patch display and should be fixed in a future release.

Ray

Ray,

Thanks for the insight into the workings of EOS and RDM.  It's a useful tool now and I also agree that it will be even more useful as the technology evolves.

-Todd

An update on the EOS and RDM with Seachangers:  the issue was resolved a while ago but I forgot about this thread...

The Seachangers required a firmware update to fix some RDM timing issues that were causing the color bump issue.  Once they were updated, everything worked fine with RDM enabled.

-Todd

And a question for the ETC folks:

Any news on making the RDM implementation in the EOS line less "voodoo"?  Any info on the timeline for when the RDM user interface might be reviewed?

Thanks,

-Todd

Todd, we are rehitting our RDM implementation next year.

:-)

a

Thanks Anne!

Looking forward to it- it's fun to watch new technology develop (and hopefully become more widely adopted)-

-Todd