Using DC motors to power computers

pics_4-stroke-generator_002_600

Electric generator experiment from HomoFaciens:

The generators I am using are in fact geared DC motors, left over from a project with my sponsor RS Components. The modern abacuses being powered during my experiments are a Raspberry Pi Model, a SIMATIC IOT2020 and an Arduino Uno. A 2×16 characters LCD is used to display results. Two geared DC motors are on my board with the test setup

More info at HomoFaciens.de.

Check out the video after the break.

App note: Electrical techniques for using different power sources on vibration motors

an_precisionmicrodrives_ab011

Application bulletin from Precisionmircodrives on powering vibration motors from different and some cases fluctuating power sources. Link here (PDF)

As vibration motors have a wide variety of applications, they are often integrated into systems which have different power sources. A common concern, in terms of power supply, is adjusting the source power supply voltage to a suitable level for the vibration motor or drive circuitry. This protects the motor, and can ensure a constant level of performance for uses like haptic feedback.

Automatic fan controller for server racks

38933511880_7a892b8310_z

Dilshan Jayakody published a new build:

In this post we describe fan controller which we designed for our 9U wall mount server cabinet. This fan controller is designed to drive a 12V DC cooler fan with pre-configured intervals or by monitoring the temperature of the server cabinet.
Core components of this fan controller is CD4060 binary counter, LM35 temperature sensor and LM358 operational amplifier. In this design CD4060 is used as long duration timer and it can configured to trigger cooler fan from 1-minute and up to 4-hour.

See the full post on his blog here.

Derek Schulte: Path Planning for 3D Printers

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)

The Problem

spaghettiPath planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.

simpleYou can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.

Trapezoids, and the KISS Principle

There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.

trapezoid[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.

Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.

Closed-loop Control

Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.

stall[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.

And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.

Conclusion

kiss[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!


Filed under: 3d Printer hacks, cons, Hackaday Columns

Derek Schulte: Path Planning for 3D Printers

[Derek Schulte] designed and sells a consumer 3D printer, and that gives him a lot of insight into what makes them tick. His printer, the New Matter MOD-t, is different from the 3D printer that you’re using now in a few different ways. Most interestingly, it uses closed-loop feedback and DC motors instead of steppers, and it uses a fairly beefy 32-bit ARM processor instead of the glorified Arduino Uno that’s running many printers out there.

The first of these choices meant that [Derek] had to write his own motor control and path planning software, and the second means that he has the processing to back it up. In his talk, he goes into real detail about how they ended up with the path planning system they did, and exactly how it works. If you’ve ever thought hard about how a physical printhead, with momentum, makes the infinitely sharp corners that it’s being told to in the G-code, this talk is for you. (Spoiler: it doesn’t break the laws of physics, and navigating through the curve involves math.)

The Problem

spaghettiPath planning goes on inside the 3D printer itself. It’s what the 3D printer’s firmware does with the received G-code that turns it into the physical motion of motors along the X, Y, and Z axes as well as the extruder. While G-code is universal, it’s also unrealistic: it specifies a series of points in 4D space (the extruder, remember?) and the speeds that are needed to get there. Path planning blends knowledge of the physical printer’s motion control abilities and tries to make the end result match the G-code as much as reasonably possible, without taking forever. Being the interface between idealized G-code and a real printer, the planning firmware needs to take the design of the printer itself, with all its physical limitations, into account.

simpleYou can make your own, one-off, 3D printer out of unobtainium, dragon scales, and the unbilled labor of a year’s worth of weekends. But if you want to make a product to sell to the general public at a reasonable price, it’s got to be built using commodity parts and work robustly. This is what drove [Derek] to use a DC motor with an encoder instead of the ubiquitous, heavy, and relatively expensive stepper motors that most other 3D printers use. Driving DC motors in open-loop feedback meant that none of the “standard” printer firmwares were going to work — he needed to roll his own. And that’s how we have this talk, about getting from A to C, around the corner in B, as quickly and accurately as possible.

Trapezoids, and the KISS Principle

There are a few ways to turn a piece of G-code that says “go north at 50 mm/sec and then go west at 50 mm/sec” into machine movement. One is to go north at full speed, slam to a stop, and then jerk off west at full speed. This is what the earliest versions of DIY 3D printer firmware did — and the result was noise, and vibration of the print head, and degradation in print quality. These were ugly times.

trapezoid[Derek], and the path planner in grbl, chose the next most complicated solution — moving at constant acceleration for each segment of the path, resulting in trapezoidal velocity profiles. This turns out to work decently well in practice and be easy to compute. [Derek] added corner rounding to the routine: where the G-code said to make a sharp corner, the firmware would take a curved corner that’s close enough that it wouldn’t look bad, but also doesn’t require the nozzle to slow to a stop. Combining the two is basically the simplest solution that can work well.

Connecting a few segments together is the next step, but it lets the printer eventually come to a stop, whether at the end of the path or because a user pressed the pause button.

Closed-loop Control

Most stepper-driven 3D printers operate in open-loop control mode. The firmware tells the stepper motor driver to take ten steps forward and hopes for the best. When a printer loses steps, layers get de-aligned from each other, and if you’ve had this happen catastrophically in the middle of a print, you know why this can suck.

stall[Derek]’s printer runs in closed-loop mode, meaning that if the printhead is too far south of where it should be, the firmware can tell that this is the case and apply more power to a motor to get it back right. Again, [Derek] chose one of the simplest methods that could work: PID control with feedforward. Of course, this means calibrating the algorithm to the machine, but a well tuned PID algorithm is a joy to watch.

And the closed control loop provides additional benefits. Where stepper motors have to be way overspecified to avoid the dreaded missed steps, closed-loop DC motors can get by on lower torques. The coolest trick that [Derek] plays with the feedback, however, is in using the ability to detect motor stall to home the printer. There are no limit switches on the three physical axes. Instead, when the motor hits the end of its ability to move, the firmware detects the stall and uses this to zero the coordinate axes. This reduces parts and simplifies the device. We’re all for that.

Conclusion

kiss[Derek] designed his motion planning routines on the same tools that we all use, and used basically the simplest possible algorithms that would work well, avoiding “academic” complications for their own sake. In the end, this allowed him to optimize for speed, look fifteen steps ahead, include some necessary special tweaks like logic for dealing with very short segments and get the product out the door for a reasonable price. Motion planning and control in a closed-loop system is never simple, but “apply the KISS principle as far as possible and then tweak for performance later” is something that all of us hackers could stand to get tattooed on some suitably long part of our bodies. Better still, let’s just thank [Derek] for the reminder and exemplification!


Filed under: 3d Printer hacks, cons, Hackaday Columns

Ask Hackaday: Dude, Where’s My MOSFET?

Transistors versus MOSFETs: both have their obvious niches. FETs are great for relatively high power applications because they have such a low on-resistance, but transistors are often easier to drive from low voltage microcontrollers because all they require is a current. It’s uncanny, though, how often we find ourselves in the middle between these extremes. What we’d really love is a part that has the virtues of both.

The ask in today’s Ask Hackaday is for your favorite part that fills a particular gap: a MOSFET device that’s able to move a handful of amps of low-voltage current without losing too much to heat, that is still drivable from a 3.3 V microcontroller, with bonus points for PWM ability at a frequency above human hearing. Imagine driving a moderately robust small DC robot motor forwards with a microcontroller, all running on a LiPo — a simple application that doesn’t need a full motor driver IC, but requires a high-efficiency, moderate current, and low-voltage-logic compatible transistor. If you’ve been here and done that, what did you use?

Bipolars

Years ago, the obvious answer to this dilemma would be TIP120 or similar bipolar junction transistor (BJT) — and a lot more batteries. The beauty of old-school Darlington transistors in low-voltage circuits is that the microcontroller only needs to produce a small current to push relatively large currents on the business end. With BJTs, as long as you can get over the base-emitter junction voltage (typically under one or two volts) you just pick the right base resistor and you’re set. This is in contrast to FETs of the day which require a given voltage to pass a current through them. Gate voltages for the big FETs are optimized for the 4-5 V range which is lousy if you all you have is a LiPo battery.

TIP122/127 H-Bridge: Easy to Build, but a Battery Hog
TIP122/127 H-Bridge: Easy to Build, Battery Hog

While the power Darlington is easy to drive, it has a few drawbacks. First is the voltage drop through the device when it’s conducting. Drop one or two volts on the transistor and you’ve pretty quickly got a few watts of power going to waste and a hot chip. And that’s assuming that you’ve got the voltage drop to spare — a volt or two off of the 3.6 V on a LiPo battery pack is a serious loss.

With apologies to [Adam Fabio], the BJT is off the list here. It’s easy to drive at low voltages, so it would work, but it won’t work well because of stupid quantum mechanics.

FETs

MOSFETs should be great for driving small motors, on paper. They have incredibly low on-resistances, easily in the milliohms, and they can turn on and off fast enough that the PWM will be efficient and noiseless. The flaw is that garden-variety power MOSFETS, for driving big loads, tend to have similarly large gate threshold voltages, which is a showstopper for low-voltage circuits. What can we do?

If the motor were being driven by a higher-voltage source, and you were switching the MOSFET on the low side, then you can use the motor’s power supply to drive the MOSFET, switching it on and off with whatever is handy — a small-signal BJT is just about perfect here. That’s the classic solution, illustrated here. As long as the motor voltage is high enough to fully open the MOSFET, you can just use that for the switching voltage.

In the actual application that spurred this column, I wanted to use a LiPo cell for the motor and the logic, but I ended up doing something ridiculous. I started off with a go-to MOSFET from my 5 V logic days, the IRF530, but it barely turns on at 3.3 V. So I cobbled on a 9 V battery to provide the switching voltage — purely to drive the MOSFET into full conduction. This 9 V “high” voltage is switched by a 2N2222 small-signal BJT and seems to do the job just fine. It works, but it’s a horrible hack; I wanted to drive everything off the LiPo, and failed.

Other Options?

Big power MOSFETs, in addition to having a higher gate voltage, also have some capacitance that needs to be overcome to turn them on and off. Between the fully-on and fully-off states, they get hot, so it’s important to push enough current into the gate fast enough that they transition quickly. Thus, big power MOSFET circuits use a gate driver circuit to drive them. A low-voltage gate driver, paired with my IRF530, would certainly be an option here. But all this just for a medium-sized DC motor? Seems like overkill.

7307Once we embrace complexity, there are small H-bridge and push-pull driver ICs that might fit the bill, and they’ve naturally got MOSFETs inside. Now that I think about it, I’ve built small-motor H-bridges from N/P complementary pair MOSFET chips in the past, and they work for low voltages. Somewhere in my pile I have some IRF7307s that will just barely do the job. I’d be ignoring one of the two paired FETs, but who cares?

Taking the next step in IC complexity, the various stepper-motor driver ICs can usually push and pull an amp or two, and operate on low voltages. You could conceivably drive a DC motor off of one phase of a stepper controller, but that just seems wasteful. But something like (half of) a TB6612 would work.

On the other hand, the fact that these various gate-driver, H-bridge, and stepper controller ICs can handle the currents I want with low logic voltage thresholds suggests that there should be at least a few monolithic, and cheaper, MOSFETs that can switch a few amps around on low voltages. Where are they hiding?

The Ask

So what would you do when you need to push up to two amps DC in one direction at LiPo battery voltages, with low loss, driven (potentially by PWM) from a 3.3 V microcontroller? Feel free to take this as a guideline, and deviate wherever you’d like from the spec if it brings up an interesting solution.

Whatever you do, don’t give me current figures out of a datasheet headline that are based on microsecond pulses, only to find out that it’s outside of the part’s DC safe operating area. I’ve been down that road before! It never ceases to amaze me how they design parts that are rated for 100 A at 10 microseconds that can only handle 300 mA steady state.

This has to be a common hacker use case. Does anyone have the MOSFET I’m looking for? Or do you all just use motor driver ICs or tack random 9 V batteries into your projects? (Ugh!)

[MOSFET tattoo image from Google image search; Make Yr Mom Sad on Tumblr (dead link)]


Filed under: Ask Hackaday, Engineering, hardware

Treadmill To Belt Grinder Conversion Worked Out

[Mike] had a bunch of disused fitness machines lying around. Being a skilled welder, he decided to take them apart and put them back together in the shape of a belt grinder.

In particular, [Mike] is reusing the height-adjustment guide rail of an old workout bench to build the adjustable frame that holds the sanding belt. A powerful DC motor including a flywheel was scavenged from one treadmill, the speed controller came from another. [Mike] won’t miss the workout bench: Once you’re welding a piece of steel tube dead-center on a flywheel, as happened for the grinder’s drive wheel, you may call yourself a man (or woman) of steel.

belt-grinder-parts belt-grinder-flywheel-welding belt-grinder-speed-controller

The finished frame received a nice paint job, a little switching cabinet, proper running wheels and, of course, a sanding belt. Despite all recycling efforts, about 80 bucks went into the project, which is still a good deal for a rock-solid, variable-speed belt grinder.

Apparently, disused fitness devices make an ideal framework to build your own tools: Strong metal frames, plentiful adjustment guides, and strong treadmill motors. Let us know how you put old steel to good use in the comments and enjoy [Mike’s] build documentation video below!


Filed under: tool hacks