Jump to content
Light-O-Rama Forums

Issue with LEDS not responding consistantly with LOR160xW Controller


JohnnySOX

Recommended Posts

I have 4-LOR160xW Controllers in my design.  I am having an issue with one of the controllers that will either leave lights off when the show file is telling it to turn on or leave channels on when they are supposed to be off.  The controller is controlling White LED strands.

I have 4 songs in my show and all channels will fire at some point during the 4 songs, but this controller does not consistently behave with what the show file is telling it to do.

Again this only happens on one of the controllers (the second one in the Ethernet chain of the four).  I am using Light-O-Rama software 5.0.16.

Thanks

 

 

Link to comment
Share on other sites

run the verifier first and foremost. and check your unit ID in HU to be sure it's number as you think it is.

(doesn't matter what order in the daisy chain - matters what it's numbered as)

Link to comment
Share on other sites

I would next think cat5 cable or connector  issue, but since it’s in the middle of your chain, that almost completely rules that out. 

So next I would be double checking se. If you did a lot of channel moving from last year &/or copy & pasting, could have commands in unwanted places. Some fades are hard to see in se, but your lights will boogey to it. Change view to view fades as ramps to do a visible check. Also, run the off button across all areas that are supposed to be off. 

Link to comment
Share on other sites

Just to add to what Mega said, hover your mouse over apparently empty cells until the tooltip shows up, with the RGB intensities.

Link to comment
Share on other sites

Interesting tool I found to look at the XML  files as a set of spreadsheets in your fav office program, which allows sorting as needed:

TotalXML converter (trial)  Parsed the  LAS file into the component section (CSV) files.

Made it easy to spot odd things


    Directory: C:\Users\xxxx\Documents\LORDec17


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----        09-Dec-17     09:09             53 channelConfig.csv
-a----        09-Dec-17     09:09             18 channels.csv
-a----        16-Dec-17     10:45           3064 channels_channel.csv   <<< had unassigned network on a RGB channel
-a----        09-Dec-17     09:09            109 channels_channels.csv
-a----        09-Dec-17     09:09           1211 channels_rgbChannel_channels_channel.csv
-a----        09-Dec-17     09:09            555 rgbChannel.csv
-a----        09-Dec-17     09:09            107 track.csv
-a----        09-Dec-17     09:09             16 tracks.csv
-a----        09-Dec-17     09:09             35 tracks_channels.csv
-a----        09-Dec-17     09:09           1235 tracks_track_channels_channel.csv

 

Link to comment
Share on other sites

Also Mega mentioned the Cat5 and thinking to rule it out, I would suggest swapping out the Cat5 cable. I've had bad ones in the chain that didn't affect other controllers down the line. I even have a cat5 cable tester that showed it good  but had interference issues internally when the show  was running. I wouldn't rule it out completely. It's worth a try just because funny things happen with our hobby.

  • Like 1
Link to comment
Share on other sites

I'M with Santa's Helper on this one.

Dumb as this sounds... I'm quite a stickler and buff of RS-485 (what LOR uses on a cat5 cable)  AND.... it (RS-485) does have a couple of quirks...

1) having a cable that has TIA 465A (or B ) where as all the other cables are the "other" version will cause a capacitive ghost on that segment of cable this can be overcome by using the correct 100 ohm termination resistors at each end of the network, and NOT trying to run a "Y" cable to a controller that is "islanded" out on its own.  (point to point (in and through) to each controller so the total is one long cable, even if you have to run one to a box, and then back from that box, and onto the next controller (NO y cables).

the terminators have to be at the ends of the cable NOT at the end of the controllers... (example) my network is one huge long 900 foot cable 700 of that is getting from my house out to where the controllers are at the front of my property, the next 100 or so feet are controller to controller, with the last 75 or so feet ending up with a chunk I can plug into the dongle on my laptop when I'm sitting in my car, out on the road in front of my property testing the show (I cannot see my show from my house because there is a huge hill between, hence the 700 some odd feet of underground cable to get to the controllers).

I have one terminator at the G3 mp3 Director in the house, and the other is on the end of the cable that is sitting coiled, so I can run it to the car if I need to change programing or do hardware diagnostics. NOTICE the 100 ohm resistor.. the covering is simply hot glue....... 

PC150005_zps3e92a203.jpg

 

and before the hot glue....

PC150004_zps337ddfcd.jpg

 

The cable that is coiled is just laying on the ground, when the G3 is idle and waiting for the show to start in the evening, I can simply plug the other end into the laptop, and check things, since the terminators are at the ends, the entire cable is "balanced" and doesn't care where the signal comes from......

Link to comment
Share on other sites

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