At what point are multiple networks/usb adapters necessary?

[LightORamaDan]

By design, running out of bandwidth should not cause "extended" improper states of channels (or stickies). That is not to say that there isn't a problem but the code is written to prevent/minimize this.

When a portion of a sequence generates more data than can be delivered within a "reasonable" time, the PC software starts simulating the controllers and tracks what their current state should be. It then sends commands to place the controller into the correct state as soon as bandwidth allows.

It would be a nice enhancement to let people know when there is a bandwidth issue so they know it is time to add another network.

[Tim Fischer]

LightORamaDan wrote:

When a portion of a sequence generates more data than can be delivered within a "reasonable" time, the PC software starts simulating the controllers and tracks what their current state should be. It then sends commands to place the controller into the correct state as soon as bandwidth allows.

Very cool, that's exactly what I was suggesting. And you guys have already done it!

[Randy]

I appreciate this discussion, as it's always nice to learn more about things like this.

With all the LOR controllers we have in our display (about 500 channels), I never had any performance issues until I added two Firefli units last year. Even after splitting those two Firefli units off to their own network, there were still some instances of sticky pixels on the Fireflis. The other LOR controller channels were fine, never any issues with them.

Is this a known issue with LOR and Fireflis? Any workarounds available? I really had to simplify the programming on the Fireflis so they wouldn't "swamp" out and leave pixels stuck on, but there were still some that stuck on occasionally. I'd sure love to fix that if anyone has any suggestions....

Thanks, Randy

[LightORamaDan]

Randy wrote:

I appreciate this discussion, as it's always nice to learn more about things like this.

With all the LOR controllers we have in our display (about 500 channels), I never had any performance issues until I added two Firefli units last year. Even after splitting those two Firefli units off to their own network, there were still some instances of sticky pixels on the Fireflis. The other LOR controller channels were fine, never any issues with them.

Is this a known issue with LOR and Fireflis? Any workarounds available? I really had to simplify the programming on the Fireflis so they wouldn't "swamp" out and leave pixels stuck on, but there were still some that stuck on occasionally. I'd sure love to fix that if anyone has any suggestions....

Thanks, Randy

I have heard of this issue and do not think it is an LOR problem. (could be wrong)... Make sure you have the latest firmware for the Fireflies (FFs).


With the CCR we had an issue where in extreme conditions the CCR would overrun and miss a command. In this case it was 12 CCRs on one network ( this is the same as having 37 FFs on one network). We fixed the issue in the CCR firmware so that they did not miss any commands. If nothing else this indicates to us that it is highly suspect that the LOR network could not keep up with two FFs.

[LightORamaDan]

LightORamaDan wrote:

Randy wrote:

I appreciate this discussion, as it's always nice to learn more about things like this.

With all the LOR controllers we have in our display (about 500 channels), I never had any performance issues until I added two Firefli units last year. Even after splitting those two Firefli units off to their own network, there were still some instances of sticky pixels on the Fireflis. The other LOR controller channels were fine, never any issues with them.

Is this a known issue with LOR and Fireflis? Any workarounds available? I really had to simplify the programming on the Fireflis so they wouldn't "swamp" out and leave pixels stuck on, but there were still some that stuck on occasionally. I'd sure love to fix that if anyone has any suggestions....

Thanks, Randy

I have heard of this issue and do not think it is an LOR problem. (could be wrong)... Make sure you have the latest firmware for the Fireflies (FFs).


With the CCR we had an issue where in extreme conditions the CCR would overrun and miss a command. In this case it was 12 CCRs on one network ( this is the same as having 37 FFs on one network). We fixed the issue in the CCR firmware so that they did not miss any commands. If nothing else this indicates to us that it is highly suspect that the LOR network could not keep up with two FFs.

It should be mentioned that there are other reasons that commands can be missed. A problem with the cables, adapters, connections, etc can cause noise in a network and cause commands to be missed. If that is the case any controller on that network would have a problem.

[Steven]

LightORamaDan wrote:

It should be mentioned that there are other reasons that commands can be missed. A problem with the cables, adapters, connections, etc can cause noise in a network and cause commands to be missed. If that is the case any controller on that network would have a problem.

Our display has 11 controllers and some places where the CAT5 runs through a conduit with power and light (channel) cables. This may have been the cause of a problem we had last year where there were not only stuck channels, but channels that turned on at times when other channels were turned on.

The solution was to install a terminator at each end of the RS485 network, as the RS485 standard specifies.

I showed how to build a terminator in this post.

[huskernut]

Ok so I have followed this and some similar discussions so I have my stupid question #1 what does it mean to split off to a 2nd network? Does it mean a second USB port and 485 adaptor? How do you configure this or is it just detected an away you go?

Thanks

Rick

[Tim Fischer]

huskernut wrote:

Ok so I have followed this and some similar discussions so I have my stupid question #1 what does it mean to split off to a 2nd network? Does it mean a second USB port and 485 adaptor? How do you configure this or is it just detected an away you go?

Correct- it means multiple 485 adapters, and multiple "chains" coming from your show computer.

It's configured in the Network Preferences. If I recall correctly, there's an option that you have to select to have it show the "advanced" settings, otherwise it defaults to only showing one available LOR network.

I'm doing this all from memory so I could be very wrong

[dmoore]

Steven wrote:

LightORamaDan wrote:

It should be mentioned that there are other reasons that commands can be missed. A problem with the cables, adapters, connections, etc can cause noise in a network and cause commands to be missed. If that is the case any controller on that network would have a problem.

Our display has 11 controllers and some places where the CAT5 runs through a conduit with power and light (channel) cables. This may have been the cause of a problem we had last year where there were not only stuck channels, but channels that turned on at times when other channels were turned on.

The solution was to install a terminator at each end of the RS485 network, as the RS485 standard specifies.

I showed how to build a terminator in this post.

You know... I've always wondered why they were not terminated as "recommened" in the 485 spec, in the way that DMX (which is also 485) is - do you think it was done to make it less complex for the user? Dan - any comments on this?

[-klb-]

Partly, different chips have different degrees of tolerance for the issues caused by lack of termination. Also, short networks are less likely to have issues.. So between good chips, and the typical under 200 foot long network of the typical LOR user, things are pretty reliable without them.. When users start pushing the envelope of length and signal interference, then terminators can make a significant difference.

But that is just my opinion on the topic...

[LightORamaDan]

-klb- wrote:

Partly, different chips have different degrees of tolerance for the issues caused by lack of termination. Also, short networks are less likely to have issues.. So between good chips, and the typical under 200 foot long network of the typical LOR user, things are pretty reliable without them.. When users start pushing the envelope of length and signal interference, then terminators can make a significant difference.

But that is just my opinion on the topic...

We designed things with the inexperienced user in mind and so that we could use inexpensive cables (such as phone cables, etc... ). I am not going to get too technical but when we talked to professional lighting engineers they told us about all the issues they had with DMX. Many of those problems were eliminated by doing two things. Creating a protocol that could run efficiently at lower speeds and second using 485 drivers that took the "sharp edges" off the signal. Those sharp edges are required for high speed BUT they also cause problems such as reflections that require terminators.

In general a LOR network does not require a terminator. When people do use them (with LOR), it seems that they make things worse as often as they make things better.

Before I ever sold a controller I tested the LOR network run at 2000ft using 100ft flat phone cables (from a $1 store a great bargain!) and connected them using cheap connectors from the same store. It ran well at all speeds. With CAT5 cable which most people use we have seen very few issues even with very long runs and lots of controllers.

Dan

[dmoore]

LightORamaDan wrote:

We designed things with the inexperienced user in mind and so that we could use inexpensive cables (such as phone cables, etc... ). I am not going to get too technical but when we talked to professional lighting engineers they told us about all the issues they had with DMX. Many of those problems were eliminated by doing two things. Creating a protocol that could run efficiently at lower speeds and second using 485 drivers that took the "sharp edges" off the signal. Those sharp edges are required for high speed BUT they also cause problems such as reflections that require terminators.

In general a LOR network does not require a terminator. When people do use them (with LOR), it seems that they make things worse as often as they make things better.

Before I ever sold a controller I tested the LOR network run at 2000ft using 100ft flat phone cables (from a $1 store a great bargain!) and connected them using cheap connectors from the same store. It ran well at all speeds. With CAT5 cable which most people use we have seen very few issues even with very long runs and lots of controllers.

Dan

The back story is always more interesting. Thanks for sharing.

[GregShoop]

I plan to add Fireflies this year and this discussion was VERY educational and written so even a dummy like me could understand most of it.

I have a question that has not been addressed, how do the wireless Easy Light Linkers effect the network and bandwidth?

[LightORamaDan]

gshoop wrote:

I plan to add Fireflies this year and this discussion was VERY educational and written so even a dummy like me could understand most of it.

I have a question that has not been addressed, how do the wireless Easy Light Linkers effect the network and bandwidth?

The LOR network will operate at thee speeds: approx( 19, 56 and 115 thousand bits per second).... The ELLs only operate at 19 and 56.

Dan

[dmoore]

LightORamaDan wrote:

gshoop wrote:

I plan to add Fireflies this year and this discussion was VERY educational and written so even a dummy like me could understand most of it.

I have a question that has not been addressed, how do the wireless Easy Light Linkers effect the network and bandwidth?

The LOR network will operate at thee speeds: approx( 19, 56 and 115 thousand bits per second).... The ELLs only operate at 19 and 56.

Dan

Just curious - do these work at the "485" layer? So, will they work with your controllers in DMX mode?

[dmoore]

Dan -

Here is a bit off the wall question - what were the factors in selecting the pins 4/5 for data? Did this go back to some of the controllers back on Computer Christmas?

[-klb-]

dmoore wrote:

LightORamaDan wrote:

gshoop wrote:

I plan to add Fireflies this year and this discussion was VERY educational and written so even a dummy like me could understand most of it. 

I have a question that has not been addressed, how do the wireless Easy Light Linkers effect the network and bandwidth? 

The LOR network will operate at thee speeds: approx( 19, 56 and 115 thousand bits per second).... The ELLs only operate at 19 and 56.

Dan

 

Just curious - do these work at the "485" layer?  So, will they work with your controllers in DMX mode?

If the question is about Ell's and DMX, no.. DMX is 256Kbps.. It takes more bandwidth to send intensity for all channels, every frame, as opposed to a protocol like LOR that uses an intelligent controller. So the 56Kbps max ELL won't work for 256Kbps DMX.

[dmoore]

-klb- wrote:

dmoore wrote:

LightORamaDan wrote:

gshoop wrote:

I plan to add Fireflies this year and this discussion was VERY educational and written so even a dummy like me could understand most of it.

I have a question that has not been addressed, how do the wireless Easy Light Linkers effect the network and bandwidth?

The LOR network will operate at thee speeds: approx( 19, 56 and 115 thousand bits per second).... The ELLs only operate at 19 and 56.

Dan

Just curious - do these work at the "485" layer? So, will they work with your controllers in DMX mode?

If the question is about Ell's and DMX, no.. DMX is 256Kbps.. It takes more bandwidth to send intensity for all channels, every frame, as opposed to a protocol like LOR that uses an intelligent controller. So the 56Kbps max ELL won't work for 256Kbps DMX.

Duh... what was I thinking. Makes sense. So only LOR protocol for ELLs.

[LightORamaDan]

dmoore wrote:

Dan -

Here is a bit off the wall question - what were the factors in selecting the pins 4/5 for data? Did this go back to some of the controllers back on Computer Christmas?

Two factors were involved with the original design. 1 we wanted to be able to use phone wires so that limited us to pins 3,4,5,6 ... In a flat phone cable (or any cable for that matter) you want differential data to be sent on two wires that are next to one another so that limits it to 3-4 or 4-5 or 5-6... Of those combinations only 4-5 are a twisted pair in CAT5 so we end up with 4-5.

Dan