Things that Make You Go Hmmmmmm....Hardware Utility ?

[jimswinder]

How is it the Hardware Utility does not find a controller, yet the controller has a steady LED and plays the lights it is controlling??

 

And no...not an ID issue. Last week all 17 controllers showed up...nothing I have changed, now only 16...#7 is missing, yet works...

 

And it is in the middle of the daisy chain..

Edited December 9, 2015 by jimswinder

[ItsMeBobO]

by chance do you have more than one controller hooked up with the same unit?   This messes with me too.  Seems to work playing but not in HWU

[jimswinder]

I doubt it as I have not changed any ids since the show started on thanksgiving...and all 17 were showing up then

Edited December 9, 2015 by jimswinder

[kzaas]

I have had that happen before, I just refreshed the list a couple times and the missing controller showed up

[Orville]

I have had that happen before, I just refreshed the list a couple times and the missing controller showed up

I second this, have had the same thing occur.  usually one or two additional refreshes and the controller makes its way into the list.   Don't know why or how it happens, but it does.

[jimswinder]

Yep...just refreshed it again...all showed up...

[Santas Helper]

I NEVER think of the HU as an issue. I don't check controllers with it. I don't test with it. I really have no need for it. Been that way since about 2006.

Then again, I don't have much issues unless it's my own fault at something silly or stupid anyways.

[JeffF]

I don't search for controllers anymore. I just use the console to go to the controller and channel I want(which usually to test the lights).

[Orville]

I NEVER think of the HU as an issue. I don't check controllers with it. I don't test with it. I really have no need for it. Been that way since about 2006.

Then again, I don't have much issues unless it's my own fault at something silly or stupid anyways.

My question is based on the text I bolded in your statement above.

 

Then how do you update your firmware in your controllers if a new firmware update comes along?    HWU is the only way I've ever been able to do it, do you not update your firmware>  Or have you found another way to do it NOT using the HWU?

[bob_moody]

I had this happen last year. Turned out it was a bad network cable.

 

Bob

[LOR Staff]

Let us assume that EVERYTHING is running perfectly in the world.  That means there is 0 noise on the line, no way to corrupt data, etc.  Basically a perfect physical network.  A marginal data network is a much more likely cause, but Let's see if I can explain this for a perfect world:

 

RS485 is a half-duplex serial communications method.  That means that it is good for having a  'conversation' one on one with a device, or for single sender with 1 or more receivers (no talking back to the sender).  One to Multiple is how LOR works.

 

One on One is reliable in two directions because we have accepted protocols/signals we can use.  For example, lets talk about 2 random pieces of equipment that speak over RS232 or RS485.  In this case we can treat them the same as they are both serial communications methods - the only difference is in how the signal is actually transmitted.  When we are one on one, we can devise a way to know when one device is done transmitting.  Think about speaking to someone over a two way radio.  When you are done you say 'Over'.  That lets the other person know you are now ready to listen.  Same thing with serial communication.

 

When we are one to many, the many can't speak back to the one.  Think Radio Broadcast.  You are given information, but you can not answer or ask a question.  Again, same thing with half duplex serial communication.  This will always work - there is no one to talk over you.

 

But what happens if you need one to many back to one?  Sure there is Full Duplex (with its own issues) but remember that RS485 is HALF duplex.  Communications can only go in one direction at a time.

 

Here is what happens with the HWU and finding units:  HWU is master, and so it has the COM port open to broadcast (not receive).  You then ask the HWU "Tell me what controllers are attached".  That is going to require a reply back from each station.  The HWU sends a packet down the line that says 'All controller, check in!'.  It then quickly changes the lines over so that it is the slave - IE it is now the receiver not the transmitter.

 

Controllers get this message and say "Ok, we need to send data up".  They need to switch modes from receiver to sender.  Now notice you have ALL your units trying to talk at once.  They ALL think they can be sender.  If they all start sending data at once, they will crash into each other.

 

Controller firmware has code in it to minimize collisions.  I'm not the firmware guy but if I remember correctly what happens is that a controller will wait for a random number of cycles and then start listening on the line for so many cycles.  If it hears data during the listening phase it repeats this.  Eventually it will listen, and not hear any data for n number of cycles.  Once that happens the controller assumes the line is clear, switches to transmit mode, and sends the info upline to the computer.

 

Ahhhh..  But notice I said MINIMIZE, not ELIMINATE.  If there is one thing you learn in computer school it is that random numbers ARE NOT random.  It is possible that 2 units generate the same random numbers, wait the same number of cycles, and immediately crash all over each other.  You also learn that no random number can be truly random if it has bounds.  Only when we say 'create a random number that has the range negative infinity to positive infinity - [–∞, +∞], could it even be remotely considered random.  In our example, we can't say 'Generate a number from 0 to infinity', and that is the number of cycles you need to wait.  Are you going to want to wait 10 minutes let alone 10 million billion years (or really longer)???

 

[FYI:  I am making these numbers up and don't know the exact values] Instead we have to say 'Generate a random number between 0 and 19', wait that many cycles.  Well by doing that we now have a 5% chance that even with only 2 units that we will generate the same random wait time.  Once we start getting more and more units on the line, this rises dramatically.  How dramatically?

 

Want to know the odds that 2 people in the same room have the same birthday?  Let's rephrase that just a little.  In a room with 23 people or more, what is the chance that any 2 people have the same birthday?  Hold on to your hats:  50% OR BETTER.  In fact with as few as 40 people in a room you are nearly 90% assured that 2 of them share a birthday!

 

How does that relate to this?  Well, in the birthday problem, we could number each day of a year from 1-365 (or 366 for leap years, but don't confuse the issue).  With 40 people in a room, with 90% certainty 2 of them will have the same number 1-365.  So if we picked random numbers 40 times with the range of 1-365, 90% of the time we will get a duplicate.

 

Think of controllers as the people with the birthdays.  Now imagine that there are only 20 days in a year instead of 365 - the same 20 values (0-19) that are randomly generated by the firmware.  If we pick random values 0-19, how many values do we have to pick before we are 90% sure we will get a duplicate.  Hint: Not many.  If I remember my math properly (from 30 years ago), the probability curve is: 1-e^-(n*n)/2*20 Where 1>= n <=20.

 

Ouch.  Please don't make me do that again.  More info:https://en.wikipedia.org/wiki/Birthday_problem  

 

Anyone still reading?  What does that have to do with the cost of tea in China?  The more units you have, the more likely it is that you will have a collision. The more collisions you have, the more 'erroneous' reports you get (which will be discarded).  

 

That is why we tell people:  "If the lights are solid it is most likely working.  If you think a controller isn't working, connect it by itself and locate it.  If it can be found you are OK."

[SparkDr]

DevMike must've really reduced it to the simplest of terms.  Even I understood what he was saying!

[Santas Helper]

My question is based on the text I bolded in your statement above.

 

Then how do you update your firmware in your controllers if a new firmware update comes along?    HWU is the only way I've ever been able to do it, do you not update your firmware>  Or have you found another way to do it NOT using the HWU?

 

If my show is working properly (which it has been for years), I'm not updating the firmware. I haven't a need to update.

I even upgraded licenses and still haven't updated firmware. All my controllers work just fine as they sit.

If LOR adds holograms as an option, then I might need to update the firmware.

DevMike MUST be an engineer. 

[jimswinder]

Thank you Master Mike...

 

The current price of tea in China is: £ 3.01

 

From Slave Jim...

Edited December 10, 2015 by jimswinder

[LOR Staff]

A member PMed me, pointed out that there are better ways to do this, and was questioning why we would actually do something like this.  He was absolutely right.  He is a programmer and saw right through the obvious poor design.  In our defense, how we do things is actually much closer to what he described.  

 

I have grossly oversimplified the process to try to make it more accessible to the masses.  To all of my fellow code monkeys out there, I apologize if I made you toss your lunch.  Much like the E1.31 document I wrote a couple of months ago, I try to put things in as simple of terms as I can.  That sometimes means deviating from the mechanics of how something actually happens to give easy to relate to real world situations.  Sometimes those deviations make people in the know cringe.  

 

I hope I didn't ruin to many monitors with spit coffee!

[dgrant]

Before retiring, one of my systems used RS485 however it was a full-duplex operation of several devices. But, I was using proper RS485 wire with dual shielded pairs and outer shielded too. Way more expensive than LOR uses with Cat5 cables which are cheap. My longest run there was about 400 feet or so and it worked nice. Now saying that, I wrote the software too so I had full control of how it worked and it was a dedicated system for only one purpose, sending commands and receiving critical data back to the sending computer for only this one system. I would easily imagine that LOR could go full duplex but our Cat5/6 wires won't do it any more and the costs to us would go way up along with the hardware interfaces being replaced and their having to write and debug a bunch of code. At some point, it becomes cost-prohibitive to do have more capability for a real-world business such as they are.

[bbass101]

I had this problem once with one of my controllers. Turns out the IC chip that transmitted the code back to the computer had been bad.
It was a CTB16 and the chip was either a MAX3082EEPA or a ISL81487LIP   Either way replaced that chip and it was all good.  If your controller worked fine before I don't this would the cause but its something to try.

[Wayne K]

I just stumbled across this post and found it interesting. I actually have a controller sitting here to send back to LOR. It is a CTB16 with ID of 10. It is controller # 6 in the chain. It continually shows up as an unknown object. Once in a while with enough refreshes it will show fine. It seems to work ok. All of the rest normally show up ok. So with Mikes description above, it sounds like this should be more of a random thing, rather than the same controller all of the time. If it is the same one all of the time, it sounds like there could be something wrong with it as bbass101 describes above? Do I send this back to LOR to replace this chip or do I send a ticket in for a new chip and try that and see what happens. It would be a lot easier to get a chip and replace that instead of taking the controller out of the enclosure and unhooking all of the wiring.

Wayne

Edited February 6, 2016 by Wayne K

[LOR Staff]

Open ticket and we can send you a COMM chip.  Takes about 2 minutes to replace and that would eliminate that from the equation.  Other things can cause issues, but that would be the first place to start (and is cheap and easy)

[Wayne K]

Thanks DevMike

1 on the way.

Wayne