Hello All!
I've been on a troublesome repair to a motherboard that is out of a theatrical moving light. It's a typical embedded system with a slew of step motors and halls effect/LED sensors.
A little background on the light fixture for those that might not know. It's basically a high power light that is able to be panned and tilted in virtually any direction via a simple data link from a far away location with a lighting desk. Along with that, the color of the light's output can be changed almost instantly. Most all concerts and theatrical performances these days have many of them on the stage doing all the fancy lighting you'll see.
Here's a link to the product page for the light:
I've got the schematic for the motherboard here:
The issue that I'm having is subtle, but it's a very puzzling problem that I thought I'd turn to the gurus here to see if anyone has any ideas.
To change the color output of the light, a metal disc with several glass color filters is rotated inside the light chassis in front of the beam. This disc has a little magnet on the edge of it and there is a hall sensor that is located on the chassis.
Upon initializing the light, the motherboard sends out commands to each of the motors which spin the discs in order to locate the positions of the color wheels and the shape wheels(called gobos).
There are two color wheels and two gobo wheels in this particular light. When they are initialized, both color wheels should spin, align and then the next procedure is the the gobo wheels should spin, and align. They spin slowly, and when the magnet comes in proximaty of the hall sensor, the color/gobo wheels stop and the system assumes they're aligned.
In my situation, I only have one of two the color motors spinning. The motor and the drive circuitry are good because after all the initialization is done, I can send commands and move the wheels, but the wheel that never moved during initialzation isn't positioned correctly and hence, the wrong colors will be there.
I'm guessing that what is happening is that the software thinks that the problem wheel is in already position so it doesn't command the motor to move it and the code just waits for the second color wheel to align until moving on to the next procedure in the init procedure. It seems both wheels in the procedure in the code are sort of ANDed. In other words, each wheel needs to find its position, and then the procedure exits.
On the first page of the schematic, what's supposed to happen is that on pin 15 IC123, the 74HC541 buffer, there should be a logic low when the wheel is in position. The processor enables this buffer in pulses, several hundreds per second it seems, for a read operation. The processor reads the databus at this time and checks for that logic low to show up for these color wheels. I5 is my problematic wheel, and I4 is the other working wheel.
There are actually two different hall sensors, one from a color wheel and the other from a gobo wheel, that share the same data line back to the 74HC541 buffer, IC123, data line labeled I5. There is also another pair(the other color wheel and other gobo) that share I4. It seems that they're able to be seperated by the code since only one wheel spins at a time, no need to chew up extra data lines.
In initialization, the pair of color wheels rotate, they find their positions, then the pair of gobo wheels rotate and find their positions. So, with that in mind, I know the data line and this buffer are working because the gobo wheel that is sharing this line with the color wheel, seems to align perfectly everytime.
I've got a 2nd motherboard that I swap into this light chassis it everything works fine, so I know the problem is with the motherboard.
I've reloaded firmware a number of times, and the problem still remains.
I've tried putting a 8.2k resistor on this databus D5 and tied it both high and low just to see if a pullup/pulldown might help.
I just can't seem to put my finger on why this is malfunctioning. The system boots up and everything works except this one thing. How can a system like this operate? The RAM and processor, and data buffer for the motor decoders are on this same databus, so if there was some problem with that data line, I would suspect everything would just cease to operate.
Everything about the circuit seems to be working properly, but why is the initialization process not spinning this motor to locate it? Am I assuming it right in that the code sees it positioned true before it even spins it? It just seems so obivous that is why it doesn't spin as I'm always watching the working color wheel locate, and then the init moves onto the gobo wheel pair position procedure.
Does anyone have any ideas on some tests or otherwise that I can try to do to figure out what the heck is going on here?
Granted, this is an already engineered product that at one time, worked. I have a 2nd motherboard that works as well, so is it possible to have an intermittent timing issue? I just have never seen a databus "degrade" and still operate 99% of the time. And if this possibility exists, how the heck do I fix it without access to source code to adjust timing, etc.
Any ideas would be greatly appreciated. Sorry about the long description. I've been on this thing for the past couple of days and it's fresh in my mind. So, just trying to give enough info for anyone that might be able to help.
Please, let me know if you'd like anymore elaboration.
Thanks!!!
Dan
{dan_at_thesonicfrogFUZZ-dot-com} Remove the "FUZZ" and replace the underscores and such from my e-mail address to contact me. Dan Charette {dan_at_thesonicfrogFUZZ-dot-com} Remove the "FUZZ" and replace the underscores and such from my e-mail address to contact me.
"I may not always be right, but I'm never wrong."