At what point are multiple networks/usb adapters necessary?

[bhays]

I have been using 17 controllers the past two years and for 2010, it is looking like 28. Will I be ok running all of these on one RS485 adapter, or should I split it into two networks?

Thanks.

[-klb-]

The answer is that to an extent, it may depend on your style of sequencing, and lighting layout. We have three networks for the city park/firehouse show. I think we have 24 (out of 44) controllers on one network that just covers the park. I don't currently see any need to try and equalize the number of controllers per network, as everything runs just fine, and the network layout is currently mostly based on geographic considerations.

[Guest wbottomley]

I'm running 32 on one network. So far, I've had no problems and everything is in sync.

Next year, it will probably be 38 controllers and four CCR's.

[Charles Belcher]

Brett,

I only used one network at home for 2026 channels, but did split the signal out of a single USB485B for a cabling routing convenience reason. No lag time for me.

You probably know this but each network can have it's own communication speed setting in "Network Preferences" as well if you decide to use more than one network.

Charles

[eldoradoboy]

I would think that the CCR's esp if sequenced without macros would stomp on the network...

I also think it has to do with a person;s sequencing style.. I could have 3000 channels but if I dont have busy sequences im not setting a lot of stuff over the line... if you sequence your timings to high resolution .05 or shorter and do a lot of busy things.. spins, chases, multiple mega trees with lots of channels, arches, etc id think a second network is in order....

im going to put CCR's on a separate network for my 010 display just because I know I will be hammering them in the sequences...
-Christopher

[stanward]

So what is the maximum number of controllers that can be installed on one network?

What is the smallest time scale that we can sequence our lights to?

How do you create multiple networks (if needed)?


What is the TOTAL maximum length of network cable can we use to connect ALL of the LOR controllers?

[Max-Paul]

Stanward,

Ok, last question first. By the books RS-485 can have a cable 4000 feet long. But if you install a repeater at the end of the 4000 feet cable, you can go another 4000 feet before another repeater is requred. And so on and so on.

As for all of your other questions. I think that the fellows before me have tried to answer this very difficult question. There are some varibles that makes a correct answer impossible. So, What timing grid are you using? Will it always be set to that speed? What is your programming style? Do you like to have every element in use at the same time? Or 75%, or 50%, or 25% of your elements at the same time? It does not matter if it is fading, shimmer, twinkle or on solid. That is all controlled by the controller. But it is the messages to the controller that makes the difference. Do you plan to add on more controllers?

See what they are saying is that depending on some of the above questions. And how you answer them, will determine when it would be a good idea to move some of your stuff onto a 2nd or 3rd network. And I feel that some can only tell you what happened to them before they had to split things up. But I doult that your setup will be like any of their setups. So, set up early and do alot of testing. If you do it early enough, and discover some problems. You will still have time to get the stuff in place to set up a second network. Or if you rather be proactive. Start getting the material and programming in place now. Split up your network so that one side of the yard is circuit 1 and the other side is circuit 2 and be done with it. But it is your choice how you want to address this..

[Randy]

This year we ran 32 "Regular" 16 channel controllers and 2 CCRs on the same network with no hint of a loading problem on the network. The timings are all over the map (with 0.05 being common), but on our Chipmunks song at the end to capture the voices in the "arguing" back and forth section, I have the timing set at .01 increments for 20 seconds and it worked just fine.

However, the one thing that didn't work as well this year was the addition of two Firefli strings. I did have to put them on their own network, and even then you can't throw too many events at them in rapid succession. I saw stuck pixels, etc. on the Fireflis and had to go in and alter the programming on those until they were able to handle it (no quick ons and offs, etc.)

Bottom line, LOR stuff - no problem. All of our LOR controllers except the CCRs are in the garage, so the total length of our network is probably less than 100 feet or so.

[Ponddude]

I am running 2 networks this year. The regular network has all my LOR stuff, including all the controllers plus my DMX things from the iDMX. The second network is with all my Firefli units. D-light doesn't seem to care that these lights do not work on a network that has other things on it. For example, they were on the network with all the LOR controllers and all I got was sticking pixels and lights that would stay on. It looked horrible. This is a known issue over at d-Light and nothing has been done to fix it. I had no choice but to move the lights onto their own network to get them to work properly.

[stanward]

Thanks for all of the responses.

I couldn't find any documentation from LOR stating the multiple networks thing. So I was curious.

I am no where near what the channel count that many of you run. I have 96, but will hopefully double that channel count for 2010.

Majority of my timing is 0.10, but I do have some faster songs at 0.05, and was wondering if cutting it down past 0.05 will screw things up. Apparently not!

[-klb-]

Some more book answers. The LOR and the network should be able to address 240 controllers on one network. But there may be limits on that, especially if you have long runs. But the repeaters would be able to take care of that.

But I do expect that you will hit the limits of what you expect to be timely response before the 240 controllers. Also, the timing grid itself probably does not directly impact how much network traffic you have. It may impact your sequencing style, which will impact the traffic. What really counts is how many state changes you are sending out the network, and how many you are sending with intent for them to look like they are happening at the same time.

As for setting up multiple networks, you start by plugging in more USB adapters, and noting what com ports they come up as. Then go into edit/preferences/network preferences. Check the box to list networks in channel configuration. Set the com port numbers for regular network, aux A, and any others you intend to use. Now in your channel config, you will have one more box that lets you specify which network each controller and channel belong to. You could in theory have controller 1 on each network, but I do keep unit ID's individual, in case I ever need to collapse two networks together for some reason.

[Denny]

I used two networks, one for the LOR controllers and another for the Firefly. No problems this year. I think something equally important this hasn't been addressed is the computer running the show. The minimum requirements listed on the LOR site are fine for a few controllers, but the more controllers added, the more powerful the computer needs to be. Last year, I tried using an "antique" that met the minimum requirements, but the show had many problems. This year, I used a computer that is about 8 years old and it struggled at times.

[stanward]

Denny, thanks for your comments. Very important point. I only can afford used dinosaur computers, with the exception of this netbook my wife gave me for Christmas 2 years ago.

Did anyone else experience the problem of an older PC slowing down their show? I know on my PC, the CPU usage of the LOR software (during the show) is very low. However, the LOR software is sensitive to the CPU usage from other programs, as LOR slows down to a crawl!





Denny wrote:

I used two networks, one for the LOR controllers and another for the Firefly. No problems this year. I think something equally important this hasn't been addressed is the computer running the show. The minimum requirements listed on the LOR site are fine for a few controllers, but the more controllers added, the more powerful the computer needs to be. Last year, I tried using an "antique" that met the minimum requirements, but the show had many problems. This year, I used a computer that is about 8 years old and it struggled at times.

[Denny]

stanward wrote:

Denny, thanks for your comments. Very important point. I only can afford used dinosaur computers, with the exception of this netbook my wife gave me for Christmas 2 years ago.

Did anyone else experience the problem of an older PC slowing down their show? I know on my PC, the CPU usage of the LOR software (during the show) is very low. However, the LOR software is sensitive to the CPU usage from other programs, as LOR slows down to a crawl!





Denny wrote:

I used two networks, one for the LOR controllers and another for the Firefly. No problems this year. I think something equally important this hasn't been addressed is the computer running the show. The minimum requirements listed on the LOR site are fine for a few controllers, but the more controllers added, the more powerful the computer needs to be. Last year, I tried using an "antique" that met the minimum requirements, but the show had many problems. This year, I used a computer that is about 8 years old and it struggled at times.

For me, it wasn't so much slowing down the show as skipping commands, seemingly sending wrong commands, etc.

[Rafter Bar R]

Question about multiple networks, I have a D-Light USB adapter, can I use this to drive my FireFly or do I have to use another LOR USB adapter?

[Denny]

lonewolvie wrote:

Question about multiple networks, I have a D-Light USB adapter, can I use this to drive my FireFly or do I have to use another LOR USB adapter?

I used the D-Light adapter to run my firefly this year. No problems, worked great.

[dmoore]

Ever wondered why you get "stickies" or channels that don't fire when you'd expect? How many controllers CAN you put on an LOR network?

The answer depends pretty much completely on which command you are running, the timing of commands and what overall network speed you are running.

The overall speed of the network is the "cap" that defines the highest level of bandwidth that can be used at ANY time. Unlike DMX which is sending ALL 512 channels about 44 times per second and makes no effort to optimize the commands (i.e. - if it's off, don't turn it off again), the LOR protocol is very focused on optimization of commands. So, some commands are very efficient. For example - you want to turn on all 32 of your channels on two 16 channels controllers - just two "commands" ((controller address + function + parameter) x 2) - DMX would send that same "ON" (actually just 255 indicating full intensity) 44 times every second. Most LOR commands such as ON, OFF, FADE are simple. Complex commands in LOR are twinkling for example. It's important to note that once a command is issued to an LOR controller, it's never sent and update to ensure the command was received and processed, LOR assumes the controller received the command - DMX just assumes you didn't get the command and sends it again and again.

So - where do the stickies come from? Since the LOR protcol, unlike DMX which sends the command over and over, only sends the command once and assumes the controller received it, you can get a case where the command to say... turn off a channel... is missed - this is your sticky channel. Why would a controller miss a command? Because the network bandwith was exhausted when a large number of other commands were being sent either becuase of tight timing or complex commands such as twinkles or ramping twinkles/fades come down, they all have to fit into that limited amount of bandwidth.

What is the solution? A fix seems the solution could be fairly easy from an S2 standpoint - the amount of bandwidth is a know quanity (19.2/56.6/115.2) and the commands being sent is a know quanity - so S2 could have an "meter" or some other method to determine when these peaks occur within your sequence and exhaust your bandwidth. The solution? Add more networks to split your traffic between them.

I wrote a "simplified" persentation of how the DMX and LOR protocols work internally and that can be found here:

http://www.holidaycoro.com/2010LSHWorkshop/DMX%20and%20LOR%20Protocols.pdf

By understanding how the LOR protcol works, it makes it completely clear as to these "weird" things that happen.

[Tim Fischer]

dmoore wrote:

What is the solution? A fix seems the solution could be fairly easy from an S2 standpoint - the amount of bandwidth is a know quanity (19.2/56.6/115.2) and the commands being sent is a know quanity - so S2 could have an "meter" or some other method to determine when these peaks occur within your sequence and exhaust your bandwidth. The solution? Add more networks to split your traffic between them.

Another possibility would be to have S2 buffer commands during these peaks. In theory, you might miss some commands, but you'd never have a "sticky" situation because the channel would be returned to the current state once the network caught up. This, of course, assumes that most of the time the network has plenty of bandwidth, but there might be a few peaks/bottlenecks in the sequence.

[dmoore]

Tim Fischer wrote:

Another possibility would be to have S2 buffer commands during these peaks. In theory, you might miss some commands, but you'd never have a "sticky" situation because the channel would be returned to the current state once the network caught up. This, of course, assumes that most of the time the network has plenty of bandwidth, but there might be a few peaks/bottlenecks in the sequence.

This is a possibility, the downfall being that depending on when the bandwidth comes open, you would end up with commands firing at incorrect timings since the music would continue to play on without being buffered.

[Tim Fischer]

dmoore wrote:

Tim Fischer wrote:

Another possibility would be to have S2 buffer commands during these peaks. In theory, you might miss some commands, but you'd never have a "sticky" situation because the channel would be returned to the current state once the network caught up. This, of course, assumes that most of the time the network has plenty of bandwidth, but there might be a few peaks/bottlenecks in the sequence.

This is a possibility, the downfall being that depending on when the bandwidth comes open, you would end up with commands firing at incorrect timings since the music would continue to play on without being buffered.

True. I was thinking more of just returning the channels to the proper state, not actually having them "catch up" with all the missed events. Seems better than a stuck channel!

Last year I was at 176 channels so this isn't really an issue for me at this point