Jump to content
Light-O-Rama Forums
Sign in to follow this  
Leopold

Delay required for channel reset?

Recommended Posts

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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..

Share this post


Link to post
Share on other sites

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 :D .

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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


 

Share this post


Link to post
Share on other sites

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:

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...