Should I trust my installed wire?

Just a note for further reference, the same is true of ACN and Shownet. Some day all DMX devices will come with an RJ45 plug and the ability to directly understand ACN (the replacement for DMX). Then we will be able to simply use cheap off the shelf network cables and switches for the entire network. That will be a great day... But it seems to be a long way off.

If that day comes, many people will be sad to realize IP based control signals are subject to standard CatX rules, like 300' maximum cable length, that don't apply to DMX.
 
So while TCP has error checking that UDP doesn't, there is still error checking in the layer 2 MAC layer which will knock out a huge number of the errors that causes funkiness with DMX...
Besides, no one would want a retransmitted DMX packet half a second later, so TCP would be the wrong tool for the job at any rate.

And it is important to remember that intrinsicallly UDP doesn't preclude error checking and lost packet handling, it just means it ineeds to be sorted out higher in the protocol stack - an example of how this works is with TFTP...
That said, the packet structure of Art-net doesn't to my knowledge include any such capacity, but I'm not convinced that's really a problem...

As a postscript, I'm not convinced ethernet to the fixture is a place that we want to be for the small generic stuff - LED pars and what not, and you introduce a more complicated point of failure on the truss than daisy chaining DMX. For the high channel count stuff, movers etc, then you're probably paying enough for the fixture that paying for a decent switch is going to be a part of the whole project...
 
The thing to remember is that once the protocol has been converted to TCP/IP for transmission over Ethernet, that becomes the only protocol that matters. The packets have no idea as to what type of information they are carrying, only that they have a value that should equal their check-sum when counted on the next hop. It could be video, audio, someone surfing the web, someone downloading a file, or even art-net data. Once the destination converter sees the IP header and grabs the packet and converts it back to DMX, all bets are off as no more error checking is done. For the period of time that the signal is riding inside the Ethernet protocol, it is pretty safe.

As for Ethernet to the fixture, not fond of that idea. Just one more thing (IP address) that would have to be programed into each fixture, and there is a lot of cheap Cat5 cables and equipment that would be bound to show up! The core concept of Cat5 was based on the idea of fixed points, such as a desktop, hub rack, and other things that don't move. Yes, there are better components on the market. More durable connectors that are still based on RJ45. Flexible stranded Cat cable. Still, there is that sea of junk stuff! As for economics, a system based on Cat5 would be far less expensive to build due to the amount of competition between manufacturers. DMX is what it is. A very basic data transmission system from the 1980s that works darn well on a small scale. As long as a show fits in one or two universes, it is still the best. For large shows, DMX becomes a nightmare! That's where I think IP protocol begins to shine.
 
It's more likely that the fixtures would use DHCP to get an address then use sACN (E1.33 RDMNet) to register and negotiate their capabilities with the controller in much the same way as RDM.

Yes, The other piece of this is we have to have RDM come along as well making everything off the shelf and plug and play. Simple and easy.
 
The thought of being reliant on a DHCP server is enough to make me lose sleep, just saying...
 
The thought of being reliant on a DHCP server is enough to make me lose sleep, just saying...

Not sure why. Many sound and video systems are already networked this way. If you're living on your own island, DHCP is smooth as butter. Biggest issue is if you're connected to an enterprise network and need the IT guy to give you a giant subnet for all your devices. More than likely even in an enterprise environment you'd still be on your island. IT guy's not going to want to do anything with lighting, and the lighting guy's not going to want anything to do with the building network (except access to those precious enterprise WAP's so you can hit the lighting network from anywhere in the theater via your iPad or laptop).

As for getting away from that pricey DMX cable, tactical CAT5E cable with etherCon's goes for a similar price. I'd be cautious about getting excited that DMX cable will be soon be laid to rest. It may come to be, but the alternatives aren't going to be much more inexpensive for cables that'll survive being coiled back up every night for a few years' straight.

On the other hand, there's something to be said for finally putting an end to that 5-pin/3-pin divide.
 
Maybe I've spent too many years surrounded by a need for redundancy in system design, but there's no pretty way to introduce a redundant DHCP server to a network.
I can build redundancy into links between switches, devices and switches where they allow, and cover most other single points of failure, but DHCP is that much harder...
 
IT guy's not going to want to do anything with lighting, and the lighting guy's not going to want anything to do with the building network

I'm not sure of many setups where you'd want your lighting network to be integrated with your building's switch anyway, unless you've got to have remote access to turn lights on and off or something non-standard. When I told my IT gal I was going to be installing a router to our lighting computer she almost bit my head off. When I explained that this computer would not be patched into the main network she was much happier.

I just want her precious, unused copper.

On the other hand, there's something to be said for finally putting an end to that 5-pin/3-pin divide.

I wouldn't put it past some of my techies to try and patch a SM58 with an RJ45. :think:
 
Maybe I've spent too many years surrounded by a need for redundancy in system design, but there's no pretty way to introduce a redundant DHCP server to a network.
I can build redundancy into links between switches, devices and switches where they allow, and cover most other single points of failure, but DHCP is that much harder...
Well remember, DHCP only does it's thing as the equipment is booted (turned on.) In this case, there is no file server involved, so the task could be done by a simple router as long as the sub-masks are the same. Unless you do a manual reset or power it down, once everyone has their IP's then the DHCP does nothing more and could effectively be removed! I demonstrated this recently for someone at work. All the workstations on our private net go into a large hub, which then loops to a router, another public hub, then into our main router. With everything booted up, I pulled the line running from the first router to the hub. With the exception of the internet, everything kept talking just fine! Now, if you powered anything down, it would not be able to get a new IP, but that's about it. n other words, don't worry too much about the DHCP server croaking during a show. Won't make much difference until you need to power cycle or reset.
 
Noting that we have SIGNIFICANTLY digressed from the original subject;

JD's points are not neccessarily the whole picture.
DHCP is a lease, assigned for a particular amount of time, typically between a few hours and several days.
Without getting into all the details, when that lease starts to fall due for renewal there is the potential for much pain to come about if the DHCP server is offline.

Proper configuration can mitigate many of the risks, but I seriously ask the question of how often this will happen in the gigging sector...
 
Well remember, DHCP only does it's thing as the equipment is booted (turned on.) In this case, there is no file server involved, so the task could be done by a simple router as long as the sub-masks are the same. Unless you do a manual reset or power it down, once everyone has their IP's then the DHCP does nothing more and could effectively be removed! I demonstrated this recently for someone at work. All the workstations on our private net go into a large hub, which then loops to a router, another public hub, then into our main router. With everything booted up, I pulled the line running from the first router to the hub. With the exception of the internet, everything kept talking just fine! Now, if you powered anything down, it would not be able to get a new IP, but that's about it. n other words, don't worry too much about the DHCP server croaking during a show. Won't make much difference until you need to power cycle or reset.
Are you still using Hubs? Likely you mean switch.
 
Noting that we have SIGNIFICANTLY digressed from the original subject;

JD's points are not neccessarily the whole picture.
DHCP is a lease, assigned for a particular amount of time, typically between a few hours and several days.
Without getting into all the details, when that lease starts to fall due for renewal there is the potential for much pain to come about if the DHCP server is offline.

Proper configuration can mitigate many of the risks, but I seriously ask the question of how often this will happen in the gigging sector...
I would just use a Class A subnet (10.0.0.0, 255.0.0.0) and simply create a really big DHCP pool with a rediculously long lease time if such things are a concern.
 
Are you still using Hubs? Likely you mean switch.
Switch means one too many things on this forum ;)
But yes, "switch" is the more current term. Most people think of a router in terms of what you would have for a home network, but that's actually (usually) a combo box containing a cable modem, router, switch, DHCP server, and wireless. The DHCP server is the only part we are interested in, therefore only one cable is needed to inject it's presence. That can be anywhere on the network. If you are worried about your DHCP access going down, then you could put it right in the booth next to the board! It dosen't care where it is as long as there is not another router blocking it, or a second DHCP server on the loop.
 
So since we are talking about stuff that's still a few years away...

How nicely does sACN play with IPv6?
 
IPv6 shouldn't make a lick of difference to sACN, other than getting all vendors to support it. However, it's hard to imagine a private lighting network needing v6. There are almost 17 million addresses in the 10.x.x.x space. Use a class B or C router and you can NAT thousands of those. That's a lot of devices.
 

Users who are viewing this thread

Back