With the announcement that Mattel is producing a 3d printer, 3d printing has gone completely mainstream. This is not a bad thing. My only question is: “What took them so long?”
Build a copy of this QFH antenna using 3/8 inch wooden dowels and some plastic bits to hold it all together.
The QFH antenna made a very significant improvement. Sadly, since I have no need of weather satellite images this project is pretty much complete.
The major issue with using Dick Cappel’s voltage boost circuit to drive a MOSFET is that a resistor would be used to pull down the gate voltage. This issue can be addressed by adding another transistor to actively pull down the voltage at the appropriate time. An additional transistor (an NPN) can be used very much as the first, except that it is set up to activate whenever the emitter voltage is less than the base voltage (essentially).
This configuration can be cascaded so that a single pulse voltage tripler (or more) can be constructed.
The following LTspice simulation shows the voltages at the 3 Pn points – the output of the pulse generator, the output of the first stage, and the input to the MOSFET.
Of course, this is cute and all, but in reality it would almost never be useful. Too many parts.
Dick Cappel has a very nice circuit for boosting the voltage of a single pulse (or PWM signal). It costs an additional transistor compared to my previous post but it allows the boosted voltage to drop to zero (take the output from the collector and remove all of the components right of the base resistor except for the resistor from the collector to ground – as noted on the webpage). For driving a MOSFET you’ll want to play with the values a bit, especially with the resistor from the collector to ground.
...and why it is almost certainly not the right answer to the problem of having a logic level signal and a non-logic level FET.
Mark VandeWettering posted an entry concerning the problem of driving an IRF510 MOSFET from a microcontroller running at 3 volts. The basic problem is that the threshold voltage of the IRF510 is specified as something between 2 and 4 volts. With only 3 volts to drive the gate it might not even be possible to turn on the device at all, much less use it to control any significant current.
The best answer to the specific problem that Mark presented was provided by Lee Felsenstein(1) – use a 2N2222 transistor instead of the IRF510.
I proposed, as a hack, a different approach. Since the MOSFET was to be driven by a PWM signal, use a diode and capacitor to boost the voltage to the gate of the IRF510. This is not a good solution to the problem. However, in some contrived cases it can actually work. Instead of being limited to driving the gate with Vcc, it is possible to drive the gate with Vcc + a little less than the min threshold voltage. Assuming the threshold voltage is less than Vcc, a couple of resistors are needed to keep the gate voltage under the min threshold voltage when the IRF510 should be turned off.
In the case of a 3 volt supply and an IRF510 this means that it is possible to drive the gate with something close to 5 volts, which means that you can at least be assured of driving the device with more than the max threshold voltage of 4 volts. Of course, the right answer is to use a different device. But, if the right contrived circumstances ever arises, it is possible to adequately drive the gate of a IRF510 such that the min and max threshold voltages are meet using only a 3 volt PWM signal, a capacitor, diode, and a couple of resistors. Note that I have not actually built the circuit, but LTspice indicates that it works as desired… Edit: I tried it on a breadboard and it does work as expected. Of course, it is still a lousy way to drive a MOSFET.
(1) I’ve never meet Lee Felsenstein, but it turns out that he designed the Sol-20 computer. A science and math teacher at my high school won a Sol-20 kit as a door prize at a computer show (that dates me). I believe I actually soldered a couple of the parts to the boards, but at this point I cannot be certain that I did not just watch the instructor do all of the soldering. It was the first computer I ever used. I learned Basic and Assembly programming on it, staying late after school to use it on as many days as I was allowed. I have “fond” memories of hand assembling code for the processor as the school did not have an assembler for the machine. Not something I’d want to do again, however. So, a very belated thank you, Mr. Felsenstein.
I’ve been working with Johnrpm on the Reprap forum on a DIY, single nozzle, drop on demand, inkjet print head. The print head itself was designed and built by Johnrpm, whereas I’ve been testing it with different nozzles and approaches to making it work reliably as a drop-on-demand device. It is constructed using a piezo disk designed to be used as an inexpensive (around $1 in single units) audio buzzer, and the entire device including driver electronics (but not including a microcontroller to control it) can be built for around $20, maybe less.
At this point the device works, as evidenced by the following images, but the drop size is currently rather too large so the next step is to experiment with smaller nozzles.
One of the potential uses for the print head is for powder printing (where the print head drops a solvent and/or binder on a bed of powder in order to bind the powder together in the appropriate places) of smaller objects. As such, I’ve been experimenting with a tiny manual powder printing bed using the sugar-sugar powder recipe on Open3DP as a base and I have successfully created several small, and very rough, 3D prints.
This diversion explains why I’ve not made any progress of late towards printing the final parts needed for constructing a Reprap Mendel. Well, that and the fact that I need to construct a larger heated bed for my Repstrap before I can print any of the remaining parts.
For more details follow the link above (or here) and read on. There is a lot of detail buried in the forum posts.
With apologies to The Graduate.
Years ago I was very interested in 3D computer graphics. This was back in the late 80s and early 90s when Silicon Graphics reigned supreme and simply being able to rotate a Phong-shaded object on the screen in real-time was a pretty impressive achievement. Today, of course, the cheapest computer can render in real-time scenes that would have taken days if not weeks to render even a single frame. Even more interesting to me, anyway, is that it is now practical for a hobbyist to construct a machine that can print out a 3D model as a real, functional, physical object.
3D rapid prototyping machines that can print out objects have existed for some time, and while the prices have been coming down in recent years, the least expensive commercial machines are still in the price range of a new car (~20k). As with any technology that requires an investment in expensive equipment there are business that will provide access to the machines for a price, such as Shapeways and i.materialise. Just send off your 3D design and some money and some days later your newly printed part will arrive via the mail.
RepRap is an open source/open hardware project with the goal of producing 3D rapid prototyping machines that can replicate themselves. The project was initially started as an idea contained in a paper by Adrian Bowyer that was published on the web on February 2nd, 2004 (Ref). While I personally think that the self-replication aspect is a bit oversold by some, the ability to produce a significant fraction of its own parts does prove that the machine is capable of producing functional as opposed to simply decorative parts.
It seems to me (and others) that the RepRap is very much like an Altair 8800. The Altair 8800 was the first microcomputer that was relatively affordable and widely available to hobbyists. It could be purchased as a kit or fully assembled and its base configuration included 256 bytes of ram. I remember first seeing a picture of it on the cover of the latest Popular Electronics in the library of the junior high school that I was attending at the time. No one at the time could have imagined that computers would one day be ubiquitous, used to produce and view graphics, music, videos and games (ok, maybe games, in the general sense, were foreseeable). At that time the Altair barely was capable of balancing a checkbook, although people in the know imagined that one day you could use one to hold and search all of your recipes in a small counter top device. Just like the Altair, the RepRap project has provided the inspiration for a variety of related projects and companies such as MakerBot and Fab@Home.
At this point the RepRap project is on its second generation machine, the Mendel. As designed it can print 3D objects in a variety of plastics, ABS and PLA being the most commonly used. Various people are experimenting with different print technologies, so the ability to print using different materials is experimentally available, with significant improvements foreseeable in the future. The quality is not up to the expensive commercial machines, but it can be used to produce functional parts.
I started working on building a RepRap style print head for my CNC’d Taig several weeks ago. Many of the parts were purchased (nozzle and Arduino and stepper driver, Peek thermal barrier, heater core kit and plastic filament), some parts were left over from other projects (geared stepper motor), and some parts I “designed” in CamBam and produced on the Taig (structural parts to hold everything in place, mostly). The design is roughly modelled on Wade’s Geared Nema 17 Extruder, except that I’ve used a stepper with the gearing built into the motor.
On Wednesday, April 21st, I attempted to print my first object, “Clouds”.
Oops. That print was quickly aborted. It turns out that the default extrusion rate generated by Skeinforge is much too high for the configuration that I’m using to control the extruder’s stepper motor. So, after some modifications to the AWK program that I used to massage the GCODE generated by Skeinforge so that it scales the extrusion rate and, after several other now forgotten false starts, my first object was successfully printed.
Ok, I really should have picked a more interesting object to print first.
The whistle rattles and whistles, but not both at the same time (that is, the ball in the whistle does not move in response blowing on the whistle). Also, the plastic I’m using is not food safe, so blowing on the whistle is not recommended. Besides, it tastes terrible…
This weekend I’ve been experimenting with settings, trying to tune the parameters in order to produce better quality objects. A dozen of the top half of the decorative container are shown below, printed using different speeds, layer depth, and flow rates.
Another test object, the Dodecahedron, is below.
The Dodecahedron has turned out to be a very good test piece. The left-most sample demonstrates what happens when EMC2 runs at a high feed speed in “G64” mode (that is, keep moving at speed regardless of how far from the stated points the tool has to be moved). This piece was printed at 32mm/s with a layer depth of 0.35mm. I’ve only had the Taig/EMC2 for a couple of months, so it took me a while to stubble across the cause of the problem.
The second and third samples are also printed at 32mm/s with a layer depth of 0.35mm. However, EMC2 was placed in “G61” mode (that is, move the the waypoint specified exactly, even if the tool must come to a complete stop). These are much closer to the desired result, but the acceleration/de-acceleration of the tool around the various waypoints leads to significant variations in the width of the extruded filament. In theory EMC2 should vary the speed of the stepper in the extruder in proportion to the speed of the tool in the XYZ axes, so I’m uncertain what is causing the effect. It might be due flaws in the extruder, or it might be due to non-linear effects in the melted plastic itself, or some other effect about which I’m currently unaware.
The forth and fifth samples where printed at 16mm/s with a layer depth of 0.4mm. EMC2 was placed in “G64 P0.1” mode (that is, the tool is allowed to be up to 0.1mm offset from the stated waypoint in order to keep the speed as high as possible). These are definitely better, but still show a significant variation in the filament thickness.
The final piece was printed using the same settings as the fifth piece, with the exception that the maximum velocity of the extruder was set to 15 inches per min (6.35 mm/s) within AXIS (the EMC2 GUI). This produced by far the best copy, but at a very significant increase in print time. The other thing to note about the final piece is the fact that scrap CDs make a very good print surfaces for small ABS objects, unless you print the first layer too close to the CD, in which case the ABS welds completely to the CD.
Of course, I don’t know any better than anyone else what the future holds, or what place RepRap will hold in the future. While I think that the RapRap is akin to an Altair 8800, it might turn out to more closely parallel CB radio. Anybody remember what that was?
In the nomenclature of the RepRep project what I’ve constructed is an EmcRepStrap, a RepRap bootstrap device using EMC2 to control at least the XYZ axes. Within the family of EmcRepStrap designs there are two different approaches to controlling the extruder: one that uses the standard RepRap extruder controller to control the motor and some software that extends EMC2 so it can communicate with the extruder controller, and one that uses EMC2 to control the stepper motor in the extruder directly. The second approach, which is the one I used, is described by David Carr. I’m using an Arduino to control the temperature of the extruder and the Arduino is currently not controllable from EMC2, so only a single fixed extrusion temperature is used.
The following AWK script was used to convert the GCODE produced by Skeinforge into a form that can be used by EMC2. This code allows the A axis values to be scaled by a parameterised constant. As it turns out this scaling is unnecessary as the values can be scaled in Skeinforge directly by changing the Speed:Flow Rate value in the Skeinforge configuration. I’ve left the feature in the AWK code as it is convenient to be able to change the scale on the A axis without re-running Skeinforge. The code also inserts the lines “G64 P0.1” and “G92 A0” into the output. The G64 so that EMC will not decide that missing a waypoint by anything more than a tenth of a millimeter is allowable, and the G92 line resets the A axis to 0 before it is otherwise used (which avoids an issue with the A axis position left over from previous runs).
The AWK code I used can be found here
Assuming that your A axis is set up in EMC2 so that a value of 1 indicates 1 degree of rotation on your pinch drive and that your pince drive is 3/8 inches in diameter, a Speed:Flow Rate value in Skeinforge of something around 8 to 13 is much closer to correct than 210 (the default value).
We went to see Neil Gaiman speak at UCLA this evening and it was a lot of fun. One of the questions that was asked was whether or not he was ever going to write an episode for Doctor Who. I’m happy to report that he nodded vigorously.