Jump to content
Light-O-Rama Forums

ALL CCB controllers choke


Recommended Posts

Posted

I have 3 CCB each on their own network by themselves and they are constantly choking where only certain bulbs will light to 1/2 of them will to they choke out for 10 seconds with no lights. Is it too much for them with crazy short .05 second changes or is there something wrong with them? If I do basic color changes in 1 second intervals, they are ok, but any fast sequencing, they choke! Any ideas?

Posted

I am reading along as well with other posts and I was wondering...is there anything wrong with using a ccb on a single unit id rather than the 2 unit id's?

Posted

Hi Chagoi,

I have 4 sets of CCB's each on a single unit id. I do have it setup so that on string 1, channel 1 is at the far end. That keeps all my channel 1's are to the left. They have been running since last weekend without any problems. Make sure you have the network with the CCB's set to fast speed, when I first set them up it was set to normal and they were choking on some of my sequences.

Posted (edited)

Frank, can you send me a section of your fastest sequence so I can see if mine chokes on it? I have all set to fast speed and all my channel 1's are on the left side as well. shawn@burtonkoi.com

Edited by Chagoi
Posted

Chagio,

Check your email, sequence sample sent.

Frank

Posted

Have you tried switching your cat5 cable? If all three CCBs are doing the same thing I would think if it is a cable issue it would be the cable from the computer to the 1st controller. I have 3 - 100 bulb CCPs on one network, and some of the chases I run have lights turning on at .01 seconds with no issues.

Good luck

Posted

I have found that the network speed setting in Network Configuration has a huge effect on performance.

My cable runs are under 100 feet I use the fastest setting.

I am running 10 CCB's and 11 CCP's and 15 CCR's

The most congested network has 7 CCP's so far timing has not been an issue even at .05.

It does seem to hold true 6-7 max on a network if you are using fast timing,

I did have an issue on the Network that only had 4 CCP's and one controller stopped responding. Turned out to be a bad controller.

It was affecting the whole network line really strange results in the show.

I put in my only spare and all is well. (Super great LOR service opened a ticket and they took care of me!!!)

I tested all the Network preference setting and if you want to see what I mean. Set your network to SLOW and you will really see the lag it will stop blank out skip etc.

11 of my CCR's are in windows on 2 wireless ELL's. (5 on 1 net 6 on the other) setting is average (due to ELL being limited at 57k) they really have no problem with .03

Running some tests this weekend down to .01 to see if I need to split up the busiest net.

Michael

Posted

Here is how the CCB/CCP controller works, this may shed some light on any strange effects caused by quick changes in your sequences.

Comm has been optimized in the newer controllers such that it consumes very little of the microprocessor bandwidth. In addition to the 19.2Kbps, 57.6, 115.2 speeds currently supported, we will be releasing a 500Kbps speed soon, the software release is done and we are making sure it's OK, so hopefully no more than a week. The new speed is conservative in terms of what the controllers can handle.

Commands arriving on the comm line are processed immediately, but don't affect the variables that actually get transferred to the bulb ICs. Every 8.3ms, the controller updates all the variables, meaning all macro & color effects are processed which even if you are not using any macros/color effects results in the new brightness data being moved to the bulb display variables. Because of the time it takes to transfer data for a 50 pixel string (and allowing for future capabilities) a bulb string is updated every other 8.3ms interval. So the strings are updated every 16.7ms or 60 times/second.

So, .05 timing means the strings are being updated 3 times as fast as you are manipulating them. This should be OK. It's more likely that comm can't keep up with some portions of your sequence and quadrupling the comm speed to 500K will fix things. If the PC cannot get the comm data out because you are exceeding the current comm speed for too long an interval, the PC will interpret commands so that it can drop some to catch up but still keep the channel states correct. Some intermediate transitions won't occur.

Brian has run a Superstar CCP tree with (I think) 14 50-bulb strings on one 500Kbps network with excellent results driving individual pixels (no macros.)

Posted

This is excellent news!!!

Posted

Wow John Thanks for the update. I hope this helps my lag problems. Cant wait to try it.

Now I am up to 7 LOR networks as I have 10 CCB (doubles) controllers and 8 CCR controllers. The big matrix has 6 controllers on 3 networks and it looks very choppy when I try to move anything across it fast. Not only did I add adapters but I also had to slow down the movements. No macros or resolutions less than 50 were planned for this year, but I have been adding them the last few nights to replace effects which looked great in the visualizer and not so good on the matrix. The good part I want to report is the 3 networks all perform about the same so there is no visual on which part of the matrix is controlled by a particular network. The objects move between networks very well when they are not too fast.

Posted

John, that all makes perfect sense from what I am seeing on this end and I am very excited to see if it makes a difference. I gotta say, I thought I was losing my mind. I can take my beefed up laptop, hook a single com cable to it with a 6ft cat cable out of the box to a single ccb with SE set to fast network and run a sequence with no macros and simply really fast timings and it chokes. This occurs on each of my ccb's. Here is an example of a choked section.

choke.gif

I really am convinced there is nothing more I can do to tune things up for this to work. Frank, I will try your file shortly, gotta run to the store.

Posted (edited)

Are you seeing the choking or lag while running through the SE or from an actual show using the control panel? I only say this because if use are using the SE as a form of testing the lights (i do) then lag will occur due to all the background stuff running. Under the Play option, uncheck all except "Control Lights". This will help with lag. If playing from the control panel, then different issue.

Edited by CLD Kevin
Posted

it happens while running the show through the control panel. SE and the visualizer do not lag or choke. I cannot control my lights from my PC, I move all my files to the show PC once completed with the sequences and only run the show on that.

Posted

That is a stress test! Every pixel is the same for the entire string. When you do that (solid color string) .. you can send 1/50th of the commands by just setting LR to 1 and only set the color on the 1st pixel. That is not a macro command. Its telling the controller to just use the first pixel. I see all of your pixels are back wards. How did you get them that way?

Doing a reply sequence for you. Going to a party, will send tomorrow.

Posted

"you can send 1/50th of the commands by just setting LR to 1 and only set the color on the 1st pixel."

please describe...I am doing the rgb much like the regular lights, maybe that is a problem?

Posted

"you can send 1/50th of the commands by just setting LR to 1 and only set the color on the 1st pixel."

please describe...I am doing the rgb much like the regular lights, maybe that is a problem?

Make a copy of you sequence.

Expand each CCB string and delete all RGB pixel events except for the first RGB pixel.

Use the intensity tool to put 1% intensity in the LR channels for the entire sequence.

What this does is tell the controller that the entire string is to be manipulated by the first RGB pixel. This will drastically reduce the number of simultaneous commands.

Posted

John, will the release of 3.8.2 include the new optimized comm?

  • The topic was locked
Guest
This topic is now closed to further replies.
×
×
  • Create New...