Impossibilities And 3D Printing

August 29, 2020 by Elliot Williams 43 Comments

This week our own [Donald Papp] wrote a thought-provoking piece on buying and selling 3D-printer models. His basic point: if you don’t know what you’re getting until you’ve purchased it, and there’s no refund policy, how can you tell if your money is being well spent? It’s a serious problem for these nascent markets, because when customers aren’t satisfied they won’t come back.

It got me thinking about my own experience, albeit with all of the free 3D models out there. They are a supremely mixed bag, and even though you’re not paying for the model, you’re paying in printing time, filament, and effort. It pays to be choosy, and all of [Donald]’s suggestions hold in the “free” market as well.

Only download models that have been printed at least once, have decent documentation about things like layer height, filament type, and support, and to the best of your abilities, be critical about the ability to fabricate the part at all. Fused-deposition printers can only print on top of previous layers, and have a distinct grain, so you need to watch out for overhangs and print orientation. With resin printers, you need to be careful about trapped volumes of uncured resin. You want to be sure that the modeler at least took these considerations into account.

But when your parts have strength requirements, fits, and tolerances, it gets even worse. There’s almost no way a designer can know if you’re overextruding on your first layers or not. Different slicers handle corners differently, making inner surfaces shrink to varying degrees. How can the designer work around your particular situation?

My personal answer is open-source. Whenever possible, I prefer models in OpenSCAD. If you download an STL with ten M8 bolt holes, you could widen them all in a modeling program, but if you’ve got the source code, it’s as easy as changing a single variable. Using the source plays to the customizability of 3D printing, which is perhaps its strongest suit, in my mind. Nobody knows exactly how thick your desk is but you, after all. Making a headphone hook that’s customizable is key.

So even if the markets for 3D prints can solve the reliability problems, through customer reviews or requirements of extensive documentation, they’ll never be able to solve the one-size-fits-nobody issue. Open source fixes this easily. Sell me the source, not the STL!

Write In PipelineC For FPGAs

August 16, 2020 by Elliot Williams 15 Comments

The best thing about field-programmable gate arrays (FPGAs), when you have a massively parallel application, is that everything runs in parallel. The worst thing about FPGAs, when you need a lot of stuff to happen in sequence, is that everything runs in parallel. If you have a multi-step computation, for example, you need to break it up into chunks, figure out the timing between them, and make sure that each chunk clears before it is fed new data. This is pipelining, and taking care of all the low-level details yourself is one of the things that can sometimes make FPGA a four-letter word beginning with “F”.

[Julian Kemmerer]’s PipelineC is a C-like language that compiles down into VHDL so that you can use it in an FPGA, and it does the pipelining for you. He has examples of how you’d use it to construct a simple state machine, and after you’ve written a few hundred state machines the long way, you’ll know why this is a good idea.

PipelineC isn’t the only high level synthesis language out there, but it sits in an interesting place. It doesn’t take care of memory or define interfaces. It just takes care of pipelining. We haven’t tried it out yet, but it looks like it would be interesting for moderately complex projects, where the mechanics of pipeline signalling is a hassle, but you don’t require the deluxe treatment. Check it out, and if you like it, let us (and [Julian], natch) know.

If you want to dive head-first into pipelining, give [Al Williams]’ two-part mini-series a look.

Pipeline graphic CC BY-SA 3.0 by CBurnett

Hammer Seeks Nail

August 15, 2020 by Elliot Williams 22 Comments

People sometimes say “when you have a hammer, everything looks like a nail” as if that were a bad thing. Hitting up Wikipedia, they’re calling it the Law of the Instrument or Maslow’s Hammer and calling it a cognitive bias. But I like hammers…

I’m working on a new tool, a four-axis hot-wire foam cutter based roughly on this design, but built out of stuff in my basement so far. I want it primarily to turn out wings for RC airplanes so that I can play around with airfoils and construction methods and so on. But halfway through building this new “hammer”, I’m already getting funny ideas of other projects that could be built with it. Classic nail-seeking behavior.

And some of these thoughts are making me reconsider the design of my hammer. I originally wanted to build it low, because it’s not likely that I’ll ever want to cut wing sections taller than 50 mm or so. But as soon as cutting out giant letters to decorate my son’s room, or maybe parts for a boat hull enter my mind, that means a significantly taller cutter, with ensuing complications.

So here I am suffering simultaneously from Maslow’s Hammer and scope creep, but I’m not sad about either of these “ills”. Playing with a couple manual prototypes for the CNC hot-wire cutter has expanded my design vocabulary; I’ve thought of a couple cool projects that I simply wouldn’t have had the mental map for before. Having tools expands the possible ways you can build, cognitive bias or not.

One person’s scope creep is another’s “fully realizing the potential of a project”. I’m pretty sure that I’ll build a version two of this machine anyway, so maybe it’s not a big deal if the first draft were height-limited, but the process of thinking through the height problem has actually lead me to a better design even for the short cutter. (Tension provided by an external bow instead of born by the vertical CNC towers. I’ll write the project up when I’m done. But that’s not the point.)

Maybe instead of lamenting Maslow’s cognitive bias, we should be celebrating the other side of the same coin: that nails are tremendously useful, and that the simple fact of having a hammer can lead you to fully appreciate them, and in turn expand what you’re capable of. As for scope creep? As long as I get the project done over my vacation next week, all’s well, right?

Quick 3D-Printed Airfoils With These OpenSCAD Helpers

August 14, 2020 by Elliot Williams 7 Comments

You know how it is. You’re working on a project that needs to move air or water, or move through air or water, but your 3D design chops and/or your aerodynamics knowledge hold you back from doing the right thing? If you use OpenSCAD, you have no excuse for creating unnecessary turbulence: just click on your favorite foil and paste it right in. [Benjamin]’s web-based utility has scraped the fantastic UIUC airfoil database and does the hard work for you.

While he originally wrote the utility to make the blades for a blower for a foundry, he’s also got plans to try out some 3D printed wind turbines, and naturally has a nice collection of turbine airfoils as well.

If your needs aren’t very fancy, and you just want something with less drag, you might also consider [ErroneousBosch]’s very simple airfoil generator, also for OpenSCAD. Making a NACA-profile wing that’s 120 mm wide and 250 mm long is as simple as airfoil_simple_wing([120, 0030], wing_length=250);

If you have more elaborate needs, or want to design the foil yourself, you can always plot out the points, convert it to a DXF and extrude. Indeed, this is what we’d do if we weren’t modelling in OpenSCAD anyway. But who wants to do all that manual labor?

Between open-source simulators, modelling tools, and 3D printable parts, there’s no excuse for sub-par aerodynamics these days. If you’re going to make a wind turbine, do it right! (And sound off on your favorite aerodynamics design tools in the comments. We’re in the market.)

PIC32 DMA Is A Weird Machine

August 13, 2020 by Elliot Williams 11 Comments

Direct memory access (DMA) systems in computers are more powerful than you might think, and [Bruce Land] and [Joseph Primmer] have done some clever hacking to take full advantage of this on the PIC32 microcontrollers. This is a cool proof-of-concept hack — you can do general computing in the DMA subsystem without using the CPU at all if you don’t mind taking your time — but they also include two useful examples: a direct digital synthesis machine and a random number generator. Both of these run using exactly 0% CPU time.

How do they do it? DMA is a mechanism for shuttling data around in memory or between hardware peripherals without involving the CPU. Say you want to take a large block of memory containing music, and spit it out slowly to an I2S audio converter. A DMA subsystem could be configured to take an interrupt from the sound chip, pass it a chunk of data, increment the data pointer, and wait for the next interrupt.

The gimmick, which goes back at least to [Rushanan] and [Checkoway]’s “Run DMA” paper, is that you can modify the memory source and destination addresses of one DMA service from another DMA service, and that some registers automatically perform mathematical operations on whatever data is put into them. Combine these together, and you’ve got transport-triggered programming.

(An awesome side-note: our own [Al Williams] developed a one-instruction transport-triggered CPU way back in the day: the One Instruction Wonder.)

What is this good for? Writing simple helper applications that run independent of the CPU on a PIC32 microcontroller. [Land] and [Primmer]’s direct-digital synthesis example is a great one. But there are a lot of cases where you simply want to take in some new data and pre-process it a little bit before it enters the main program flow. While creating weird machines in the DMA engine might be a slower way to get it done, it keeps the CPU free for doing other stuff. We’re sure you’ll come up with something.

DIY HID, OMG!

August 8, 2020 by Elliot Williams 15 Comments

William English, one of the creators of the mouse back in the 60s, passed away last week. And that got me thinking of how amazing it would have been to be in the place that was inventing what would become modern computing interfaces. What a special time! Of course, they probably had no idea.

From here, it looks like the mouse changed everything, but you have to realize that they were working in a world with light-pens, where you could actually draw on the screen. In contrast, the mouse seems positively non-futuristic. They must have known they’d come up with an improvement over the status quo, but did they know they’d created a revolution?

So where has the revolutionary spirit in DIY human interface devices gone? I’d claim it’s still alive and kicking. Indeed our own Kristina Panos has a series called “Inputs of Interest” and we’ve seen a ton of DIY keyboards of late. Then there are many varieties of dial inputs. I used to have a dedicated scroll wheel made out of a hard-drive platter, and when I was reading lots of PDFs on-screen, I have to say it earned its desk-space. Heck, we’ve even seen people make their own mouse.

But what I love about the story of the development of the mouse is that they asked the question “what is the best way to locate a point on a screen” and tried to answer it. Half of their success is probably in simply asking the right question, and the other half in prototyping something half-workable. My gut says that we don’t have inputs figured out 100% on mobile yet. This sounds like a job for Hackaday. What’s the next big human-interface design need? And have you got any crazy ideas to solve it?

Hackaday Remoticon

And this week, we announced the Hackaday Remoticon, our shelter-in-place version of the Supercon. It’s going to take place in November as usual, but online instead of IRL.

The good news? It’s going to be chock full of workshops, all streamed online and recorded for posterity. And for that we need your proposals. If you’d like to teach a group of distributed hackers learning your favorite techniques and tricks, this is your chance!

The bad news is of course that we won’t get to see you all in person. That’s going to make the 2021 Hackaday Supercon seem even more super.

COVID Tracing Apps: What Europe Has Done Right, And Wrong

August 3, 2020 by Elliot Williams 63 Comments

Europe has been in COVID-containment mode for the last month, in contrast to the prior three months of serious lockdown. Kids went back to school, in shifts, and people went on vacation to countries with similarly low infection rates. Legoland and the zoo opened back up, capped at 1/3 capacity. Hardware stores and post offices are running “normally” once you’ve accommodated mandatory masks and 1.5 meter separations while standing in line as “normal”. To make up for the fact that half of the tables have to be left empty, most restaurants have sprawled out onto their terraces. It’s not really normal, but it’s also no longer horrible.

But even a country that’s doing very well like Germany, where I live, has a few hundred to a thousand new cases per day. If these are left to spread unchecked as before, the possibility of a second wave is very real, hence the mask-and-distance routine. The various European COVID-tracing apps were rolled out with this backdrop of a looming pandemic that’s tenuously under control. While nobody expects the apps to replace public distancing, they also stand to help if they can catch new and asymptomatic cases before they get passed on.

When Google and Apple introduced their frameworks for tracing apps, I took a technical look at them. My conclusion was that the infrastructure was sound, but that the implementation details would be where all of the dragons lay in wait. Not surprisingly, I was right!

Here’s an update on what’s happened in the first month of Europe’s experience with COVID-tracing apps. The good news is that the apps seem to be well written and based on the aforementioned solid foundation. Many, many people have installed at least one of the apps, and despite some quite serious growing pains, they seem to be mostly functioning as they should. The bad news is that, due to its privacy-preserving nature, nobody knows how many people have received warnings, or what effect, if any, the app is having on the infection rate. You certainly can’t see an “app effect” in the new daily cases rate. After a month of hard coding work and extreme public goodwill, it may be that cellphone apps just aren’t the panacea some had hoped.

Continue reading “COVID Tracing Apps: What Europe Has Done Right, And Wrong” →