3D Printering: Hobbs Meters And 3D Printer Reliability

February 10, 2015 by Brian Benchoff 40 Comments

A direct link to Makerbot's 3-pack of Smart Extruders is very hard to find — A direct link to Makerbot’s 3-pack of Smart Extruders is very hard to find

It’s been a little over a year since Makerbot introduced their new line of printers, and since then there have been grumblings about the quality of the Smart Extruder that each one of these printers comes with. While there is no 3D printer extruder that will not eventually clog, wear down, or otherwise break, there are reports of the Makerbot Smart Extruder failing in only hundreds or even tens of hours of use. Considering that a single large print can take a dozen or so hours to complete, you can easily see the why the Smart Extruder is so despised and why even the availability of a three-pack of Smart Extruders is a joke in the 3D printing community.

Of course a cheap shot at Makerbot that plays right into your preconceived ideas and prejudices is far too easy. We’re here to solve problems, not just state them, so here’s what we’re working with: to quantify the long-term reliability of 3D printers we need a way to measure the mean time before failure of extruders. This is already a solved problem; it’s just not implemented.

On aircraft and some very expensive engines that power things like buildings and ships, there’s one gauge, tucked away in the control panel, that keeps track of how long the engine has been running. It’s called a hobbs meter, and the idea behind it is extremely simple – when there is power going to the Hobbs meter, it counts out hours on a small clockwork display. The resolution of the display is only tenths of an hour, usually, but that’s good enough for scheduling maintenance and to be mentioned in NTSB accident reports.

Spend enough time with a 3D printer, and you’ll quickly realize the ‘estimated print time’ is merely a ballpark, and with failed prints the ‘total print time for this object’ isn’t exactly a perfect measure of how many hours you’ve been using your extruder. Only by directly measuring how many hours are logged on a hot end or how many kilometers of filament have been sent through an extruder will you ever get an accurate idea of how long an extruder has been running, and how reliable a printer is.

Hobbs meters are available from Mouser, but you’ll be overpaying there. The better option is from a vendor in a different niche; $30 for a meter that can connect directly to the extruder heater. If enough people add this and keep proper logs, there’s a slight chance of improving the state of 3D printers with real data and not the prejudices of people trying to justify their own designs and purchases.

But perhaps that’s too hard; adding a $30 item to a printer’s BOM just for the sake of data is a bit much. Luckily, there’s an even simpler solution that won’t cost a dime. Just measure the time a heater has been on in the firmware, or save the total length of extruded filament in a microcontroller’s EEPROM. Every printer firmware out there, from Marlin to Repetier to Sprinter has in it a way to calculate both the length of time a heater has been on or how much filament has been pushed through a nozzle.

However, this is 3D printing we’re dealing with. An organized community is not a luxury we currently enjoy, and for this to work several things are needed. The first is somewhere to upload failure statistics. This would be a web site, naturally, with the ability to input the printer make, extruder and hot end model, and the time since last clogged nozzle. The website itself is just a database, some JavaScript, a bit of CSS, and some hosting costs; not hard until you consider tens of thousands of operators would have to know about this website and contribute.

Secondly, if we’re not going with mechanical Hobbs meters there would need to be a ‘total time heater on’ or ‘total length of extruded filament’ variable in the various firmwares. There would hopefully be standardized Gcodes or Mcodes to read and reset this variable.

Will this happen? Of course not. Organization isn’t a strong suit of the RepRap project, and any company that implements Hobbs meter functionality will probably lock that up in proprietary obfuscation. However, Makerbot isn’t dumb, and given they’re selling three-packs of extruders, I would bet they have some data on the MTBF of their extruders. A community-based measurement of the most common cause of broken printers is certainly possible, but like all problems it’s one of organization, not technology.

3D Printering is a semi-weekly column that digs deep into all things related to 3D Printing. If you have questions or ideas for future installments please sending us your thoughts.

Retrotechtacular: Multi-Purpose Military Magazines Make Maintenance Memorable

February 10, 2015 by Kristina Panos 18 Comments

Whether you’ve been following Retrotechtacular for a while or have firsthand experience with the U.S. Army, you know that when they want to teach something to a someone, they’ll get the job done in spades with a side of style. The era between WWII and the Vietnam War was a golden age of clear, simple instruction that saw the Army use memorable material to teach a wide array of topics. And speaking of golden ages, the Army found success with comic book-style instructional magazines drawn chiefly by [Will Eisner] of Spirit fame.

The first of these rags was called Army Motors, which premiered in 1940. It introduced several memorable characters such as a Beetle Bailey-esque bumbling soldier named Private Joe Dope, and no-nonsense gal mechanic Connie Rodd, a sharp cookie who’s as brainy as she is buxom. Educational and entertaining in equal parts, the magazine was pretty well received.

Its successor, known simply as P.S. started its run around the beginning of the Korean War in June 1951. These magazines were intended as a postscript to the various equipment maintenance manuals that soldiers used. They offered all kinds of preventive maintenance procedures as well as protips for Army life. The eye-catching depictions of Connie Rodd demanded soldiers’ attention while the anthropomorphic equipment illustrations encouraged them to listen to what their equipment told them.

Additional artists including [Joe Kubert] and [Dan Spiegle] were brought in to produce P.S. on a monthly basis. As the years marched on, the magazine’s character base expanded to include representatives of other military branches solving specialized problems. The bumbling idiot types were 86’d pretty early on, but cheesecake was served well into the 1970s.

Did we mention that they’re still making P.S.? Here’s the February 2015 issue and a friendly PDF warning.

Thanks for the tip, [Itay]!

Retrotechtacular is a weekly column featuring hacks, technology, and kitsch from ages of yore. Help keep it fresh by sending in your ideas for future installments.

Ask Hackaday: Bringing Your Design To Market

February 9, 2015 by Will Sweatman 19 Comments

While many of us have made and documented our open source projects, not many of us have tried to sell our design to the masses. [Scott] developed, marketed, and “bootstrapped” a cool looking MIDI controller. Now, before you get your jumpers in a bunch – the project is completely open source. [Scott] documented the entire process of not only the design, but the trials and tribulations of bringing it to market as well. Calculating costs, FCC testing and the many other challenges of bringing a consumer electronics device to market are all detailed in his blog. Join me while we look at the highs and lows of his interesting and eventually worthwhile journey.

Putting yourself into a game where orders are in the tens of thousands, with hundreds of thousands of dollars changing hands is not easy when you’re just a guy with an idea and a soldering iron. [Scott] was up for the challenge, however. He quickly realized that much of the margin is spent on advertising and to cover risk. On his last order, some of the paint was chipping off. He had to fix the paint and repackage everything – all at his cost.

He also talks about the learning process of product design along the way. His original idea was to make a volume controller, but couldn’t sell a single one. He was forced to redesign the software into the MIDI controller as it exists today. He tried to launch a Kickstarter, but was rejected. This turned out to be a good thing, however, because he would have wound up kickstarting a product that didn’t work.

For advertising, he relied on Google and made some extremely detailed tutorials for his product. Many of them can be used for other MIDI controllers, and often come up in Google searches. Smart. Very smart.

Be sure to check out the video below, where [Scott] gets into some capacitive touch design theory, and talks about how not to cut your final product in half while on the CNC.

Have any of you ever tried to mass produce and sell one of your designs? Let us know in the comments!

Continue reading “Ask Hackaday: Bringing Your Design To Market” →

Hackaday Links: February 8, 2015

February 8, 2015 by Brian Benchoff 10 Comments

[CNLohr] is famous for his extremely strange projects, including something that does something with Minecraft that even he can’t describe. Over the years, he’s built up a vast collection of projects that have been both incredible fails and successes. Here’s a video tour of all those projects.

For this week’s edition “Kickstarter is going insane”, you only need to look at the title of the campaign: Tesla Coils for North Korea.

Last week, a few slow scan TV signals were received from the International Space Station. Here’s the reddit thread.

The worst thing about using an Arduino in a semi-professional environment is the IDE. Here’s cuwire, a better IDE.

Wanna see something insane? How about an SSH library written in x64 assembly?

Radio Shack is in its death throes, and since you haven’t gone in the last few years, you might as well head out one last time and pick up some items on clearance. Here’s the list of store closings (PDF) and all 1,784 stores slated to be closed plotted on Google Maps.

Hacklet 33 – Minecraft Projects

February 6, 2015 by Adam Fabio 6 Comments

Minecraft hit the PC gaming scene as an alpha release on May 17, 2009. Something about the open world, the crafting system, and the various modes of gameplay made it an instant hit. Since then Minecraft become one of the best selling video games of all time, inspiring thousands of hacks, mods, and projects. This week’s Hacklet highlights some of the best Minecraft projects on Hackaday.io!

We start with [Toulon] and his MineCraft Sidecar Keypad. The Mystify Claw was originally designed as an alternative input device for First Person Shooter (FPS) games. It may look like a mouse, but the claw has no balls or lasers. It provides a 10 button “cradle” for the left hand. Some folks liked the claw, but for many it quickly became a dust collector. [Toulon] resurrected this old input device as an awesome Minecraft controller. He started by yanking all the old electronics, replacing the claw’s brain with the Teensy 2.0, a favorite of keyboard hackers everywhere. New buttons and a slew of new Teensy code made things perfect for mining.

Next up is [Thomas] and his Raspberry Minecraft Server. The Raspberry Pi has long been a hacking platform for Minecraft. The official Raspberry Pi edition of Minecraft is easy to get running, and great for hours of fun. You can also run a Minecraft server on the Pi, which is exactly what [Thomas] is doing. He’s set his Raspberry Pi up with a WiFi dongle and a battery pack. With a bit of configuration, this allows the Pi to become the center of a wireless Lan party. On batteries, the Pi will run for about five hours of continuous gaming. Details for [Thomas’] project are a bit light right now, but that’s only because he just literally started documenting and uploading his project as we’re going to press. Give him a few days and he’ll have everything filled in!

[GPPK] brings a bit of Minecraft into the real world with Full Size Wireless Redstone Lamp. Inspired by smaller models of the Minecraft redstone lamp, [GPPK] decided to build a life-sized version. “Life-sized” in this case is about 1 cubic meter. That’s a BIG lamp! [GPPK] designed the shell of the lamp in Sketchup, and cut the sides out using a gantry style CNC machine. The structure will be held together with 3D printed connectors, while a Raspberry Pi will provide the brains. Turning the lamp on will be as simple as turning on a switch in-game in Minecraft. [GPPK] has been a bit slow lately with updates on the project. If you know [GPPK] let ’em know that we’re anxiously awaiting some info!

Finally, we have [Simon] and Raspberry Pi Python Controller. One of the best ways to get kids hooked on hacking and electronics is to show them how simple circuits can lead to big changes. What better way to do that than wiring up a simple push button controller for Minecraft? [Simon] used an Arduino paired to a Raspberry Pi with a serial over USB connection. Buttons wired to the Arduino are sent through the serial link to the Pi, where a python script fires off actions based on the serial data. [Simon] has tested his script with Mincraft Pi Edition, and is happy to report back that it works great.

Do you know what’s missing from this Hacklet? Your Minecraft project! It’s not too late though – upload your info to Hackaday.io, and we might just add it to our brand new Minecraft Projects List!

Well, it’s just about quitting time here in the Hackaday Mine. As long as the creepers don’t get us, we’ll be back next week. Same hack time, same hack channel, bringing you the best of Hackaday.io!

Ask Hackaday: Understanding The X86 Memory Addressing System

February 3, 2015 by Will Sweatman 65 Comments

A quick look at the pinouts of an Intel 8086 & 8088 processor reveals a 20 bit address bus. There was high demand for the ability to address 1 meg (2^20) of address space, and Intel delivered. However, a curious individual would wonder how they can achieve such a feat with only 16 bit registers. Intel solved this riddle by combining two registers so they could make it compatible with code written for the 8008, 8080 & 8085. The process they use can be a bit confusing when trying to figure out where to locate your code in the ROM. In this article, we are going to go over the basics of how the Physical Address is calculated and how to locate your code correctly in ROM.

Continue reading “Ask Hackaday: Understanding The X86 Memory Addressing System” →

Retrotechtacular: ⋅⋅⋅⋅ ––– ⋅–– – ––– –– ––– ⋅–⋅ ⋅⋅⋅ ⋅ –⋅–⋅ ––– –⋅⋅ ⋅

February 3, 2015 by Kristina Panos 12 Comments

There’s a lot to learn from this 1966 Army training film about the International Morse Code, but the most crucial component of good keying is rhythm. A young man named [Owens] demonstrates very clean keying, and the instructor points out that skill is the product of sending uniform and short dits, uniform and short dahs, and correct spacing between dits, dahs, letters, and words.

Throughout the film, there are title cards in a typeface that shows the stroke order of military printing. The instructor points this out after a brief interlude about the phonetic alphabet (Alpha, Bravo, Charlie, &c). Right away, we see that the Morse Code for ‘H’ is four dits that gallop with the rhythm of a horse in a hurry to get to the hotel.

Such clever and memorable pictures are painted for a few other letters. We wish he would have covered them all, but that’s not the aim of this film. The Army is more concerned with good, clean rhythm and proper spacing that marks the difference between ‘low’ planes and ‘enemy’ planes. There’s a simple, three-step plan to getting what is called a ‘good fist’, and the Army demonstrates this in the best possible way: a giant J-38 and fake hand descending from the ceiling to match. Yes, really.

The first step is to adjust the key to ensure good contact alignment, proper gap spacing, and ideal spring tension. The second step is to develop good technique by resting one’s elbow on the table and holding the key rather than slapping it. The third step is simply to practice. Learning through imitation is helpful, as is taping one’s practice sessions and playing them back. [Owens] likes to use an RD-60 code recorder, which immortalizes his signals in ink.

Continue reading “Retrotechtacular: ⋅⋅⋅⋅ ––– ⋅–– – ––– –– ––– ⋅–⋅ ⋅⋅⋅ ⋅ –⋅–⋅ ––– –⋅⋅ ⋅” →