Automated Fixtures Meteor ElipScans hate ETCnet...

Tweedle

Member
Hello all!

Hooray for my first post!

Background:

So I wanted to share a recent issue I found while trying to integrate Meteor ElipScan Mirrors into the ETCnet at my theatre. We use ETCnet2 and Emphasis as a control server, though not as the board's brain. We use Emphasis to program cue lights, worklights, etc. and thusly allow "AMX" (a control surface) to control them through the net.

Instance:

3 ElipScans hung on ETC Source Four fixtures. These are 3-pin DMX input mirrors. I turned them around to 5-pin DMX with an adaptor. These converted 3-pin-to-5-pin runs then went into a ETCnet2 Node--that node connected via ethernet to the ETCnet.

Issue:

CLICKING! Random clicking was heard, loudly. We didn't know what it was. The board was not sending values to the mirrors, they had only been turned on via non-dim circuits. Even when a value, say "FL," was assigned through the board to a channel, say "Pan," we would hear the clicking. Odd. And annoying as all get-out.

Solution:

Our Supervisor of Sound had an idea... "Since they're 3-pin units, can we run them through a sound tieline to the booth--bypassing the net?" I immediately knew at that moment what the issue was: the ElipScans were invented to run off straight line voltage issued through only DMX--NOT ETCnet. Well, it worked. Peace and quiet. Ahhhh.

Conclusion:

Although data was successfully transfered through the net, converted to 3-pin configuration, and understood as commands by the mirrors, there was also background data being transmitted. The mirrors did not move or shake as a result of the "clicking." I attributed this to the fact that they are being bombarded with background signal (ie, binary). Since a network is always sending signal, they couldn't understand what was being whispered underneath the standard voltage currents.

All was well for the show, and although the ElipScans were loud (as always), they were not annoyingly loud. Anyone else experience this "data background" when dealing with DMX-required intelligents?

Best,
Tweedle.
 
Did you try to contact ETC or Meteor tech support?
 
I immediately knew at that moment what the issue was: the ElipScans were invented to run off straight line voltage issued through only DMX--NOT ETCnet. Well, it worked. Peace and quiet. Ahhhh.
This is not true, and frankly makes no sense.

Solution:

Our Supervisor of Sound had an idea... "Since they're 3-pin units, can we run them through a sound tieline to the booth--bypassing the net?" I immediately knew at that moment what the issue was: the ElipScans were invented to run off straight line voltage issued through only DMX--NOT ETCnet. Well, it worked. Peace and quiet. Ahhhh.

Conclusion:

Although data was successfully transfered through the net, converted to 3-pin configuration, and understood as commands by the mirrors, there was also background data being transmitted. The mirrors did not move or shake as a result of the "clicking." I attributed this to the fact that they are being bombarded with background signal (ie, binary). Since a network is always sending signal, they couldn't understand what was being whispered underneath the standard voltage currents.

All was well for the show, and although the ElipScans were loud (as always), they were not annoyingly loud. Anyone else experience this "data background" when dealing with DMX-required intelligents?

Best,
Tweedle.

DMX is DMX is DMX. It doesn't matter if it comes out of a node or if it comes straight out of the back of the board. DMX is a standard protocol. ETC DMX network nodes are designed to take the ETCNet Data and output it as DMX (Strand nodes do ShowNet, and other manufacturers have their own), so the data that comes out of the node on the DMX line is exactly the same as the data that comes out of the DMX port on the console (unless you have configured your nodes to output different universes). Now, it is possible that the nodes are outputting bad signal, but you would need a DMX analyzer to figure that out. I would be interested to know if any other DMX devices are having issues when connected to the same node.

I suppose that it could also be possible that you have corrupt data being fed out over your network. Also, could be a bum node or bad 3-5 or 5-3 adapters.

As an ElipScan owner, I will tell you that what you probably need is to make sure that your data lines are terminated. ElipScans are one of the most finiky units I have ever worked with. They need some serious TLC to make them work with you. They are also the most noisy units.
 
Last edited:
This is not true, and frankly makes no sense.



DMX is DMX is DMX. It doesn't matter if it comes out of a node or if it comes straight out of the back of the board. DMX is a standard protocol. DMX network nodes are designed to take the ETCNet Data and output it as DMX, so the data that comes out of the node on the DMX line is exactly the same as the data that comes out of the DMX port on the console (unless you have configured your nodes to output different universes). Now, it is possible that the nodes are outputting bad signal, but you would need a DMX analyzer to figure that out. I would be interested to know if any other DMX devices are having issues when connected to the same node.

I suppose that it could also be possible that you have corrupt data being fed out over your network. Also, could be a bum node or bad 3-5 or 5-3 adapters.

As an ElipScan owner, I will tell you that what you probably need is to make sure that your data lines are terminated. ElipScans are one of the most finiky units I have ever worked with. They need some serious TLC to make them work with you. They are also the most noisy units.

Agreed. I have been running elipscans off of SN110 nodes for years, right now I have 15 different things running off a net2node on an emphasis system. Your problem was that you did not have the node properly configured. Elipscans randomly move until they receive DMX.
 
Well, we had never had any problem with any other DMX based fixtures, SeaChangers, Scrollers, etc. The problem was solved when we bypassed the ETCnet.

Apologies for the "voltage" confusion. I only meant "signal." Oops. I have tested all the turn-arounds (3 to 5 pin). They are fine. My hindsight tells me there was no proper termination. Which, after reading all the thread replies, was probably the issue.

Again, I apologize for any confusion. Thank you all for your input! :p

Best,
Tweedle
 
According to Barbizon, DMX has improved a lot over the years and the signals are faster. Older DMX devices are sometimes not compatible with a newer DMX system because it is sending data at faster rates than the older devices can handle. This became apparent at the end of our install when Barbizon was still here finishing up in our other spaces as we set up for the State of the University address in our main theatre.

We own a flapper module for our projecter. It is called The Flapper (original version) from Engineering Solutions There are two modes on it. Manual mode utilizes a 3 pin connecter with a hand switch that you have to run offstage to someone to control. The other option is through DMX. As hard as we tried, we could not get our EOS to control the module. With our switch missing, we had no way of blacking out the projector. Barbizon had their tester handy though and it was able to control the unit through DMX so they let us borrow it for the event. We have now tracked down the manual switch and will resort to using that until I contact ETC about seeing if we can get it to work.
 
According to Barbizon, DMX has improved a lot over the years and the signals are faster. ...
1986: originally published as USITT DMX-512
1990: revised as USITT DMX512-1990
2004: ANSI E1.11 - 2004, Entertainment Technology - USITT DMX512-A - Asynchronous Serial Digital Data Transmission Standard for Controlling Lighting Equipment and Accessories.

The baud rate for DMX has always been 250k (refresh rate of 44 times per second).
 
I do not know about EOS, but i know on the express/expression line, you could lower the dmx rate. Some consoles change the rate of data that they are outputing when you change a value (ie Hog II) the Hog 1000 however keeps the same rate. You can watch the flash of the fixtures recieve LED change based on each console. The guys ran into a problem, which i have not checked out in the shop yet (partially due to the Hog 1000 is swimming in water and we have no power), on a leprecon analog rack with a demulitplexer. When they were using the Hog II all of the lights dimmed fine (except all of the racks were not trimmed properly), but when connected to the hog 1000 everything would flash and freak out.
 
PROBLEM SOLVED!

After poking around the NCE for the network, I found the "DMX Outputs" option for the Nodes. I slowed the Port Speed. They were set to "Maximum" = 42Hz refresh rate.. I changed them to "Fast" = 39Hz refresh rate.

Thanks for all your input!
 

Users who are viewing this thread

Back