Round 2 Goes To The Electrons

synaptron_mega_round2

Our never-ending quest to develop a powerful but tiny motion controller for DC motors continues.  In my second hardware iteration of the Synaptron Mega design I was flummoxed, flustered, flabbergasted, and then finally forged forward.  But the electrons gave me a run for the money on this one.

My second hardware design was actually a set of minor modifications of the first design whose focus was primarily one of minimization and simplification.  There were a few changes to ease thermal considerations, and I wanted a larger screw terminal because, well, my test wires are kind of big.  And big wires carry more current.  And more current is better.

Right off the bat I found a layout error that took out the system’s motor current measuring circuit.  Not good, but I simply commented out the over-current stuff in the operating system and started testing without that protection in place.  This did mean that a 3rd revision of the circuit board, and another round of testing was required down the road.  But I could still test most of the system and the board change would be easy.

I built up two prototypes, and decided to use a linear actuator motor with a potentiometer for feedback as my initial test load.  This was sent to me by a customer for testing.  The motor is big, noisy, 24V, and pulls somewhere north of 15A at the start of movement.   It was perfect.  It also annoys everyone else in the lab.

But my prototypes decided they didn’t always want to run their firmware.  Sometimes they would power up and run.  Sometimes they would communicate, and sometimes they would just lay there like so many pieces of aging and worthless silicon.  When I did get them to run, some of the analog measurements were quirky.  They were kind-of-right.  Part of the time.  Sort of.

I built the remaining prototypes (2) to increase my sample group, and saw similar problems with the units not running their firmware.  I began to look at the reset circuit, and from a schematic standpoint it looked fine.  From a board layout standpoint I did have the in-circuit programming header too close to the H-bridge creating the potential for noise related resets.  And I ran the reset line from that header to another connector, so the end user could have access to the reset line.  That would all have to be fixed.

Eventually I started looking at an input/output pin that shared two functions.  It flashed an LED on power-up, and when communication was received (configured as an output).  It also configured itself as an input to see if the pin was pulled low on power-up and during run time.   If low on power-up it entered bootload mode (for firmware upgrades).  If low during run time it would restore the factory default settings.  This pin was floating low during operation.  I later realized that noise related resets and this pin being low were causing the controller to enter bootload mode.  When this happened  it appeared to not be running, but was actually waiting to receive a new operating system.  Adding a pull-up resistor fixed this, but not the reset problem.

I also managed to track down the analog measurement problems.  I had not cleaned some water soluble solder flux well enough.  The solder flux is necessary to use when soldering the really small surface mount components, and it leaves a conductive residue.  I had run into this issue on an earlier design, so was aware of it.  But you know how things go, one minute you’re soldering, the next you’re involved in a multi-million dollar hip-hop band opening for Justin Bieber.   Sometimes you get busy and forget.

That’s when the H-bridges started to blow up.  Not all of them.  Just most of them.  They made this groaning noise, like an old man falling in a ditch without one of those “I’ve Fallen and I Can’t Get Up” thingies.  The parts I’m using are pretty stout.  I can’t imagine that they were suffering from over-current problems since they have short circuit protection built in.  It pretty much had to be a transient voltage failure.  They were rated for operation to 42V, and apparently getting that and more.  This was mostly because of the motor I decided to test with.  I had to make a design decision.  Did I really need to run a motor that large with a board that small?  Hecks yeah I did.

Long story not short but less long, I started marking up the schematic and pretty soon was looking at another re-design.  Round 3.  The changes will impact the final cost and board size.  But I did find a pot of rainbow at the end of the gold.  I threw on some external components; some diodes, a transient voltage suppressor, RC snubber, and tripled the motor voltages capacitance.  I’ve now been running the 24V actuator for about an hour with no noise related resets and no H-bridges falling down.   That gives me hope that round 3 will end in a victory for the engineer, and not the engineered.

Speak Your Mind

*