morden11 Posted October 7, 2019 Posted October 7, 2019 Summary of what's going on: Current network (Call it the Regular Network) is set to 500k Enhanced and has the following controllers daisy chained: 5 16 Channel Gen 3 Residentials 1 Ancient CMB24 10W RGB light controller 8 50W RGB Floods and 9 Cosmic Color Devices (ordered this year with the summer sale) with 2 ports each as follows: 4 CCB with each port having 100 C9 bulbs 2 CCP with each port having 100 bullet bulbs 3 CCR with each port having 1 ribbon I have the most recent version of Light O Rama software and renewed my license as of 4 days ago. I have Pro level software. I checked every controller by itself on the hardware utility before putting out into the yard. All of them registered in the Hardware Utility. **************************************************************************** I set all of them up with power, and daisy chained all of the controllers using Cat5 cable ***************************************************************************** I use the Hardware utility to check all controllers on the network. It bounces back only 14 of them: a) The 5 Gen 3 16 channel units (all firmware 1.09) b) The 8 50W flood units RGB (all firmware 1.05) c) The CMB24 (though it's not calling it that anymore it's calling it interpup or bootloader or something) ***************************************************************************** Absolutely none of the CCR / CCB / CCP controllers bounce back on the hardware utility now (even though they did when they were by themselves) I look at the 5 Gen 3 16 channel units inside the case and it's a 'solid' green light I look at any of the CCB / CCP / CCR units inside the case and it's a flashing red light which it shouldn't be of course And, here's the really weird thing. Even though the CCB / CCP / CCR controllers don't register, it 'still' sends the signal from hardware utility down the daisy chain as I have the some 50W flood units and Gen 3 16 channel units both before 'and' after the Cosmic Color units in daisy chain order. I don't even know where to begin with figuring this out.
Mr. P Posted October 7, 2019 Posted October 7, 2019 Update your software version and license level in your profile, we can't help if we don't know what you are working with. Also, are the CCP, CCB and CCR the original or are they the newer second versions?
dibblejr Posted October 7, 2019 Posted October 7, 2019 (edited) You should only connect one at a time while setting up in the HU for the first time. It used to state that in the manual. Less confusion that way. Also in the top right corner of HU what is your max Unit IDs set at? Just go with F0 for now and wait the extra minute for it to search. Then after all is set up in HU you can adjust it later. You could have multiple problems going on at the same time. Once a controller is recognized then add the next, if it’s not recognized move on until all that work well together are connected. Then figure out if a controller is bad or you need a software update. JR Edited October 7, 2019 by dibblejr
morden11 Posted October 7, 2019 Author Posted October 7, 2019 Mr P, The license and software versions are now updated.
TheDucks Posted October 7, 2019 Posted October 7, 2019 All this is on ONE LOR adapter? Problem 1 Pixels need a RED (high speed) network set to 500 or 1000K (value determined by the slowest device limitation) and the total number of channels is limited (show complexity affects) You are in luck, all your Residential and CMB are modern versions. and will also play nice up to 500K, so these can be on either the old, slow Black (56-115K) or a faster Red adapter http://www1.lightorama.com/network-speeds/ is the matrix of what is allowed (device-speed, device-mode)
k6ccc Posted October 7, 2019 Posted October 7, 2019 If I did the math right in my head, that is about 2,400 channels, which should be OK on a single 500k enhanced network. The way the HU operates can result in stuff missed, however the flashing red status LEDs are not right. Before you get too excited, ignore the HU and start the control panel and play a sequence for real. See if the lights play and if not, check the status LEDs.
TheDucks Posted October 7, 2019 Posted October 7, 2019 The Miss identify in HU happens. Personally, I would Terminate the last controller on the cable. 120 ohms between 4 + 5. (this makes the CAT5 less susceptible to noise) Some of the gen 2 Pixies now have a jumper for this, but that unit must be last on the line
morden11 Posted October 8, 2019 Author Posted October 8, 2019 Alright I figured it out. It unfortunately wasn't any of the above nor was it the solution proposed by the technical support team at Light O Rama. A combination of Youtube research and trial and error led me to the right fix. Here is what happened: I sat down with each controller in our house to set the Unit ID with the Hardware Utility, one at a time. When I did this, and then did 'Refresh', it found the unit correctly with the ID I had set. Like an assembly line I did this with 8 more Pixel (2 Port) controllers. Then I put them all outside and attached them to the network via Daisy Chain and the 'black' USB 485 unit. However, when I fired up the Hardware Utility 'after' plugging in power to the entire network, that's when I saw the issue I noted above. All the Gen 3 16 channel controllers appeared, all the 50W floods appeared, but none of the 9 Pixel controllers appeared nor did the CMB24 (which was Unit #1). Instead it showed that Unit 1 was anything from 'InPup' to 'Bootloader'. Well, here is the rub and I'm a bit salty that the instructions for the new Pixel controllers aren't more clear. Apparently the factory sent me these things with a dipswitch pushed into the 'On' position, so the unit defaults back to '01' as a Unit ID. This didn't happen though when I had the controllers set up by themselves, it only happened when they were plugged into the network with other controllers. Not sure why that is, why the manual doesn't say with a picture to move the dipswitch to the 'off' position so they're all off (as I don't think everyone wants controllers to all be Unit ID 01). Anyway, once the network reset all the controller IDs, then the Hardware Utility was detecting '9' Pixel controllers with unit ID 01 as well as the CMB24 which also had unit ID 01. I'm guessing the software didn't know what to do with that information so it showed weird readouts for unit ID 01 and nothing else. So I went controller by controller outside, resetting each and pushing the dipswitch to 0. And now everything works great. I clearly need the 'Red' 485 unit as the Black one just can't keep up with the pixel controllers, but that's a much easier fix. I'd ask for the Light O Rama folks to not presume that people using the software and hardware have understanding of the fundamentals of this stuff and instead produce instructions that assume the least common denominator, like me. It would have saved me days of needless troubleshooting.
tlogan Posted October 8, 2019 Posted October 8, 2019 And don't forget that the Pixies AUTOMATICALLY assign a UnitID to each port. So, if you assigning a Pixie to UnitID01, and it has two ports, it automatically assigns UnitID02 to the other port. If you're ordering one after the other, your next available UnitID for any controller is UnitID03.
Mr. P Posted October 8, 2019 Posted October 8, 2019 It sure does state it in the manual. Here is an exert taken from the manual: Hardware Configuration Assigning a Unit ID Second generation Pixies have a DIP switch with 8 positions. This is used to set the unit ID. If all switches are set to ‘off’, then the unit ID as set by the Hardware Utility will be used. (see below) Refer to the DIP Switch Address Settings and LOR Unit ID to DMX Start Address sections for the mapping of your desired LOR/DMX address to DIP switch settings.
morden11 Posted October 8, 2019 Author Posted October 8, 2019 Mr. P, I'm a layperson, that paragraph might as well have been written in hieroglyphics. The only reason I know what a dip switch even is is the result of exhaustive research and self-teaching on the concept. What I'd prefer is that the instructions are written for a small child, or a golden retriever, and not with the assumption that a user has fundamental understanding of the hardware involved before picking up the manual. Then I might have had the light bulb go off before running into this issue. TLogan, Thank you kindly for the feedback. I learned this by accident using the SE5 system and it just happened to show the Unit ID of X+1 as a property of the 'Prop' when I double clicked Port #2. Absent that, I'm sure I'd be trying to also figure out why I set one Pixel controller to 0E, another to 0F, and then things don't work right since it should be 0E, 0F and then 0G, 0H. This is another topic that should be in plain english in the manuals.
dibblejr Posted October 8, 2019 Posted October 8, 2019 (edited) 1 hour ago, morden11 said: Alright I figured it out. It unfortunately wasn't any of the above nor was it the solution proposed by the technical support team at Light O Rama. A combination of Youtube research and trial and error led me to the right fix. Here is what happened: I sat down with each controller in our house to set the Unit ID with the Hardware Utility, one at a time. When I did this, and then did 'Refresh', it found the unit correctly with the ID I had set. Like an assembly line I did this with 8 more Pixel (2 Port) controllers. Then I put them all outside and attached them to the network via Daisy Chain and the 'black' USB 485 unit. However, when I fired up the Hardware Utility 'after' plugging in power to the entire network, that's when I saw the issue I noted above. All the Gen 3 16 channel controllers appeared, all the 50W floods appeared, but none of the 9 Pixel controllers appeared nor did the CMB24 (which was Unit #1). Instead it showed that Unit 1 was anything from 'InPup' to 'Bootloader'. Well, here is the rub and I'm a bit salty that the instructions for the new Pixel controllers aren't more clear. Apparently the factory sent me these things with a dipswitch pushed into the 'On' position, so the unit defaults back to '01' as a Unit ID. This didn't happen though when I had the controllers set up by themselves, it only happened when they were plugged into the network with other controllers. Not sure why that is, why the manual doesn't say with a picture to move the dipswitch to the 'off' position so they're all off (as I don't think everyone wants controllers to all be Unit ID 01). Anyway, once the network reset all the controller IDs, then the Hardware Utility was detecting '9' Pixel controllers with unit ID 01 as well as the CMB24 which also had unit ID 01. I'm guessing the software didn't know what to do with that information so it showed weird readouts for unit ID 01 and nothing else. So I went controller by controller outside, resetting each and pushing the dipswitch to 0. And now everything works great. I clearly need the 'Red' 485 unit as the Black one just can't keep up with the pixel controllers, but that's a much easier fix. I'd ask for the Light O Rama folks to not presume that people using the software and hardware have understanding of the fundamentals of this stuff and instead produce instructions that assume the least common denominator, like me. It would have saved me days of needless troubleshooting. It’s actually included in the writeup I did in the General Hardware Tab. Had you watched the video or read the writeup. Glad you got it up and running. Flipping off the dip switch is the first thing I recommend to everyone. JR Edited October 8, 2019 by dibblejr
tlogan Posted October 8, 2019 Posted October 8, 2019 1 hour ago, morden11 said: Mr. P, I'm a layperson, that paragraph might as well have been written in hieroglyphics. The only reason I know what a dip switch even is is the result of exhaustive research and self-teaching on the concept. What I'd prefer is that the instructions are written for a small child, or a golden retriever, and not with the assumption that a user has fundamental understanding of the hardware involved before picking up the manual. Then I might have had the light bulb go off before running into this issue. TLogan, Thank you kindly for the feedback. I learned this by accident using the SE5 system and it just happened to show the Unit ID of X+1 as a property of the 'Prop' when I double clicked Port #2. Absent that, I'm sure I'd be trying to also figure out why I set one Pixel controller to 0E, another to 0F, and then things don't work right since it should be 0E, 0F and then 0G, 0H. This is another topic that should be in plain english in the manuals. Just making sure you know that after 0F (no 16s and 15 ones) is 10 (one 16 and zero ones). Took me a long time too and I used to program IBM mainframes and had to convert between Hex and Decimal (sometimes binary...0001, 0010, 0011, 0100, 0101,0110) all the time. I CLEARLY remember sitting in math class thinking "WHEN am I EVER going to need to know this?"
Recommended Posts