Motherboard databus on a theatrical moving light working(but not quite)

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:

formatting link

I've got the schematic for the motherboard here:

formatting link

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."

Reply to
Dan Charette
Loading thread data ...

hall sensor is stuck low? try to measure output and touch with magnet. pin on buffer is stuck low?, try to compare input output ,and wiggle input

-Lasse

Reply to
langwadt

Lasse, Thanks for your interest and thoughts on this problem. What's so strange and why I've posted here is because of what you had mentioned. Both items, the hall sensor and the buffer are operational and functioning. Neither are stuck. Which is why this problem is so bizarre. There is a second gobo wheel on this very line whose hall sensor data is shared with the first problematic one. This second one, when it is time for its procedure in the init, works just fine on this same data buffer line. The second uses its own hall sensor, but access to the data bus is exact same door. As for the hall sensor on my problematic wheel, it's functioning fine too. I'm able to manually move the wheel during init and affect the hall sensor when the magnet comes in proximatey... it changes to a very nice logic low and then changes back to high when I move past. The circuit, for all practical purposes appears to function perfectly... each part that is. But, my problem is that during the initialization of the light, this color wheel doesn't spin, and hence doesn't find its home position. I'm inclined to think that for some reason or another, the code thinks that the wheel has already found its position and doesn't bother to spin the wheel at all. And the question is WHY this is happening, why is the init procedure not even spinning the wheel? How can the code have received a position true from this hall sensor that never generates its low? I'm leaning towards somehow the code is reading in a logic low at some point early in this part of the init procedure. And that sorta speaks of a timing issue somehow. But, being that this product actually worked at some point, can a databus timing issue come up like this... is it possible to just suddenly start to have timing issues on a hardware bus that still functions 99% of the other time? I mean, the code executes with no issues. All the other motors and hall sensors seem to correctly receive and send data... it's just this one. And, it repeats everytime... there is no intermittence about it, whatever is wrong is clearly wrong, it doesn't spin the motor at init in this procedure 100% of the times I've tried it, probing it and experimenting with different tests. This is why I'm a little stumped and thought I'd turn to you guys as the collective pool of experience and talent here is astonishing at times. :) Thanks again for your thoughts and time on this Lasse. Have a great remainder of your week. Dan 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."

Reply to
Dan Charette

snipped-for-privacy@fonz.dk Inscribed thus:

On the basis that you have a second working motherboard, it would rule out any problems at the light end.

Have you checked the obvious ? Such as broken wires or pins in or on the connectors on the faulty motherboard ! Even dry joints at the point where the connector is soldered to the board.

--
Best Regards:
                Baron.
Reply to
baron

That is the bit I don't get - if the first sensor produces a low when the first wheel locates, how can another sensor share the same input line (and pull it high) before it rotates into the correct position? Or is the individual sensor energisation controlled by the processor? In which case the first (working) sensor is not being de-energised.

--
Geo
Reply to
Geo

Can't to you look at the hall sensor signal with a meter?

It is possible that the hall sensor is failing giving a marginal signal. If it has been getting worse over time you will see the problem as soon as it is bad enough to not work with the 'motherboard' in the unit. It might still be good enough for a different 'motherboard' so you can't assume the fault must be on the 'motherboard'.

If two sensors really do share the same signal in some kind of wired ored scheme then one not working points to a fault with the sensor or wiring or magnet.

Reply to
nospam

I'm sorry, I didn't elaborate more on this part, now I see it could be confusing. So, let me embellish a little, hope this helps: There are a total of 4 wheels that need to locate themselves. The initialization procedure of the code sets them spinning in pairs.

1st pair of wheels spin, and when each wheel in the pair hits its point, the hall sensors then send back a low to the buffer, which is constantly being read by the processor during the time frame given for the procedure to execute. The procedure for this pair doesn't seem to exit until either a timeout(after a minute or so) or when each of the wheels find their positions. After they've found their positions, the processor sends a command to the motors to rotate them just a tiny bit so they move out of the hall sensor's range, hence opening up the two data lines to be used by the second pair of wheel/sensor combinations on those same data lines as the first. Yes, it doesn't make sense if the first set of wheels weren't spun back out of their sensor's range. So, my problem lies in the 1st pair of wheels, and one of the wheels just doesn't even start spinning. Once the 2nd wheel has found its position, BOTH wheels spin just a little out of position and then the 2nd pair of wheels start their locating... and BOTH of these wheels rotate and find their positions using the SAME two data lines for the hall sensor data.

What's not shown on the schematic is the pair of halls on these data lines. Where they're at is on page two, connector PL251, on the 1st three pins is the pair of halls, piggyback/paralled and pins 456 have the second set of halls paralled. They're paralled just in the wiring coming from this connector. That's why this is utterly confusing because I know the data lines are working correctly because of the 2nd pair's correct alignment. The question really is why doesn't that first wheel even start spinning? I'm just wondering if there is some data lagging on the bus on the line that the processor is checking for that hall sensor's feedback of correct position. And even before the wheel starts spinning, the processor reads a logic low, giving it a "Wheel 1 is in position" indication. That's why the procedure always exits once wheel two finds its position. At least, that's my theory anyway. And for my theory to hold any water at all, what the heck could cause this scenario to occur? If this board did in fact work when it was new, what failed or what could have failed? Even so, if I had some kinda problem on the databus, I would suspect that nothing would work, not just this one little thing. The motors and RAM are hanging on this databus and if there was some timing issue, is it possible only this one little thing could be not working? Just haven't seen a problem quite like this before. Thanks for the help and thoughts on this issue. It's been a very puzzling one, that's for sure.

On Thu, 10 Dec 2009 18:36:07 GMT, Geo wrote:

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."

Reply to
Dan Charette

I would love to believe it's with the sensor, but there's too much evidence pointing away from it.

1) I've probed the suspect sensor with a scope and can manually rotate the disc past it and see and very nice logic low, well within the margins for a true low and high on this 5V system.

2) The disc doesn't even spin which doesn't really give the sensor a chance to do speak out and tell the processor that the disc is aligned.

3) I am with you on the idea of the 2nd good motherboard having some different characteristics that would accomodate a marginally operating sensor, but seeing that 2nd hall sensor on this data line operational 100% of the time just makes me believe that this problematic motherboard is handling the incoming data on this line correctly.

4) I have swapped the suspect hall sensor with one of the other working ones and problem did not follow the sensor.

Thanks for the thoughts though... it's really helpful and spawns plenty of great ideas.

Have a great day! :)

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."

Reply to
Dan Charette

Ok -with the working motherboard - can you position (by hand) the problem wheel to the sensor position then do the init. Does the good motherboard then behave the same as the bad?

--
Geo
Reply to
Geo

Not sure if this would give any info (from the manual):- "Factory Test (SPEC/FTST): This menu provides an effects test (ETST), a movement test (MTST), and a sensor test (STST) used for quality control. The sensor test includes programs for testing sensors on the color and gobo wheels (COL1, COL2, Rgob, and Fgob)."

--
Geo
Reply to
Geo

So,

sorry it's taken me a bit to get a reply posting going, but I did some more experiments with the lighting fixture motherboard and thought I'd present them for further eveidence.

The tests available in the factory menu are sorta of a continous loop of the individual parts in the initialization procedure. They do help to isolate troublesome areas, like in this case, and save time since you don't have to always power the whoel fixture up just to test one small part.

I'll describe what's happening when I run the color 2/Rgobo test.

Under normal conditions, the light would have powered up and went through its initialization, and the color wheels and gobos would be positioned correctly. When engaging the test procedure for color 2, the LED display on the side panel simply says "ON." Now, what this means is that the shared data line for these two sensors is indicating a true state, or low in this case. If I manually move both wheels, just a little so each of the two hall sensors are out of range, the display says "Off" Then, the processor will send a command to one of the motors and rotate it until the wheel comes back into alignment.

Both of the wheels, when moved out of hall sensor range, will indicate on the display "On" when I manually move them past the hall sensor. It's just that the color two wheel, when "Off" just won't trigger the processor to move the wheel, spinning it around to get it in position.

I've done some probing on the data bus ahead of the motor drive data buffer, on the main data bus connecting the processor and the flash RAM. And, I can actually see activity when I rotate the Rgobo wheel off position, then the data lines activate and the motor rotates the rgobo wheel until it's in position. I try this with color 2, and I cannot see a change on the data lines. So, this tells me that the processor isn't giving a data write to the motor data buffer at all.

I have swapped out the flash RAM IC121, and loaded it with new programming and no change, the problem is still there. I've also swapped out IC122, 74HCT574 motor driver data buffer, IC123 - 74HC541 Hall sensor data buffer, and IC126 - 74HCT138 Motor driver chip select decoder.

The only chip left that has anything to do with this function is the microprocessor. I just cannot imagine that this would be the problem.

As I stated in earlier posts, I am absolutely able to control this color wheel motor under normal operation. It moves, and steps as it should. It's just that upon initialization, it doesn't move and it's not in the right spot for normal operation later.

My only real grasping at straws thought now is that somehow, the code that the processor is reading for the init procedure on this one motor, is somehow corrupted when the processor reads it or writes it. As I said, I've swapped out the flash memory, so the chances of there being a bad byte or two of data, in the same place would be astronomical.

Can a processor read something from RAM and just not write out correctly what it read? Without seeing the source code, I can't imagine there being some strange sequence for spinning the motor that is different from the normal operation procedure. So, I would think that in initialization, the procedure just calls a motor drive function until the hall sensor is aligned. So, why is the processor just not spinning the wheel only in initialization? That is the big $10,000 question.

Any more ideas to try?

Thanks for thinking on this... it sure helps to bounce these ideas off someone. The manufacturer BTW is non-responsive. I've sent a few e-mails so far and not one response.

Have a great even>>

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."

Reply to
Dan Charette

sorry it's taken me a bit to get a reply posting going, but I did some more experiments with the lighting fixture motherboard and thought I'd present them for further eveidence.

The tests available in the factory menu are sorta of a continous loop of the individual parts in the initialization procedure. They do help to isolate troublesome areas, like in this case, and save time since you don't have to always power the whoel fixture up just to test one small part.

I'll describe what's happening when I run the color 2/Rgobo test.

Under normal conditions, the light would have powered up and went through its initialization, and the color wheels and gobos would be positioned correctly. When engaging the test procedure for color 2, the LED display on the side panel simply says "ON." Now, what this means is that the shared data line for these two sensors is indicating a true state, or low in this case. If I manually move both wheels, just a little so each of the two hall sensors are out of range, the display says "Off" Then, the processor will send a command to one of the motors and rotate it until the wheel comes back into alignment.

Both of the wheels, when moved out of hall sensor range, will indicate on the display "On" when I manually move them past the hall sensor. It's just that the color two wheel, when "Off" just won't trigger the processor to move the wheel, spinning it around to get it in position.

I've done some probing on the data bus ahead of the motor drive data buffer, on the main data bus connecting the processor and the flash RAM. And, I can actually see activity when I rotate the Rgobo wheel off position, then the data lines activate and the motor rotates the rgobo wheel until it's in position. I try this with color 2, and I cannot see a change on the data lines. So, this tells me that the processor isn't giving a data write to the motor data buffer at all.

I have swapped out the flash RAM IC121, and loaded it with new programming and no change, the problem is still there. I've also swapped out IC122, 74HCT574 motor driver data buffer, IC123 - 74HC541 Hall sensor data buffer, and IC126 - 74HCT138 Motor driver chip select decoder.

The only chip left that has anything to do with this function is the microprocessor. I just cannot imagine that this would be the problem.

As I stated in earlier posts, I am absolutely able to control this color wheel motor under normal operation. It moves, and steps as it should. It's just that upon initialization, it doesn't move and it's not in the right spot for normal operation later.

My only real grasping at straws thought now is that somehow, the code that the processor is reading for the init procedure on this one motor, is somehow corrupted when the processor reads it or writes it. As I said, I've swapped out the flash memory, so the chances of there being a bad byte or two of data, in the same place would be astronomical.

Can a processor read something from RAM and just not write out correctly what it read? Without seeing the source code, I can't imagine there being some strange sequence for spinning the motor that is different from the normal operation procedure. So, I would think that in initialization, the procedure just calls a motor drive function until the hall sensor is aligned. So, why is the processor just not spinning the wheel only in initialization? That is the big $10,000 question.

Any more ideas to try?

Thanks for thinking on this... it sure helps to bounce these ideas off someone. The manufacturer BTW is non-responsive. I've sent a few e-mails so far and not one response.

Have a great evening! :)

Dan

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."

Reply to
Dan Charette

Which flash chip did you use for the master? From the flakey board or=20 the proven good board?

bus

problem wheel

then behave

movement

sensor test

(COL1, COL2,

Reply to
JosephKK

:

bus

lem wheel

n behave

movement

sor test

1, COL2,

to OP..

you seem to have a non obvious problem like a marginal logic level or switch bounce or something that doesn't show up obviously...

since you have 2 wheels and 2 sets of parts, if you can't puzzle this out, I suggest swapping parts around good to bad till the problem changes and "follows" a bad or marginal part...

If swapping a part suddenly fixes it completely, then you have a combination of marginal things..

I'd also be tempted to add 0.1uF caps across all the logic signals to eliminate glitches. There may be a 1us glitch pulse that the SW sees that you don't

Mark

Mark

Reply to
Mark

I had replaced the flash memory on the flakey board with a known working flash memory and still the same problem occurs.

wheel

behave

movement

test

COL2,

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."

Reply to
Dan Charette

Mark,

Thanks so much for your comments on this problem.

I have switched and swapped out not only the sensors, motors and drive circuitry on the questionable board, but also have swapped in known good parts onto this board and the problem doesn't/hasn't moved at all. It's still all about this one color 2 motor not spinning during its init procedure to figure out its position.

I will definately try the .1uf caps on the logic lines as I suspect there is data glitch somewhere that the processor is reading in and hence, thinking that it's aligned when it really isn't and thus, doesn't even fire the motor move the wheel for positioning.

I've just not ever come upon a problem like this where the system is

99.9999% working, except for some discrete procedure.

That's what is really odd about this is that the motor drive works just fine after the init finishes and I can move the wheel and it even sounds and seems to keep up at the same speed as the other wheels. The hall sensor on this wheel works correctly when I manually move the wheel and look at the logic levels coming into the buffer. And since there is another sensor sharing this same logic line, it always seems to find its position so it would seem that logic line post the buffer is being read by the processor correctly.

I will let you know what happens after I try out the caps and see if that elicites a change or not.

Thanks again for the comments and help on this really puzzling issue.

See ya!

wheel

behave

movement

test

COL2,

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."

Reply to
Dan Charette

OK, does the micro have on board ROM? Just how are the index sensors=20 handled between the sensor and the uP/uC. What kind of input pin is = used?=20 (you may have to analyze the code for this one)

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.