Control/Dimming Moving Light vs. Ion communication issues

plotdependent

New Member
We have an ETC Ion lightboard and several Robe Robin DL4S moving lights that have been forgetting attributes recorded into cues and attribute wheels not matching up with their live function (ex: the Tilt attribute wheel will instead move Shutter C in and out). The industry technician we have been working with believed it to be the fact our board had gone through several board updates so they did a full wipe of the board and we started from scratch.
Unfortunately, the lights are still not remembering attribute settings we record into cues (it will have everything but the correct gobo pulled up or it will be a box but in a different pan/tilt location). Our venue does ~50 shows a year and the movers are an integral part of that.

I'm reaching out to this community because we are stumped and are hoping SOMEONE has experienced this before/has recommendations. We still believe it's probably a board issue and not a mover issue. If it helps we are patching the movers at profile M1, have Net3s in the grid, and connect the ION to fire almost all sound and projection cues formerly through MIDI and now through OSC using QLab just in case any of that could be a clue. Happy to answer any clarification questions, but would honestly just be happy with someone saying we're not alone in this.
 
The fastest way to resolve this would be to call tech support (it's free and they love to help!). They'll be able to help you narrow down the issue for sure.

For technical support in the Americas,
please call 608-831-4116
or toll-free in the U.S. at 800-688-4116
[email protected]

For technical support in Europe, The Middle East & Africa
please call (+44) (0) 208 753 0984
[email protected]

For technical support in Germany, Austria, Switzerland, Eastern Europe & Russia
please call (+49) 8024 4700-0
[email protected]

For technical support in Asia,
please call (+852) 2799 1220
[email protected]
 
Besides calling tech support an easy first step would to be bring a mover down and come right out of the back of the board.

Then start introducing everything else.
Board ML
Then
Qlab Board no Net3 ML
Then
Qlab Board Net3 ML

And see if you have the same results.

If I had to guess I would say Qlab over OSC is scrambling the encoders.
 
Can you send a show file? ETC Tech support will also ask for this, but my shot in the dark is that it's a programming error somewhere in tracking/updating/referenced data. If you have proper control of a unit under manual control and then lose that control once data is referenced then I would guess that the referenced data is being augmented in an unintentional way.

Of course things can happen and weird things do happen... but it is not normal behavior on any desk that I have worked with for it to "forget" recorded cue values, or for attribute matching to randomly change on encoders. It is possible that the encoders have multiple pages and I'm not particularly familiar with that fixture profile, but it's unfortunately fairly easy to get lost in encoder pages on an ION which can lead to reaching for the same encoder and coming up with a different result....

OSC shouldn't scramble the encoders, but if you've got a wonky bug in your osc language you may be getting unintended referenced data changes....
 
It shouldn't but they said they took the board back to basics. Until we get a report back with ground test it's all a mystery.
 
Can you send a show file? ETC Tech support will also ask for this, but my shot in the dark is that it's a programming error somewhere in tracking/updating/referenced data. If you have proper control of a unit under manual control and then lose that control once data is referenced then I would guess that the referenced data is being augmented in an unintentional way.

Of course things can happen and weird things do happen... but it is not normal behavior on any desk that I have worked with for it to "forget" recorded cue values, or for attribute matching to randomly change on encoders. It is possible that the encoders have multiple pages and I'm not particularly familiar with that fixture profile, but it's unfortunately fairly easy to get lost in encoder pages on an ION which can lead to reaching for the same encoder and coming up with a different result....

OSC shouldn't scramble the encoders, but if you've got a wonky bug in your osc language you may be getting unintended referenced data changes....


We write every show as a Cue Only show unless a designer comes in and asks for it otherwise, but we do let our movers Auto Mark. I also at one point thought that maybe the wheels were just being mis-selected since they change positions sometimes after a board update (something that used to be the 1st wheel was moved to the 3rd wheel sort of stuff) or that I, in my haste to program, was simply not hitting update.

The complication became more than just a "I must be doing something wrong" issue when I told an intern they had selected the wrong wheel when a shutter was moving when they should have been using Pan. They then made eye contact with me while moving the wheel that read "Pan" and I watched as that wheel effected a shutter instead- asking with their eyes what they should be doing differently. We took a pause and the wheel then started to effect Pan as it should have.

This brings me to the other issue: it's intermittent. To test it's forgetfulness at one point I created a cue stack that just sequenced through every option I could for the mover (red rose, into green box, into spinning prism pebble breakup, into amber sharp circle, ect.) and it never forgot a single attribute.

Here is the board file for the camp show we did when the movers (Chan 161-164) were used often and the attributes in Qs were sometimes remembered and sometimes not (Qs 1051-1067 as a prime example). Don't judge me for not cleaning up the soft blocks; it was a long week.
 

Attachments

  • Camp 2017 2017-08-22 15-59-45.esf
    403.9 KB · Views: 244
Try unpatching the fixture and repatching it. Also, try duplicating the fixture in the fixtures tab of the patch and using the duplicate of instead of the main patch. If all else fails, build a new patch from scratch using the manual.

https://www.robe.cz/index.php?type=10898&tx_odproducts_f[action]=downloadFile&tx_odproducts_f[file]=robe/downloads/user_manuals/User_manual_Robin_DL4S_Profile.pdf

I have had the same issues in EOS 2.5 with my Clay Paky HPEs. Unpatching and repatching is the only way I've gotten it to work. Used to happen once every 4 months. None so far in 2.6

It also wouldnt hurt to do a factory reset on the Robes just in case the board sent a firmware update to them.
 
Here is the board file for the camp show we did when the movers (Chan 161-164) were used often and the attributes in Qs were sometimes remembered and sometimes not (Qs 1051-1067 as a prime example). Don't judge me for not cleaning up the soft blocks; it was a long week.

You're judgement free on the partial blocks this time ;)

I'm not sure why re-patching the fixture would solve the issue, but at least you have a similar issue with a potential solution so definitely give ChrisB's suggestion a try. Another thing I would check is your startup and shutdown procedure for your data line and the fixtures. Particularly if you're using gateways and Nodes... it is possible that you're running into what's commonly referred to as a network collision which could potentially cause some of the issues you describe at the data transmission level. Highly likely... but possible. I always try to power on my control surface, then gateways/nodes, then fixtures. The opposite for shutdown. That may be a root trigger for your issue causing a data hiccup.

Still worth a call to HQ... but maybe keep this one to business hours... Dionysus knows I've bothered them enough during dinner before....
 
Last edited by a moderator:
Never heard of any capability in the EOS series that allows the console to send manufacturers firmware to a device on the DMX line.

Through the base DMX protocol, this is highly unlikely. However there are some lights that can accept firmware updates via RDM, Robe is one that falls into this category. You are also assuming the OP is using DMX protocol, however, they didn't say that, just that they are using Net3 Nodes. Robe is one of the most innovative lighting companies out there, and they allow virtually all protocols direct into the fixture. The Robe Robin DL4S can accept DMX-512, RDM, ArtNet, MA Net, MA Net2 and sACN direct to the fixture.

https://www.robe.cz/robe-universal-interface/ Here is a Robe device that can push firmware updates via RDM

That being said, I do not know if it's possible to intentionally push a firmware update to a fixture through EOS (or if EOS only allows updates via the GCE to gateways themselves) only that sending firmware updates through RDM, ArtNet and sACN 3 is possible. :)
I may be mistaken but with ETC's Net3 Concert I believe remote firmware updates for fixtures are possible.

There have also been known issues with RDM causing interference with DMX in some systems, and has been mentioned on ETCs forums a few years back. Making sure this is off both on the fixture and the board might help, especially if you don't use RDM.

I was merely offering other options. Simply put, if the two were speaking the same language before and now they aren't, something had to change... Hope this helps.
 
Let's see if we can narrow down the issues.
If you download sACNview, you will be able to see what the sACN levels are being sent out on the network and WHAT DEVICE is sending them.
I would also run ETC Concert to make sure that you aren't having a network conflict. You said that you have Net3 in the grid. I assume this means ETCNet3 DMX/RDM Gateways. How are they configured? Static IPs or dynamic? If they are dynamic, what device is handling DHCP? There can only be one device on the network serving DHCP.
The Robes have the shutters and the pan very far apart. Is it possible that someone messed with the fixture library? I don't know EOS that well to know if you can live edit the library.
After checking the other things, if the problem still persisted, I would start with a new show file and patch the first fixture and see if the problem persists.
Good luck,
John
 
There are many, many factors that could be at play here. As others have mentioned, unless you need it, I would suggest turning off RDM either globally or by output port on your gateways. I would also suggest double checking the addresses that each fixture is set to and making sure that they are actually patched correctly. Also double check the fixture modes and make sure that they are still in the mode you expect them to be.

The other terribly important thing to consider is if you are using presets and/or pallets in your programming. If you are, then you need to pay attention to your update screen when you update cues. Update is a super powerful tool that can update your cues and references in one shot, which can be a real mess if you don't intend to do that.

Also, coming from a background in theatre, I am passionately against working in cue-only, especially with moving lights. It creates so much more cleanup and ultimately makes life miserable as a programmer. Typically I find that in theatre settings, people don't use tracking because they don't understand it, but if you are doing theatre, you should learn to embrace the tracking. Also, if you are working in cue-only, partial blocks are not really a thing. I mean, since Eos is designed to be a tracking desk by default, it will show you when a channel is commanded at the same level in every cue, but that is somewhat of a formality in cue-only.
 

Users who are viewing this thread

Back