Ethernet

[Snowblade99]

Hello,

 

Here is a link to a helpful guide published by ETC. It covers many of the basics of networking. Obviously its bias toward ETCNet2 and ETC products, it was written by us (ETC), but it covers a lot of the common topics that arise during designing your lighting network.

 

Many Thanks,

 

Iain Quin

 

Version 3:

 

http://www.etcconnect.com/docs/docs_downlo...nning_Guide.pdf

 

Noticed there are two versions! V4 covers cat 1-7!

Version 4:

http://www.etcconnect.com/docs/docs_downlo...nning_Guide.pdf

[Oovis]

So if you could link it up to a network system in a building does that mean in theory you could control your console remotley from any room in the building?

 

That's probably something you'd need to talk to your IT people about. There may well be a hit on the system's overhead if you start pumping Ethernet DMX down a shared network. I think the idea is to, generally, use a dedicated lighting network.

 

During our refit last year we had CAT5e cables run throughout the stage and auditorium. These can be used to distribute Ethernet or, using an Ethercon to XLR adapter, straight DMX.

[d_korman]

So if you could link it up to a network system in a building does that mean in theory you could control your console remotley from any room in the building?

 

That's probably something you'd need to talk to your IT people about. There may well be a hit on the system's overhead if you start pumping Ethernet DMX down a shared network. I think the idea is to, generally, use a dedicated lighting network.

 

During our refit last year we had CAT5e cables run throughout the stage and auditorium. These can be used to distribute Ethernet or, using an Ethercon to XLR adapter, straight DMX.

 

It's not just the overhead. Some Ethernet/DMX protocols, eg Artnet, use IP addressing in non-standard way which is likely to make it incompatible with building/organisation IP networks.

[AndrewR]

Its not just the addressing thats the problem, most of the DMX/Ethernet protocols use antisocial things like Broadcast packets, its things like this rather than the overhead, that will drive your IT folk nuts. (the overhead is tiny compared to what most networks can handle)

 

If you do a search there is an old thread on here about using ethernet for a distributed lighting system.

[drjad]

Of course, the interesting thing would be use existing Ethernet wireless networks. An encapsulated protocol would be surely feasible, allowing adaptable uses of the network for various technical use.

 

Security would need to be built in - to prevent hacking of your show by someone else on the same network. And wireless connectivity 'blips' might produce interesting results in real time!

[Tomo]

ETCNet 2 uses multicasting (which would be the right method) to send the DMX packets around the network, but ETC still don't recommend mixing a lighting network with a corporate network, primarily because ETC have no control over what happens on the corporate network.

This can introduce a fair bit of latency as the switches do their renegotiating - managed switches would allow it to work, but do you really want to do all that setup when you could just keep them seperate and plug in a flying lead to your management PC as required?

 

Addressing could be an issue because none of the existing DMX-over-IP systems use DHCP - every IP is static, and thus the corporate network must avoid the addresses used by the lighting network.

 

Regarding wireless links - there is a place in Greece that uses ETCNet 2 over a few Wi-Fi links.

 

It's not a recommended solution though, primarily due to the security and latency issues.

The system was designed to be sat on a private, physically secure wired network with low latency.

 

Latency becomes a big issue because these systems don't use TCP/IP either, as TCP only applies to unicasting links (1:1 comms). The 1:many comms required by lighting control needs a different method to deal with lost packets. Cisco invented one method that is used fairly often - multicast with an ID number, then re-send over unicast to the ones that missed a packet - but this is obviously fairly slow as it'll only know it missed when the next packet arrives and the ID number is wrong!

 

On dedicated, wired, closed networks, packets get missed very rarely, so even ArtNet works.

 

Wi-Fi is insecure by definition - obviously encryption can be applied by the access points, and this would improve the situation to a degree.

Also, WiFi tends to have greater latency than wired links - packets get mangled by random intereference and have to be re-sent - this doesn't matter for internet surfing, but it's nasty to have your snap-to-black happen immediately to the wired half of the rig, and then happen half a second later to the wi-fi half.

 

That's ignoring the fact that a 2.4GHz analogue TV sender can completely crush a Wi-Fi connection.

 

At the end of the day, a £10,000 wireless system can be almost as good as a £10 wire.

Stay wired if you can!

[bruce]

Of course, the interesting thing would be use existing Ethernet wireless networks.

[pedant]

Strictly speaking, most wireless networks are not "wireless ethernet" - Ethernet is defined within IEEE 802.3, and WiFi, or whatever you want to call it, often erroneously referred to as "wireless ethernet", is 802.11. But the difference is probably only relevant to a network engineer....

[/pedant]

 

 

That's ignoring the fact that a 2.4GHz analogue TV sender can completely crush a Wi-Fi connection.

 

An interesting observation.

 

I recently bought a cheap 2.4GHz spectrum analyser. It's very useful when deploying wireless networks, to see what frequencies are currently in use, not just by wifi, but by DECT, video senders etc etc. But the most interesting result was when we turned it on in the office, and saw 3 wifi frequencies in use. (The literature always says that you must keep adjacent access points separated by 4 channels, but it's only when you see it on a spectrum analyser that you realise just how wide the frequency bands used are.) Anyway, we then turned on the microwave oven in the room next door. It swamped everything with noise - it was not possible to make out any of the underlying wifi channels.

[Tomo]

Ouch - I'd not thought about the effect of microwave ovens.

That's nasty.

[maeterlinck]

L&SI have a recent article on wireless DMX. Worth a read. it's very practically based, with some real world results.

Microwaves are bad for anything in the 2.4GHz area, however, I believe it's managable after the initial surge, but don't hold me to that.

Lots of the manufactures for DMX-Ethernet products have papers about their use, might be worth a look.

Ethernet is quite a complex protocol and requires many layers and sub-protocols to actually comunicate data. IP multicast is probably the closest to DMX I can think of offhand. But this has it's own issues.

What might be of most interest is the ability to run DMX over CAT5 (and maybe 6 not sure) cable. Ignore real 120ohm DMX and simply change the plugs on the end when there is an 'ethernet' type protocol that's really suitable for theatre.

[Tomo]

The L&SI article was very, very stupid IMO - they included just one one specific DMX-over-ethernet across a Wi-Fi link in it and compared it to the proprietry DMX-over-air systems.

 

That's an editorial mistake - either try all the major DMX-over-ethernet solutions across a given Wi-Fi link, or mention that DMX-over-ethernet will often work over Wi-Fi links.

They implied that this was the only DMX-over-ethernet system that worked over Wi-Fi, and also gave results that simply cannot be used to compare the various DMX-over-ethernet systems performance over a Wi-Fi link either.

[gupster]

With the way all things are going ethernet and ip there is alot o cheap courses now from 1 day basic knowledge courses to really advanced stuff. Ive done a few of the courses for ip cctv.

[Bean]

Ethernet has its problems over straight DMX:

 

It has a tenth of the range, uses 4 of 8 pins (making it impractical to run down mic looms), To extend the cable you need either an adapter or booster, the connectors and cable is fragile, Ethernet cable is blue and do you really want blue lines flying around from mover to mover, then either hiding them or letting the audience see and have to live with it?, Ethernet cables are crimped, and anyone who's done some crimping will know that they are a b**** to crimp correctly, And what about addressing dimmers or movers, setting an IP thats twelve digits long on an up/down button setup, per fixture?

 

The benifits are: booster/splitters cost much less (since they are ethernet switches/hubs), they carry more information, is interfacable with computers and ready made cables are only as far as the local computer store.

 

But have you ever needed more than one universe on a desk with one DMX universe output? Have you needed more than four DMX universes? if not, stick with DMX XLR's or make up XLR to RJ45 (or RJ11) adapters using different pairs of wires for each universe.

 

Just out of curiousity, Who has ever needed more than 512 channels for either all the dimmers or all the movers?

[bruce]

Hi Bean, welcome to the Blue Room...

Ethernet has its problems over straight DMX:

Well, it has "differences". That's because it's different. Whether they are "problems" is down to individual interpretation.

It has a tenth of the range,

What's the max cable length for DMX? A quick "google" comes up with varying results - I had thought it was around 300m, but some sources say it's 1800 feet (about 600m).

 

Standard ethernet-over-cat5 has a limit of 100m - which is shorter than DMX, but not necessarily by a factor of 10. But that's not a limitation of Ethernet, it's a limitation of 10BASE-T and 100BASE-T ethernet-over-CAT5 - I have built ethernet networks which are tens of kilometers long.

 

But more importantly, the length limitation is less of a problem due to the different topology. Since it is star-based rather than daisy-chained, the "total cable run" is less relevant.

 

uses 4 of 8 pins (making it impractical to run down mic looms),

You're not suggesting that we should run DMX over mic cable, are you :D

Ethernet cable is blue

 

Sorry, until I read that bit, I was taking your post seriously. But now we're verging into the realms of nonsense...

[Nick512]

Ethernet has its problems over straight DMX:

It has a tenth of the range, uses 4 of 8 pins (making it impractical to run down mic looms), To extend the cable you need either an adaptor or booster, the connectors and cable is fragile, Ethernet cable is blue and do you really want blue lines flying around from mover to mover, then either hiding them or letting the audience see and have to live with it?, Ethernet cables are crimped, and anyone who's done some crimping will know that they are a b**** to crimp correctly,

 

With High Quality DMX Cable you can get 300 - 400m range. Using Mic Cable which is a bad idea anyway you will probably get around half that length. Granted Ethernet cable either Cat5, Cat5e or Cat6 has a recommended max cable length of 100m but in reality you can often double that. Using Fiber for you ethernet you can get a range well in excess of 25 miles! Standard RJ45 connectors are very venerable but there are a range of connectors manufactured for our industry such as the nuetrik ethercon, which in my experience is just as reliable as a XLR. You can get the cable in a whole range of colours not just blue and TMB even makes an Entertainment Specific Cat5e which is hard wearing and designed to take the abuse of life on the road. Again with fiber there is a whole selection originally designed for military use that is fitting in nicely to the touring/install market. I actually found that crimping the cable is much faster that soldering, and in the field fixes are easier as all you need it a set of side cutters and a crimp tool.

 

And what about addressing dimmers or movers, setting an IP thats twelve digits long on an up/down button setup, per fixture?

 

One of the Manufactures that I have talked to about implementing the protocol have hinted that addressing will not be done by an IP address, this will be done by a DHCP server, instead the light will use its inbuilt MAC address, this is unique, therefore not requiring manual addressing at all.

 

Just out of curiousity, Who has ever needed more than 512 channels for either all the dimmers or all the movers?

 

With moving lights now using 20 - 40 channels each 512 channels disappears very quickly.

 

The last show I designed and operated had 5941 Channels running over 14 Universes. All over Artnet, from an Avolites Diamond 4 distributed by the PRG ACS400 System. Worked like a dream no lag experienced anywhere even with lights that were 300m from the control point.

 

My Current show uses 4 Universes 1723 Channels, I have 26 VL3000 Spots, 18 Mac2000 Washes, 10 Pixellines, 20 Source 4's, Some scrollers and Molefays. Control is from a Avo D4 Elite, Artnet directly from the desk into an Apple Airport Exress then at dimmer there is another Airport Express which links into a 3com 100Mb Hub then into a Luminex DMX8 Box where the artnet is converted Into DMX, The system runs flawlessly and I have never experianced lag or dropout the Airport express boxes are frequently 80 - 100m apart. the Luminex box also lets me switch Artnet sources from the desk letting me use a D4 Tablet Pc verion of the desk for a backup, focusing & Tech'ing..

[bruce]

Agree with virtually everything Nick512 says, apart from one minor point:

Cat5, Cat5e or Cat6 has a recommended max cable length of 100m but in reality you can often double that.

 

No. It has a specified maximum length, not a recommended one. There's a difference. The limitation is largely driven by timing issues.

 

In practice, a longer cable might appear to work when tested, but the errors will only show up when you start to put real load on the circuit.