MechEtroller 1.3: Still Trolling

Far from stalling at version 1.2, MechEtroller 1.3 boards arrived in early January 2015, While still full of problems, I'm happy to report that this version has been the most successful yet!

1.3 uses a similar D2PAK FET package to 1.2, but with a revised layout. I'm finally convinced I've got a pretty efficient FET configuration which maximizes power track cross-sectional area, minimizes trace length, and provides very convenient diode locations. Disadvantages include having no great location to put the hefty power rail capacitor, slightly more complicated heatsinking geometry, non-unified power input and output thru-holes, and a loss of  symmetry.

There are also a number of other improvement over 1.3 besides fixing schematic mistakes.The series linear power regulators are much larger, not because the current draw has increased, but because I had serious reliability problems during debugging with the less robust smaller LDOs. Encoder input is now supported, and is now routed to the 328 interrupt pins, The logic side layout is also more clean in my opinion.

Soldering was uneventful and decently easy given the wide spacing of components. Power inputs worked right off the bat, as well as microcontroller bootloading and programming. Even gate driver triggering worked smoothly with no load. As soon as the drivers began triggering the FETs while they were under load, however, the board began experiencing an uncontrolled resetting symptom. For a week I probed, soldered, and desoldered, convinced that poor capacitive decoupling somewhere  in the voltage regulation,  logic circuitry, or gate drivers was causing a low voltage dropout (triggering a reset until voltage levels rose again). After going through a number of capacitors and inductors of various sizes, I eventually discovered a crucial schematic mistake.

The capacitors on the gate drivers were accidentally placed across the Vrail and output of the driver, instead of ground. I don't know exactly what kind of nonsense effects this had inside the driver, but it wasn't very productive. 4 point to point soldered caps later, and the board could actually drive a motor! 

After powering a couple small test motors, I ramped up the testing to a more challenging 24 volt electric scooter motor, powered by a Lithium Iron Phosphate battery pack rated at up to 800 A output! Quickly, it became apparent that further FET heatsinking was required. At first, in keeping with the low production cost goal of the project, I designed a simple flat aluminum plate that mounted to the top of the controller.

After some testing with a handy plate of copper, however, it became apparent that this was no where near sufficient for the heat output! So in order to continue testing, I grabbed some relatively cheap heatsinks and thermal epoxy off of Amazon and mounted it on.

I'm pretty sure this represents the biggest heatsink that can reasonably be fit on a controller of this size. An absence of time and proper equipment limited the extent of testing that could be performed with this setup, but the results were pretty impressive. At least one chair in the lab now has a small hole where a vise-grip clamped motor used to be. Despite the much improved heat sinking, temperatures were still quite high everywhere on the FET side of the board (even when driving smaller loads). For an unknown reason not too after this, at least one FET shorted out and ruined the prototype. It could have been a random metal chip or maybe something about the heatsink itself, but the epoxy didn't allow much of an opportunity to take it apart.

It wasn't until much later that I learned why the bridge operated so inefficiently. For a long time I've read of N-channel MOSFETs described as being "low side" transistors. Blissfully unaware of the ramifications of this, I've been using the same transistors (and more importantly, the same gate drivers) for FETs used on both high and low sides of the h-bridge. The problem (if not obvious already) is that the Vgs or gate-source voltage of my IRFS7537PbF FETs needs to be approximately 12 volts to operate with the lowest possible on-state resistance. However, in an H-bridge, nearly all of the voltage drop occurs across the motor, meaning that the voltage at the source pin of the high side FETS is dictated by the raw battery voltage feeding into the controller. If I was feeding the controller with a 24 volt battery, I would need a 36 volt (relative to ground) gate voltage to produce the required 12 volt potential between gate and source. Talk about a big mistake.

But hey, it's all a learning experience. As a bonus, now I won't be forgetting anytime soon. Solutions to this problem include: using a p-channel MOSFET or finding a gate driver that can dynamically boost its voltage to activate a high-side n-channel FET. It turns out that finding p-channel FETs with the same power rating as my existing n-channels is difficult and expensive, So that leaves the more complicated gate driving circuitry as the winner. Fortunately, Digikey (and Allegro Microsystems) are happy to help with the A4940 full bridge driver. This awesome chip packs all four gate drivers needed for high and low side n-channel FETs into one package with a bunch of bonus features. This will be my platform for version 1.4.

The list of changes I'd like to make in the next iteration includes:

• Swapping out the four individual gate drivers for the A4940 chip

• Overall cleaner component layout, particularly with the capacitors for logic components

• Simplifying voltage regulation down to just one regulator (thanks to the A4940)

• Switching to a surface mount crystal (just to standardize)

• ICSP header (it's not worth the hassle of using a pogo ICSP programmer when I have the extra board real estate)

• Possibly using FETs with a lower Rds (at least on the high side)

• Larger reverse polarity protection diode on the voltage regulator

• More capacitance across the power input (to provide buffering for larger motors)

Version 1,4 will get it's own update when the boards arrive,

3d printer updates 3: Almost there (for real)!

When I last left off, the mechanics of the 3d printer were near enough complete, with the wiring closely following suit. This progress and the progress that will follow all occurred in only a few days between the RPI Formula Hybrid season and final exams (hence the abrupt halt in work and weak photo documentation).

Now that the (substantial amount) of wiring was in a test-ready state, I began the process of tweaking Marlin (my open source controller firmware of choice) and debugging stepper motor connections. For a long time, I kept getting very strange "stuttering" effects from the steppers. I found the culprit to be a combination of swapped wires, poor limit settings in Marlin, and uncalibrated current control potentiometers on the stepper drivers . Once the x and y axes were moving smoothly (and scaled to correctly replicate mm inputs), I switched attention to the z.

The new NEMA 23 stepper motor was working great on the z, right up until the moment when it wasn't. Every time that the motor passed a certain point during upward travel, the speed would bog down, an unpleasant noise would be emitted, and usually the leadscrew clamp would slip. Initially, I though this was another case of misaligned guide rails or screw marring, but it never occurred on the downstroke, and worked fine at every other place on the rail. Many tests later, I finally noticed an edge of the aluminum rear panel that had warped in far enough to catch the gantry when it slid up from below. The motor had literally been trying (and failing) to tear the machine apart! With no immediate fix available, I simply shimmed the z-axis rails a fraction of an inch inwards by adding a washer to all connection points. This solved the problem, and shouldn't have any effect on accuracy due to the 3-point leveling build plate.

After fixing another relatively minor mechanical problem (incorrect build plate spacing), I was finally ready to tackle the extruder: one of the few parts on the entire machine I just purchased instead of designed. The extruder was a MB8 knockoff with no frills, bought more than a year ago for the initial 3d printer project. Initial wiring went well, with the thermistor responding properly and the hotend heating relatively quickly. A small amount of smoke was produced at full temperature, but I attribute this mostly to months worth contaminants and grease that had been collecting on the surface. It gradually stopped smoking after being on for a while.

Unfortunately, after loading it up with filament, things started going wrong. The first few inches of filament would readily squeeze out the end of the nozzle, and then slow to a crawl. Meanwhile, the internal driving gear would grind away at the seized filament, jamming the extruder and necessitating a tedious teardown of the assembly. About 10 time-consuming disassemblies and reassemblies later, I determined the cause of the problem to be unacceptable heating of the brass feeder tube leading up to the hot end. Before the filament had even reached the nozzle of the hot end, it would have already become sufficiently soft and malleable (technical term: gooey) to buckle over itself and stick to the walls of the tube.

I quickly came to understand that I needed a dramatic temperature transition between the feeding tube and hot end to allow the process to run as intended. There was nothing I could do about the conduction up through the brass tube, but I had hope that I could at least introduce some forced convection on the midsection of the tube. The ideal design would have circular concentric fins running up the tube with a fan blowing over them. With the night getting late on my last day to work on the project, I went for a hail mary option.While I ran over to the machine shop to turn a crude aluminum heatsink, my friend biked to the local (not yet shut down!) Radioshack to grab some Arctic Sliver heat paste. The result was a marginally better hot end:

With only a single (wide) parting tool left unbroken in the shop, and no time to grind a new one, I was only able to get two fins out of my stock. Despite the improvements, it still was not enough to get the extruder functional before the deadline. With no time to order a new one before flying across the country to California, the printer has sat at RPI all summer. While I'm sad to have to wait so long to finally see it run, I'm at least glad that many of my design elements that I was most concerned about worked. 

With the printer on my mind's backburner all summer (as I've been busy having too much fun interning at Tesla Motors), my eventual plan was to do a full extruder swap with whatever the internet claims is the best design. The downside, of course, is that this also requires re-waterjetting a new mount plate and possibly more parts to ensure functionality. So imagine my surprise when browsing Amazon revealed this. I love it when pictures in my head turn out to be real things! While it is not compatible with my extruder design, I'm excited enough about the design that I intend to buy one and modify it to accept the new hotend. If that too fails, I may have to plan on the original full replacement.

In the near future I'll try to write an update about the continuing progress of MechEtroller, a build log of an exciting year-long Formula Hybrid project, and possibly something relating to this: