Jump to content
Light-O-Rama Forums

Smibo

Members
  • Content count

    9
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Smibo

  • Rank
    New Forum User

Profile Information

  • Gender
    Not Telling
  • Location
    SW Florida
  • Occupation
    IT Consultant

More About Me

  • How I learned about Light-O-Rama -
    YouTube Videos of LOR displays
  • Favorite Decorating Holiday?
    Halloween

LOR Software

  • LOR Software Version
    4.3.24
  • License Level
    Pro
  1. Hi all. Hope everyone had a great holiday season! So, here's what I have found out about this issue: - It was definitely NOT a cable integrity issue; the problem persisted no matter how solid the network cabling was. - The problem disappeared entirely when I deleted the stand-alone sequence from the CF50, put in on an SD card and ran it from a (uMP3G3) mini show director. - I had a similar issue for the Christmas show with a CMB24D controller running eight 10-watt RGB floods too. Each of the floods were set to fade up in either red or green over one second, stay on for several seconds, then fade down over one second. At any given time, only four or five of the floods would be on, while the "off" ones were to "strobe" kind of randomly, in either red, green or white, by turning their respective channels on for one centisecond at 100% intensity. I had uploaded the animation sequence to the CMB24D as a stand-alone, and found that the fades and ons were okay, but the strobe events were just ignored entirely. Again, the solution was to remove the stand-alone sequence from the controller, and run the las from a mini director. To me, this seems to indicate that there's an inherent logical limitation in both the CF50's controller board and the CMB24D; simple sequences are okay, but once your animation goes beyond some threshold of complexity, the on-board processors and/or memory are just unable to keep up. The solution (for me) was to simply offload that work to a show director, and everything worked fine. I'm going to need a couple more mini show directors for next year though. Just wanted to follow up in case someone else has a similar issue. Thanks again to everyone who contributed!
  2. Many thanks to everyone who contributed to this thread. As of this post, the problem with the networked unit persists, but I'm going to let it ride until after Halloween. During the November Halloween-to-Christmas transition, I plan to test the theory that they'll work okay with a show director, then put these two units on the bench for further diagnosis. I'll remove the back covers and connect them directly to each other with a known-good Cat5e cable, and see how they perform like that. If that works, I'll custom make replacement cables for both units, using waterproof, direct-burial rated Cat5e cable, pinned out and crimped to the 568B standard (same as most pre-made cables), and take Mega Arch's advice to seal the crimped ends with silicone. No matter what, I'll be sure to report back here with what I find out, in case someone else has a similar problem in the future, and reads this thread in search of a solution. Thanks again, everyone!
  3. Thanks, Mega Arch. I suspected the cable or connection at first too, but the fact that both units work perfectly when the same sequence is run from a laptop / RS485 adapter, kind of disproves that theory, no? The 2nd unit is STILL getting its commands across the exact same cable connection, and it works flawlessly. I'd be willing to bet that if I ran both units from an SD card in a show director at 500k network speed, they'd work fine too. I may try that next, just to see. Anyhoo, today I went back and removed the standalone sequence from unit 02, power cycled the whole set, and guess what? Now It works. Or at least about 80% better than before; every once in a while the green diodes fail to light up when the unit is supposed to go to orange, making it shine red instead instead of orange, but for the most part it's all good. After I did that, I inspected the connection between the two, and found everything clean, shiny and dry inside the waterproof connector. I capped those off anyway, and connected the other two cables from each unit (again, it's a direct connection, without a 3rd cat5 cable between them), and got the exact same behavior. I'll tinker with them some more after the holidays, but at this point I'm thinking I'll have to get a new pair for next year, and use these two as individual standalones elsewhere, just for ambiance.
  4. There are only 2 units on this network, 01 and 02. Either one works ok as standalone, but the networked one doesn't. I have tried: - 01 as standalone, 02 networked. 01 works ok, 02 does not. - 02 as standalone, 01 networked. 02 works ok, 01 does not. - BOTH units as standalone and connected to each other. Both units work ok, but out of sync with each other. This is how I left it for now, because having the correct color is more important in this application than having perfect sync.
  5. CF50D issue / malfunction

    I've removed and replaced the cover on a CF50D without compromising the waterproof integrity of the seal. If you are very careful, and follow the instructions to the letter, there's no reason it should be a problem. Having said that though, your issue sounds to me more like something for the tech wizards at LOR to address; I had a similar issue with an undetectable CCR controller that turned all its channels on, and had to send it back to the mother ship for repair. They reset the firmware internally somehow, and all was right in the world after that.
  6. So, here's my boggle: As the title suggests, I have two CF50Ds (unit IDs #1 and #2) operating in standalone mode, not connected to any other LOR controllers or any show director or anything. For Halloween, the animation sequence I'm using does alternating color fades from orange to purple (as unit #1 fades from orange to purple, unit #2 fades from purple to orange, then vice versa), over a span of one second, stays that color for a second, then fades back to the other color, over a total sequence length of one minute. There are only two devices in the sequence. If I download the las into either unit as a standalone sequence, that unit works exactly as expected. However, if I then connect the other unit, the unit with the sequence in it still works fine, but the other, "slave" unit does not fade correctly (e.g. when fading from purple to orange, the red leds fade up first, then the greens just suddenly turn on at their specified intensity a several milliseconds later). I tried changing the sequence to simply switching each unit from one color to the other (purple is 52% red, 52% blue, orange is 100% red, 13% green) without the color fade, and that's even worse; the unit with the sequence in it still works perfectly, but the slave unit seems to change to whatever color it happens to feel like that second, sometimes even the color I asked for! Note that either unit works perfectly if it's the one with the sequence in it, and it's the other unit has the problem. The connection between the two is direct, meaning there is no other ethernet cable between the two waterproof connectors, just one unit's plug connected to the other unit's jack, inside the jack unit's waterproof connector. I tried downloading the same sequence into BOTH units, and they both work fine, but out of sync with each other. If I remove the standalone sequence from both units and run the same sequence on my laptop through an RS485 adapter, both units work perfectly. I'm about to start tearing my hair out. What am I missing?
  7. Okay, turns out that just changing the network speed to 500k was all it took! Works like a Swiss watch now. Thanks for your advice Brian, and sorry for posting this in the wrong sub-forum. It probably belonged in "Hardware" discussions. I'll pay more attention in the future. Thanks again!
  8. Thanks, Brian. The G3-Mp3 is running just one (regular) network, and I had left it at the default network speed of 57k. I'll try changing it to 500k,and test that first. If still no joy, I'll try putting the CCR on an aux network, and see if that makes a difference. I thought I was using the latest S4 (4.2.10), but now I see that 4.2.12 is available, so I'll get that. The G3-Mp3 is fairly new (this year's summer sale) but I'll make sure it has the latest firmware too. I'll try to get all that done this afternoon, and report back. Thanks again!
  9. Sorry if this post is redundant; I thought I read a similar post here before, but can't find it anymore. Anyway, here's the scenario: - 2 LOR1602 controllers, and an LOR1602 G3-Mp3, running regular LED light strings, everything works fine. Mp3 file is constant bit rate (CBR). - Added a CCR arch (one CCR, full length), morphs chasing from top (center) of arch, running down both sides. So far, so good. - 2 shows on the SD card; show2 (one animation sequence) "runs when powered on", show1 (one musical sequence) interrupts show2 when triggered, plays one time only, then show2 resumes. When I play the musical sequence from my laptop/RS482 adatper, everything is fine. When I write the shows to the SD card and try to play it through the G3-Mp3, the CCR is okay, but the regular lights are firing about 11 seconds behind the music! I've gone into SE and removed the CCR device, saved that sequence and wrote it to the SD card, and everything is good again (except no CCR, obvs). As soon as I add the CCR again, the timing of the regular lights gets WAY out of whack. Both SE and SS are using 0.05 centisecond timings. CCR device in SE is copy/pasted from exported "*_sup.las" file (no audio file in SS). I tried making a new SS sequence using the same CBR Mp3, exporting that to a "*_sup.lms" file, and copy/pasting it into SE, and it still messes up the timing of my regular lights (but only when played by the G3-Mp3 - when played from computer it's fine). What am I missing?
×