I'm extremely proud to say that my writing is featured in the current issue of Metal Additive Manufacturing Magazine. The article summarizes much of my work over the past two years, and includes many of my thoughts about how the industry can be better in the future. You can read the full article here.
Thanks so much to Nick Williams and the rest of the Metal AM for asking me to contribute!
Note: As before, thanks to Bradley Rothenberg (of nTopology) and Ryan Schmidt (of MeshMixer/Autodesk) for their continued help on this workflow.
As documented previously (1, 2, 3, 4), I've been working on a multi-step workflow to create printable lattice structures for mechanical parts. In earlier posts, I described some of the techniques I used to generate the lattice itself, and at this point I'm ready to refine the mechanical features and evaluate the end result.
I've made a few changes to my remeshed surfaces since my last post, so I start this process today in MeshMixer. Here I've got three parts: The stem body itself, a surface that's designed to reinforce the threaded portions of the faceplate bolt holes (this is mostly hidden inside the stem body, but you can see its border still), and the faceplate itself.
From this, I export three separate OBJ files and import the into nTopology Element. There, I generate simple surface lattices: each edge in the OBJ is turned into a beam in the new lattices.
Next, I create a set of attractors that I'll use to control the thickness of my lattice. The locations of these attractors were taken directly from Inventor; I know the XYZ locations of the general areas that I want to thicken, and so put the attractors right where I want them. Then I control each attractor's size and falloff curve to thicken just the areas I want. In the shots below I have every attractor on a cosine falloff; the bolt attractors are 12mm in size, and the clamp cylinder attractors are just a few mm bigger than the diameter of the cylinder.
Once I've got the attractors set up, I go through each part and thicken the lattice. The grey appearance is just where nTopology is showing me a wireframe, and the density of the mesh is really high:
You can see here that each part has some degree of variation in its beam sizes. In the bolt areas the mesh is dense and the beams are thick; in the middle of the stem body the mesh is sparse and the beams are thin.
At this point, I export each of the three lattices and bring them back into MeshMixer. Here you can see them overlaid on the original meshes:
Now, I import meshes that correspond with the mechanical features I want to preserve in the part. I've taken these directly from Inventor: I created an assembly file containing the original IPT and then created a new IPT that refers directly to the mechanical features. I export that as an STL, bring it into MeshMixer, and then select it and flip all of its normals so that it's inside out. Here you can see those boolean parts - first as red bodies in Inventor, then as meshes in MeshMixer, then as inside-out meshes:
Now I select the three lattice objects, combine them into one, and run the inspector tool and fix all of the mesh problems. Then I run "Make Solid" on the whole object. I run this in "Accurate" mode and turn the "Solid Accuracy" and "Mesh Density" settings *way* up in order to keep the whole thing smooth:
Now I've got a single lattice object that's fully solid and ready to have its mechanical features taken back out. Pretty rad. I combine the lattice and the mechanical features into one object and run "Make Solid" again, again at high density and accuracy:
I select the result, run the Inspector tool, and fix any errors. Then I look around the lattice and evaluate it. Inevitably there are a bunch of areas that are cut off, thin, or chunky - places where the lattice was thin once the mechanical features were removed, and the meshing operation rounded over the resulting isthmus. Unfortunately, that's not something that I can go back and fix; I need to move individual nodes back in my original lattice in MeshMixer. But at least I know that now, and going back through the workflow actually isn't as painful as it sounds. And anyway, the part that I have now is actually pretty good:
I should note here that I got a *lot* of help on the Boolean operations from Ryan Schmidt. Ryan also recorded a full video showing how to reintroduce the mechanical features even if you didn't have the ability to create them in Inventor. Although I went a slightly different route, there's a lot here that's super useful - and it shows the really powerful features that are built into MeshMixer:
Now that I've gone through the full process from start to finish, I see a few aspects of my design that still need some work. I also know that I still need to reduce the number of overhanging features in my design (which will probably be built on its end, with the handlebar side up). I'm also excited to test out the lattice utilities that are built into the most recent build of nTopology Element - especially in the area where the handlebar bolt reinforcements interface with the rest of the stem body. Bradley describes the process here:
I also, for what it's worth, need to do some actual FEA on my part. But by focusing on a repeatable workflow for even designing parts like this - and keeping a mind towards some basic manufacturability constraints - I've got something here that shows some promise. More soon :)
Note: Below, I use the term "DMLS" to refer to laser metal powder bed fusion. Some will have issues with this usage; I encourage readers to ignore the (possibly trademarked) terms themselves and focus on the information contained within them.
Over the past few months I've spent a lot of time trying to determine whether DMLS or EBM would be a more suitable technology for the titanium bike parts I'm working on. Early on (in my collaborations with DRT and Layerwise) I focused on DMLS, and more recently I've worked with Addaero on EBM. These two technologies are in many ways complementary, and in truth I expect to work with both of them - but their design constraints and total manufacturing process chain are a bit different, and I wanted to spend some time understanding how that will affect the cost and quality of the parts I'm working on.
In the video below, I show some of the basic differences in surface quality and support structures. Of course there are many other factors that are worth exploration, starting with minimum feature size and built-in stress, probably; I'll get to those in future updates.
Incidentally, I'm *really* interested to see the differences between DMLS and EBM in printing the lattice structures I've been working on. More soon :)
The other day I got a nice email from Xavier Alexandre, which included a few good questions about my update from last week. His questions are here, along with my answers:
XA: It isn't entirely clear for me what guides your remeshing from a mechanical/strength optimization point of view. I get that you are trying to optimize for stiffness so you're trying to maximize the stem virtual hull volume. But this global shape is set at the beginning of your workflow in Inventor. Then you're trying to have an higher lattice density around the mechanical features but how did you set on edges length or thickness. Is it based on gut feeling? If so, do you feel that there will still be a lot of room for weight/mechanical properties optimization?
Yeah - you could definitely call my process "emergent." I know that my minimum practical beam size is going to be something greater than .6mm (the exact number is unclear and will require testing). I know that I want to minimize overhanging features, and that it'll probably be appealing (from a cost perspective) to build the main stem body on its end, so that I can pack more of them into a build plate. I also know that the clamp areas will need some significant surface area in order to not, for instance, damage a carbon fiber part that they might be clamped to. I also know that the threaded bolt holes (which will be M4, but which Inventor exports as 3.2mm diameter smooth holes) will need a minimum wall thickness of about 1mm, and will really want more than that. And I know that the heads of the bolts will similarly need a bearing surface of about 1mm, and that both the bearing surface and the threaded hole will need to be reinforced back to the rest of the structure in order to distribute the clamping load on the part.
In short: Yeah, it's mostly gut at the moment. But to be honest the biggest constraint right now is manufacturability; I need the lattice to be oriented so that it won't require support structures *everywhere*, and am focusing mostly on that at the moment. Once I've got that (and basic mass distribution in areas that I *know* will need it, e.g. bolt holes) mostly solved, then I'll move on to FEA. nTopology Element has an FEA solver built in, and you can feed the results back into the design so that overstressed areas get reinforced. I'm definitely excited to get there, but for now I'm focusing on making something that a job shop will be willing to make in the first place :)
XA: I didn't get the part with the interior Oct-Tet volume lattice at all. Is it gonna be merged with the exterior lattice? A lot of these beams will be surprisingly useful once the whole part is put together Huh?
Exactly - the volume lattice (which is an oct-tet topology - see this paper for a better description than I could ever give you) will be booleaned with the surface lattices to create one structure. If you look at that volume lattice on its own, you'll notice that there are some stray beams that don't appear to be doing anything - they stick out into the middle of nowhere, and don't appear to be taking any load. But when you merge the volume with the surfaces, the situation changes, and those beams might be more useful than you would have thought.
As it happens, I've been focusing more and more on surface lattices in the past few days, as they're a bit easier to control explicitly - and the changes that I make are easier to immediately grasp the effects of. The "generate multiple individual lattices and then merge them at the end" workflow really isn't optimal for this reason: it takes way too long to understand what the finished structure will work like.
XA: You won't have skins in your design. I guess that for the stem to fit handlebars and steerer tubes you'll need the contacting beams to match the tubes curvature. Did you plan to design the beam shape for this or is it something you'll let for post processing. If so, do you plan to make those beams sturdier to account for grinding?
I'd *love* to bend the beams around the clamp area, actually. Right now I don't have a convenient way of doing that, but I'm looking into it. Either way I'll boolean out the clamp regions before printing, so I shouldn't need to grind away much.
As you might expect, my thoughts on this workflow are changing as I use it more. It's a rather finicky process, and I'm eager to industrialize it a bit - and improve the areas that are most difficult to reproduce.
More soon!
The other day, the New York Infrastructure Observatory took a tour of the MTA's Coney Island Yards. I had heard that the Coney Island Yards were *the* thing to see in the MTA's vast array of locations and properties, and was thrilled that they were able to accommodate us.
You can read more about the Coney Island Complex in the tour announcement email, and sign up to learn about upcoming tours here.
Note: Most of the photos below have descriptions, which you can see if you click on them :)
Thanks again to the MTA for hosting us!
This past August, I visited Tsue Chong Co, a noodle and fortune cookie factory in Seattle. Most of this is pretty self explanatory, but I figured it was worth posting on a Friday for fun :)
They had two methods of making fortune cookies. Here's the older machine:
And here's the newer, modern machine:
They also made rice noodles. The process is a little hard to see here but it's basically a big steamer that congeals the rice slurry as it is fed through the machine:
And a few photos of the rest of the shop, including their wheat noodle production process:
Manufacturing, huh? Happy Friday :)
Note: Special thanks to Bradley Rothenberg (of nTopology) and Ryan Schmidt (of MeshMixer/Autodesk) for their continued help on this workflow. Also, both of them make awesome (and very weird ;) software that you should check out.
A scenario: You've got a part that you want to manufacture with metal powder bed fusion. You've got a few mechanical features that you know you need (to mate up with other parts in an assembly) and a general sense of the design space that's available for the part you're designing. You know the mechanical properties you need (via an ISO test that the part needs to pass) and you've got a target mass (which is basically "less than the competition"), and a target cost (which is basically "similar to the competition, taking into account a ~35% margin for me").
I've spent a lot of the past week going back and forth between Inventor, MeshMixer, and nTopology Element, trying to make a 3D lattice structures that are both mechanically effective and easy to manufacture. My workflow has been decidedly emergent, and it's also been counterintuitive at times; I've often found myself working backwards (away from my final design intent) in order to create the conditions where I can make progress down the line. My end goal is to design a bike stem that's sub 125g and which has minimal post-processing costs and requires minimal support structures (I'll deal with the actual dollar cost later, as it'll depend on a bunch of factors that aren't under my direct control).
I've got 27.7 cubic centimeters of titanium to play with. Where do I put it?
I began in Inventor. Setting up a design space is, counterintuitively, kind of a hard thing to do. Very few parts that I've designed have hard and fast design space boundaries; most of them could always be a little bigger, or a little smaller, and the rest of the assembly would stretch or squish to accommodate it. Nevertheless, I need to start somewhere, so I created a T-spline form that was close to what I thought I'd want:
I export it as an STL at low resolution (where we're going, resolution doesn't matter :) and bring it into MeshMixer:
From here, things start to get complicated. The way I see it, this part essentially has three components:
For this design, I'm using lattice structures throughout the part. I won't design any skins (I'm generally anti-skin, unless you've got fluid separation requirements in your design), instead opting to let the lattices vary in density from zero (in the middle of the part) to 100% (in areas like the threaded and counterbored bolt holes).
Because the different surface regions of the part (the mechanical features and the exterior surface) will have different mechanical requirements, I begin by duplicating my lattice in MeshMixer and isolating each of them in its own object:
I then go through each region and remesh it in MeshMixer. A few notes here:
I DON'T worry about geometric accuracy much during this process; I assume that I'll need to clean up the geometry at the end (after I've generated the full lattice structure - more on this in a future post) anyway.
Then I export the lattices as OBJs, bring them into nTopology Element, and see what they look like:
At this point, I decided that I really wanted to stretch the entire exterior lattice out so that more of the beams would be horizontal. The part will probably be built on its end, so these will be easier to build as a result. So I go back into MeshMixer, transform the part down (it happens to be the Z axis here) by 50%, and remesh the outer skin. Then I transform it back up to 100%, stretching everything out.
As you can see in the last few shots, the lattice has been stretched significantly. I've also remeshed a few of the higher resolution areas individually, evening them out a bit. Back in nTopology Element, you can see the difference between the old lattice (the last shot below) and the new one:
Meanwhile, I've used nTopology element to create (and warp) an Oct-Tet volume lattice for the interior of the part. This may look odd (and to be sure it needs some work) but a lot of these beams will be surprisingly useful once the whole part is put together. The red stuff here is a zero-thickness representation of the mechanical features' lattice structures; the white/yellow structure is the volume lattice:
When you put the whole thing together, it starts looking pretty good:
Now, there's still a lot wrong with this. There are a *lot* of overhanging faces. The threaded bolt holes aren't very well connected to the outer mesh, and there's probably too much material on all of the flat faces (where the slits/slots are). I'm also over my mass target - my total is 34.1 cubic centimeters, and my target was 27.7.
But there's a lot right with the design, too. My beams are about the right size throughout, and I've been able to (more or less) distribute my mass where it will matter most. And while the aesthetics of the part aren't exactly what I'd like them to be, they're not far off either.
So, a few things I need to work on:
Clearly, there's a lot to do here still. But I'm beginning to get the hang of this workflow, and hoping to have some printable (and extremely lightweight) designs to make soon :)
From the end of the day yesterday:
This is still not manufacturable, and is still missing all the mechanical features too. But it's getting there! By combining a skin lattice (which my part definitely needs in at least some regions, for instance the clamp faces) and a minimal, bonelike volume lattice, I hope to be able to create something that's significantly lighter than a comparable tube-to-tube (e.g. welded) structure.
The next step, I think, is to reintroduce the mechanical features (at least some of them) into the model *before* I remesh the surfaces. I would really want the mesh density to be created relative to the kinds and intensities of the forces that the part is going to be under: for instance, all of the bolts and clamp faces will want higher density meshes around them, etc. At the moment my best bet is to do that manually, by selecting areas I want to be at higher densities and just remeshing them to suit my intuition.
More soon :)
I get the feeling I'll be doing a *lot* of this in the coming month:
Here I've taken an STL from Inventor and brought it into MeshMixer, where I'm remeshing the outside skin. I'm doing this so that I can then create a surface (as opposed to a volume) lattice in nTopology Element. If I tried to create the mesh directly from Inventor's STL, it would be much to fine and have a bunch of artifacts from the way that Inventor processes T-Spline surfaces (Inventor breaks the surface up into panels, and then subdivides each one individually - you can see the panel boundaries in the beginning of the gif), and would also be *way* too fine to be used as a scaffold for a surface lattice. By remeshing at a lower resolution - and playing with MeshMixer's remeshing settings a bit - I can get to a topology that's way better.
The design that I'm pointing towards here still isn't manufacturable - and is missing a bunch of mechanical features that the end part will need too - but it's starting to come together a lot better:
Special thanks to Ryan Schmidt (of Autodesk/Meshmixer) and Bradley Rothenberg (of nTopology) for pointing me in this direction - and for helping me out with the even cooler stuff I hope to do in the next week :)
Ada and I got back from our honeymoon on Wednesday evening. It was really great to unplug a bit over the past month (aside from the first few days of October, I really haven't worked much this month), and between yesterday and today I'm spending a little time reprioritizing the backlog I was chewing through in September. Here are the things I'm focusing on in the next few weeks:
I'm also thinking about a few longer term things:
More on all of this soon.
My weekly manufacturing newsletter, The Prepared, has grown significantly in the last few months. I had more signups in August than any month before, and I've been proud to recognize more and more of my subscribers for having done work that I've admired in in the past.
As it's matured, I've gotten a bit better about knowing what I - and my subscribers - want from it. Here are a few guidelines I use currently:
Be focused. While I might fancy myself capable of commenting intelligently on a wide range of topics, the fact of the matter is that while people will appreciate the "manufacturing guy comments on other random subject" link, they won't love the "random guy comments on whatever he wants" link.
Have a voice. I'm with Joe Biden on this: No matter how well it pays, I don't want a job that doesn't allow me to be me.
Be pithy. I tend to pontificate, but this is a weekly email. Try to keep it short.
Be warm. I tend to be skeptical of things I don't have personal experience, but the point of the newsletter is to connect people with interesting stuff. Where appropriate, show a little enthusiasm :)
Differentiate yourself. I subscribe to a few great newsletters (check out Jon Russell's, Reilly Brennan's, Alexis Madrigal's, and Benedict Evans's), and will definitely repost stuff that those guys share. But ultimately it's good for me to have my own niche, and defining myself in opposition to them helps make The Prepared better and more useful to my subscribers.
Don't stress the format. The categories are useful for organization, but they really don't matter that much.
Attribute links where it makes sense. This is a tricky one, especially because my workflow (which is 90% Pocket, 10% IFTTT+Gmail) doesn't make it easy for me to remember who sent me what. As a result this ends up being mostly driven by practical constraints, like whether or not the person who sent it could use a shout out, and whether or not they have a web presence that I can link to, and how well publicized the thing they sent me was. Not exactly a science, but I try.
This is a weekly email, but the actual day I send it out doesn't really matter. Some people may feel differently, but my rule is that I need to send it "sometime in the weekend," and I define "weekend" liberally.
This has been a long time coming.
For what it's worth, I had the idea before either Triple Bottom Line or Bastion launched - but I'm fully aware that that doesn't buy me shit. At its core: build titanium 3D printed bike frame components, and use carbon fiber tubing for areas that are too big to practically print. This avoids the crazy crowded build chamber (and inefficient glue joints) that Renishaw/Empire's bike required, and utilizes AM for what it's good at - making customizable, low-mass parts that fit easily on a build plate.
I thought about this for a *long* time, but only this week spent some time modeling my design spaces in Inventor and poking at the lattice generation process in nTopology Element. This is still far from manufacturable, but it was great to spend a day working through how to design and customize each design space in a way that was repeatable and simple.
In short, the frame would have four (or possibly three, if I integrate the brake bridge into the seat lug) printed titanium components; the rest is carbon fiber tubing. I'll likely also add a printed seatmast topper (probably with integrated saddle rails).
I spent a *tiny* amount of time setting up lattices for each printed component in nTopology Element today. This is extremely preliminary, but I really like the look and think that the basic idea - that the printed components are optimized for lattice shape and thickness, but in general never reach 100% density - is a good one.
You can *bet* that I'll be working on this more in the next week. Stay tuned :)
Something I've been thinking about a lot:
Recently I've heard more and more about design optimization in the context of metal 3D printing. "It's this amazing opportunity," the line goes. "Using the power of generative design tools and the freedom that additive manufacturing provides, we can finally design directly for functional intent - and create more functional and efficient products as a result."
Let's think about this.
Anyone I've had beers with recently will confirm: this is a *big* issue for me. Again and again, I hear otherwise thoughtful and intelligent people talking about how, with 3D printing, "complexity is free." This is an absurd statement, and here's why.
Widely accepted definitions for complexity are elusive, but I think it's fair to say that it's related to the number of variables that need to be understood in order to accurately - and precisely - represent a system. In manufacturing, complexity correlates (and I'd argue the relationship is causal) with the number of processes required to produce a product. It's also assumed that the more complex a system is, the more processing power (whether by silicon or by meat) is needed in order to design the process chain that'll most efficiently and effectively produce it.
In subtractive manufacturing, any feature that's not a block of material is complex. That includes things like holes, threads, and bosses. It also includes high resolution (polished/ground) surfaces, complex (non Euclidian) geometries, and irregular 3D patterns.
Many of these features are trivial to create by additive manufacturing. 3D lattice structures and compound curvature are a pain in the ass to mill out of a solid block, but in many cases they can be printed with little effort at all. This capability of 3D printing is - and this isn't hyperbole here - truly wonderful, and has no doubt spurred remarkable design innovation in the past few years.
But that has nothing to do with the overall complexity of the design rules that apply to additive manufacturing. For instance: 3D printing is notably subject to interactions with gravity; overhanging faces are, with many technologies, extremely "complex" to produce. Surface finish is a constant issue, requiring huge efforts in both actual post-processing time AND the intellectual effort required to develop a cost effective and logistically simple supply chain for the finished part. And the crystalline and thermal interactions occurring within metal AM are, to a great extent, barely understood at all - while with subtractive, the process is repeatable and mature.
These variables - things like surface finish, orientation to the build plate, and metallurgy - make additive manufacturing immensely complex. Anyone who tells you otherwise is pulling your leg.
What these people mean to say, I think, is that the design rules for additive manufacturing are drastically different from the design rules for subtractive & formative manufacturing. Which they absolutely are. And, to be totally clear, this is part of what I love about AM - the chance to rethink the basic assumptions that I've always taken towards conventional product development. But it's *not* a reduction in manufacturing or design complexity - and I think the sales pitch for additive is hurt when these two things are conflated.
Here, I'd like to use an analogy:
Adobe Photoshop is a tool for creating visual designs for humans to look at.
Photoshop has a number of features, but the end result of all of them is to change the colors of the pixels on your screen. Each of those pixels has a brightness and a hue, and hue boils down to the wavelength of the light that each pixel is emitting. Human eyes, meanwhile, respond to light with wavelengths from about 390 to 700 nm.
There are some exceptions, but we're pretty good at engineering computer monitors so that they produce light within the visible spectrum. When I go into Photoshop and draw a line, it'll let me color that line in red, or purple, or anywhere in between. There are some cases where the palette falls short, but in general it's able to produce every color that I'd ever want to see - and none that I can't. If you ask a graphic designer to draw an ultraviolet or infrared line in Photoshop, they'll look at you like you're crazy.
3D design tools don't act this way at all; they're totally happy letting me create designs that are utterly impossible to make in the physical world.
Now I recognize that this comparison isn't totally fair. Human eyesight is relatively well understood, whereas we know remarkably little about what *really* happens as we melt, form, and cut metal parts. But the fact remains: 3D design tools just aren't concerned with whether our designs are shit or shinola. And so when we ask them to "optimize" those designs, they give us exactly what we've asked them for.
I'd guess that this is a result (at least partly) of the traditional divide between CAD and CAM. These systems were developed by different companies and in service of different customer objectives, and in the end we've been left with a system that encodes - and then promptly decodes - our design intent in a distinctly disjointed way.
Additive manufacturing hasn't solved this source of complexity; nor, to my knowledge, has it exacerbated it. It remains with us today, and screams out to me:
Until manufacturing constraints are quantified early on in the design process, any "design optimization" that's done will be inherently inefficient - and those inefficiencies will then be repeated by separate DFM/CAM software.
This is a massive barrier in the industry today, and I know that some of the best people in both software and manufacturing are working on it as I write this. If you're one of them, or if you have experiences similar to mine, let me know - I'd love to collaborate.
For context, read Ben Einstein's very smart post, "The Real Reason Why Quirky Failed."
Quirky had two classes of customer.
As Ben describes, Quirky sold pieces of hardware to one class of customer. I was one of them - I bought a few of their products (and generally disliked them) a few years back. And as Ben accurately noted, those products were often poorly supported and maintained. Which sucked for those customers.
But Quirky also sold a second product, in the form of product execution services & royalties. The customers of this product were people with ideas, and those customers "paid" Quirky by giving them the right to develop, manufacture, and distribute those ideas.
I believe that Quirky's key failing was that that second product never got market fit. In other words: As a person with an idea for a hardware product, it just never made sense to give up the rights to that idea in exchange for product execution services & royalties.
I bring a few pieces of supporting evidence for this claim:
I believe that this - exchanging ideas for execution and royalties - was Quirky's primary product. They were, to be sure, very proud of that fact: Kaufman repeatedly said things like "The mission of what we do is to make invention accessible to people all around the world." Nothing about the best coffee maker, or air conditioner, or flashlight: Quirky's primary product was invention services, and they would live or die based on the extent to which they convinced people to give them good ideas. But they failed to iterate on this product, and it never attained product-market-fit. And so no matter how successful their [insert consumer product here] was, that disconnect would ultimately have killed them regardless.
I *really* like bets. Not that I'm a gambler; I just like the idea that strong feelings be backed up by dollars on the table (note: this is related to my distrust of focus groups & user feedback in general). One of my favorite recent bets is Felix Salmon vs. Ben Horowitz on Bitcoin, and I'm always on the lookout for things I feel strongly enough to place a stake on.
Well last week, that chance arose. I was having coffee with Andre Wegner, and (as is our wont) we got to talking about the prospects for simulation of physical systems. I've been playing more and more with design optimization (and therefore FEA) software, and have increasingly felt that design automation is impractical, and will develop slowly (if at all). Andre is a technological optimist; he believes that an increasingly large amount of our design, testing, and optimization will be done virtually.
A concrete example arose: Andre believes that the field of computational fluid dynamics will progress quickly enough to make wind tunnels obsolete within our lifetime. I believe it won't.
So, the bet:
If, in ten years (2025.09.18), wind tunnels are "still a thing," Andre owes me dinner. If they aren't, I owe him dinner.
I'm looking forward to this.
Just posting some long overdue drawings of my seatpost assembly. More on this part soon.
Yesterday I went up to visit Rich, Dave, and Cesar at Addaero, and came home with a few new EBM prints. These are an iteration on the parts they printed me a few months back, and should be easier to post-process (and are lighter to boot :).
I'm working on getting a better understanding of the differences in manufacturing process chain in DMLS and EBM (a life-cycle assessment of sorts), and one big difference ultimately will be surface finish treatments. As a result, I'll be sending these parts off to a few special places to get some very special surface treatments applied to them - and then will send them to EFBE for testing. It's likely that different treatments will result in different mechanical properties, and they'll definitely result in different cost structures as well. Stay tuned for updates :)
There are a lot of reasons to run a Kickstarter campaign. It can provide a relatively low-risk way to get market validation; it can be a non-dilutive way to cover startup costs; it can be a good way to quickly reach a large number of customers.
But notes like this - man, they're hard to beat:
Over the past month I've mentioned my college major more and more in conversations about why I'm drawn to metal additive manufacturing. "Aside from trying to develop solutions for physical problems, I'm not an engineer," I'll say. "I studied Linguistics in college." I'm probably not the best judge of my intentions here, but I suspect I use this fact partly to highlight the authenticity of my enthusiasm (I've clearly selected this out as a topic of interest), and partly to set myself up as a Man From Mars. But in doing so, I end up downplaying what is an interesting thread in my career path - the desire to organize and understand data in ways that make it easier to do stuff.
I ended up in my first ling class - Syntax 1 - on a whim. I had a rather insufferable tendency to take random classes in college, most of which I'd skate through with curiosity but not a ton of drive. But Syntax was different. Where the philosophy classes I had taken were mostly concerned with arguing over opinions, and everything else seemed focused on teaching me facts, Syntax was about reasoning, pattern matching, and experiment design. Better yet, the data set at hand is literally infinite, and is accessible just by thinking up new sentences and comparing them with gibberish. I would spend hours doing this in my head: figuring out what the key variables to test a theory were, and then thinking up sentences that tested them. It was very compelling work.
Meanwhile, I had fallen in love with building things in the physical world. I was heavily involved in running a small bike shop during college, and took welding classes on the weekends. And when the opportunity arose to take time off school to run a small construction project for my parents, I jumped at it. Executing physical things - making the world more suitable for someone's needs - became a big part of my life, and when I finished my major I took on another, much larger, construction project.
Throughout my career (first in construction, then in manufacturing and product development), I've grappled with the uncertainty that the physical world brings. In linguistics (much like computer science) there's a high correlation between theory and practice. That's not to say that those fields are any easier to navigate - each presents more than its share of big challenges. But in the physical world there is a fundamental conflict between the accuracy and the resolution of what we can measure, and our ability to synthesize models for how things work is constrained by this. And even if we could overcome these fundamental uncertainties, a lot of the time you just get soot on the imaging system, and the whole experiment is rendered useless.
Somewhat separately, I've grappled with the toolchain used to coordinate physical projects. My first real experience with this was finding a decent plumber, but the same sense has followed me through manufacturing procurement, new product development, and small parts storage systems. The structures of the manufacturing and construction industries are idiosyncratic and not at all self-similar. Moreover, they turn over less quickly than those in linguistics (the study of language, not the language itself) and software development, where entire new paradigms can be developed and implemented in a matter of months.
Today, additive manufacturing is right in the overlap in the Venn diagram of "subject to physical uncertainty" and "has a really disjointed toolchain." And the more I learn about the technology and the industry, the more it seems like the ideal place to witness - and have a meaningful impact in shaping - a new era for how human systems affect the physical world.
Of course it is key that people want the (purported) benefits that I hope metal AM will bring in this next few years. The work at hand, then, is to find applications where the value of AM is great enough to be commercially viable now - and then adjust their systems of production to fit the need. In other words: First, find what the pain points are in bringing 3D printed consumer products to market. Then, identify and organize the data flow in order to avoid & solve those pain points.
Of course, additive is just one of many sub-industries that I'd look forward to seeing the streamlined, integrated versions of. I still want a better way of finding a plumber, and I still want better ways of communicating what I want to him, and I still want more effective and efficient systems for him to organize his small parts inventory. Some of my favorite people are out there working on those problems right now, and I take every opportunity I can to help them along in some way. Because I see in them the same desire that I have: to organize data about the physical world in ways that make it easier for us to do good things there.
Hence, my desire to better understand physical urban infrastructure; my desire to help both Amazon and McMaster-Carr think about the way they're approaching the digitization of industrial supply; my frustration when today's procurement platforms simply digitize an opaque process without rethinking the role they play in product development; my tendency to draw parallels between "soft" robotics (think Baxter) and the supplier validation process. In all of these cases, I see - and am excited for - a significant shift in the way that information is used to understand and improve the physical world.
In my work in metal AM to date, I have tried to uncover the existing theories - rules of thumb, essentially - that most reliably produce parts today. I'm looking forward to continuing on that path, and to working with and around the engineers, researchers, and entrepreneurs at the boundaries of theory and the physical world today.
A version of this saddle, but way cooler:
I've got a few other things going on right now, but this is one that I've been itching to do for a while. More soon :)
