Delay required for channel reset?

[Leopold]

It appears that when sequencing the channels on a CTB16PC controller that after turning a channel off it requires between a half and a full second to recover before it can be turned back on.

I can be sure it is the controller channel, not the lighting, because I can reduce the load to just the small LED in the plug, and the beats are skipped there just as they are in the main lighting. That is, I can be sure if the low wattage lighting being used it not itself part of the problem, I suppose.

When running the chase test with only two channels, the on/offs begin getting erratic when the speed is higher than 6. If I include 8 channels in sequence, then it can run at 1, as it seems the channels get enough time to reset after being blinked before the next turn comes around.

Has this been a problem for anyone else? It sure make synchronizing heads to singing music difficult.

[Don]

Leopold wrote:

When running the chase test with only two channels, the on/offs begin getting erratic when the speed is higher than 6. If I include 8 channels in sequence, then it can run at 1, as it seems the channels get enough time to reset after being blinked before the next turn comes around.

Can you clarify this? What, exactly, do you mean by "when the speed is higher than 6" ? I also don't quite follow how including 8 channels in the sequence let's it run at "1".

What speed is higher than 6? When including 8 channels, what "it" runs at 1?

[Leopold]

On the Hardware utility, the first displayed page is apparently the "Test" page. After initializing the controllers without problems, I checked channels 1-9 of the #1 controller, powering a face display. I clicked on "On" next to the speed slider, and the chase started. It looked fine, even with the speed slider all the way to the left (displaying "1", the fastest speed). I then turned off active checkboxes one by one, which has the effect of causing the channels which are still in the chase to turn on faster (less time since they were last turned off). When I got to three channels left, they started turning on and off erratically; apparently they began ignoring turn on commands, I'd think because they haven't had time to reset since they were last turned off (that's my theory, anyway). If I slowed the slider, I could find a point where the lights again appeared to operate correctly that was "6" when I had two channels in the chase.

We bought five CTB16PC controllers; at least three of then display this behavior, so I think it is a design problem (though I can't imagine how I'm the only person to report this, AFAICT), or perhaps something that I haven't properly initialized or setup (certainly possible). We're powering very low wattage string light.

[TJ Hvasta]

So do I understand you uncheck the channel boxes with the chase test still active? I've only unchecked the boxes and rerun the chase after stopping any test. Stop the test, uncheck the box for the channel, then, start the chase test..

The Sequencer turns on/off/on much faster than the Hardware utility. 1/10 sec and slower I've never seen any "not ready" to turn back on problems..

[Leopold]

Okay, I'll try that out tomorrow morning and report back. My thanks.

Agree about the sequencer. I'm running a 100 msec grid, and I did a quick animation and that worked perfectly. The question in my mind is whether the controller can keep up with the sequencer, and I'm wondering why I'm having this trouble with it when apparently no one else is. I must add that I picked up LOR software for the first time three days ago, and ran the controller for the first time this afternoon, so I'm not hardly yet comfortable that I know exactly what I'm doing. Maybe by next week .

[-klb-]

I've never seen any indications of a need for a channel reset time from the controller. But, I've never pushed things in the hardware utility.. In the sequence editor, I've pushed things fairly hard.

[Ken Benedict]

Would a full loop in the Cat5 cable cause this?
It should be a single line from the PC -> USB -> Controller without a return loop.
Just a shoot-from-the-hip suggestion, thinking about noise on the Cat5 line.

[Leopold]

Let me be clear - I first noticed the effect while looking at a show I had produced on the sequencer. In particular, one light was off more often than the sequence indicated it should be. I invoked the chase test in order to try to track the problem down; I don't just see the problem there, though. It just seemed the easiest way to explain and reproduce the problem.

In the sequence I have one place where I turn a light which has been on, off then back on three times in the shortest interval the grid allows: 1/10th second. In the visualization, it works as designed. In the real lights, it turns off once and then turns on again somewhere downstream; that's it.

I'll check the CAT5 wiring today, to make sure it is correct. I'm familiar with daisy-chained high-speed wiring, so I don't think that's a problem. As a thought, LOR doesn't provide a termination resistor array for the daisy-chain, does it?

[-klb-]

I've run a LOR network through about 25 controllers and probably well over 500 foot long, with no termination, and no issues. While it is RS485, and should require one, they indicate they have had more issues with termination, than without. Some people do say though that they have had issues being helped by adding termination.

What kind of lights do you have plugged in? How many other things are going on at that same time?

[Denny]

I had similar issues a couple years ago, but was running quite a few commands including dmx, fire-fly, etc. I was also using a very old computer. I solved the problem by going from one network to two and using my laptop.

[-klb-]

Leopold wrote:

Let me be clear - I first noticed the effect while looking at a show I had produced on the sequencer. In particular, one light was off more often than the sequence indicated it should be. I invoked the chase test in order to try to track the problem down; I don't just see the problem there, though. It just seemed the easiest way to explain and reproduce the problem.

In the sequence I have one place where I turn a light which has been on, off then back on three times in the shortest interval the grid allows: 1/10th second. In the visualization, it works as designed. In the real lights, it turns off once and then turns on again somewhere downstream; that's it.

I'll check the CAT5 wiring today, to make sure it is correct. I'm familiar with daisy-chained high-speed wiring, so I don't think that's a problem. As a thought, LOR doesn't provide a termination resistor array for the daisy-chain, does it?

If you are using tracks, have you run the LOR verifier against a schedule and show that include this sequence? This actually sounds more like a channel duplication issue than a hardware issue.

[TJ Hvasta]

My thots too.. channel duped.. Leo, try using the Verifier to look for duplicate events..

[Leopold]

I've found out what it was. What we are driving from the controller box is a small wall-brick power supply, which supplies 9 volts to the light, which is a "glow wire" (http://www.glowire.com/), a coaxial electroluminescent wire that glows after the 9 volts is boosted by a small box up to 120 volts at 4000Hz. The delay is caused by the power supplies; they were never designed to be driven on and off quickly, and it takes them about a half second to recover from a shut-off.

Each has a small red LED on the bottom, which was reacting just like the wire, It took be a bit to realize the LED was on the PS output, not the input like most power lights are. That was why I was blaming the controller.

What we need to do is something more subtle, like getting a larger 9 volt power supply and turning on/off its output to the lights. Is there a LOR-type controller which supplies contact open/closures rather than 115v on/off, or one that supplies some small DC voltage rather than AC power line?

[JBullard]

Leopold wrote:

I've found out what it was. What we are driving from the controller box is a small wall-brick power supply, which supplies 9 volts to the light, which is a "glow wire" (http://www.glowire.com/), a coaxial electroluminescent wire that glows after the 9 volts is boosted by a small box up to 120 volts at 4000Hz. The delay is caused by the power supplies; they were never designed to be driven on and off quickly, and it takes them about a half second to recover from a shut-off.

Each has a small red LED on the bottom, which was reacting just like the wire, It took be a bit to realize the LED was on the PS output, not the input like most power lights are. That was why I was blaming the controller.

What we need to do is something more subtle, like getting a larger 9 volt power supply and turning on/off its output to the lights. Is there a LOR-type controller which supplies contact open/closures rather than 115v on/off, or one that supplies some small DC voltage rather than AC power line?

The LOR DC card is designed for that:

The Servo Dog has contact closers


EDIT: forgot to give you a link for these controllers:

http://www.lightorama.com/DigitalIO.html


 

[Leopold]

Thank you, sir. Looks like that's just what I need.

Thanks for the help, Mssrs Hvasta, kilb, Denny, Benedict and Don. It has been a learning experience.

:] :cool: