Even when we share the design files for open source hardware, the step between digital files and a real-world mechatronics widget is still a big one. That’s why I set off on a personal vendetta to find ways to make that transfer step easier for newcomers to an open source mechantronics project.
Today, I want to spill the beans on one of these finds: part numbers, and showcase how they can help you share your project in a way that helps other reproduce it. Think of part numbers as being like version numbers for software, but on real objects.
I’ll showcase an example of putting part numbers to work on one of my projects, and then I’ll finish off by showing just how part numbers offer some powerful community-building aspects to your project.
A Tale Told with Jubilee
To give this idea some teeth, I put it to work on Jubilee, my open source toolchanging machine. Between October 2019 to November 2020, we’ve slowly grown the number of folks building Jubilees in the world from 1 to more than 50 chatting it up on the Discord server.
A snippet of the Jubilee fam
These days, Jubilee is still just a collection of files on the internet. Folks building one need to meticulously order everything on the bill-of-materials, 3D print all the parts, and then step through the assembly process. The whole process can take a couple months because of the extra wait for parts to ship from overseas. And in that time, the design can get a slight tweak along the way. Here lies a tricky situation for builders. As the project evolves, they need to decide how they want to evolve their build process with it. Do they take the update, or keep building the version they started with? And if they decide to adopt the updates, how do they keep track of how their machine compares against the latest project files?
In software, these might be easy answers. Just check the version of the code you’re running with a simple command line incantation! Or check the name of the file you’re executing, or the date you created it. All of these answers work great for digital files but immediately break down with real world objects. As soon as we transform that STL file into a real world part, we’re losing information. We’re are severing the link between a traceable file with metadata and a physical object it represents. So how do we keep this link? One way, is with a part number inscribed directly into the object itself. That’s the route I took for this project.
Taking a step back, one of my goals with sharing Jubilee is to try to give anyone who builds it a sense of agency over their build process. In short, over time, Jubilee’s design changes as people make it better. And as people build it, I want them to be able to make informed decisions about those changes. To make it happen, I figured it would be useful for folks to be able to identify the machine version they were building by inspecting the actual machine, not the files that created it. That’s the real drive behind part numbers: to give the builder a clear sense of where their machine stands in relationship to the project.
But First: Some Design Theory
If you’ve picked up a copy of Donald Norman’s The Design of Everyday Things, the idea of how part numbers can help really starts to make sense. In his book, which you should totally read, Norman brings up two distinct concepts, knowledge in the head, and knowledge in the world. As a user of designed things, knowledge in the head is information you need to memorize so that you can use said designed object. It’s whatever matters in the instruction manual. Knowledge in the world is also information you need to know so that you can use the object, but it’s somehow attached to the object itself, so you don’t need to memorize it. To hit this idea home, think about plugging some devices into the back of a video projector, like the one below. Which input is which?
Thankfully, the one on the top is labeled; that’s knowledge in the world. But the one on the bottom is not, it’s in the manual. That’s knowledge in the head. Which one would you rather use? While the second one looks cleaner, the first one lets me throw away the instruction manual–or not need one at all! That’s the idea with an inscribed part number. It’s knowledge in the world that lets the builder know exactly what they’re holding in their hands in a way that lets them trace it back to the file that created it.
Creating a Part Numbering Scheme
Now that we know how part numbers might help, let’s talk about applying it both to Jubilee and in general. My understanding is that folks in industry fall into two camps when it comes to part numbering schemes. Either (1) your part number is just a number that increments with every new part, or (2) your part number has structured fields that each have a specific meaning. An example of the first one is just a sequence of numbers like this: 000001. And the second might look like this: 07-BED-04-MKS-MRW.
I think there are places and cases for both; it just depends on the situation. If your part number doesn’t need to be human-readable or can be looked up quickly with a computer, a simple numeric part number makes sense. Heck, you can even encode it on a barcode stickered on the part itself to make the lookup process easier. If the scope of your part numbering scheme is ever-expanding with new categories that you can’t determine up-front, enumeration might also make sense.
But if you’re part number needs some sort of human-readable meaning, the second option might be the way to go. And it was the right fit for Jubilee. First, the project scope is well defined. We know that the machine isn’t going to have an ever-increasing number of categories. Second, and more importantly, people new to the project might need to read the part numbers.
To put together a part numbering scheme, some folks in the Jubilee community kicked off a discussion on Github. The plan was to apply the scheme to every non-off-the-shelf-part. Here, that meant every 3D-printed and machined part would get a part number embedded directly onto it. The crux of this conversation was a an open question: what meaningful information is worth encoding into the part number for other people to read? We came up with a few takeaways. For all parts, the version mattered, and having some sort of short unique “signature” to easily identify it mattered too. For machined parts, “who made it” mattered.
Besides the conversation on Github, other situations on Jubilee’s Discord server were motivating the push to identify parts, namely debugging other builders’ setups. For one, mixing parts from different versions of the machine didn’t always work, so builders with mixed batches of parts would find themselves in scenarios where the assembly instructions asked them to do something impossible.
In other cases, some folks arrived with machined parts whose manufacturing quality was causing assembly or performance issues. But without knowing where those machined parts came from or how they were made, it would take extra conversation to uncover whether any of the machining processes were responsible for the issues. In a nutshell, having any form of traceability up front would be an added bonus to shortcut a few steps in debugging someone else’s Jubilee setup.
After some back and forth, I settled on a scheme that looked like this:
[subassembly] – [part id + params] – [revision] – [fab process + material] – [who fabricated it]
with a shortened version that looked like this:
[part id + params] – [revision]
The first option was the full part number. The second was the bare minimum that needed to fit on the part somewhere. Most 3D printed parts just embed the short part number which is inset on the side of the part. Here’s a shot of what these look like in action on a handful of parts.
Finally, I should mention that part numbers for Jubilee are project-specific. A different project means a different set of part numbers (although I might reuse the same scheme). But in this situation, we just need a way to help Jubilee builders know what they’re building from, and communicate with each other in a way that’s highly specific.
Parts Made with Decentralized Manufacturing
As Jubilee’s design matured, a few machinists actually started to make small batches of parts to sell them to the growing community of builders. The result was that the design became easier to self-source since you could just buy machined parts if you couldn’t make them yourself.
With the part numbering scheme set, I reached out to these machinists asking if they’d be willing to etch part numbers on their parts and list the part number on their website. They kindly agreed. Here, each vendor gets a unique part number that’s similar except for the last few fields. Those last sections identify the part’s material and manufacturer.
So while both 713Maker and Mandala Rose Works both make aluminum bed plates, the part numbers can tell a story about what they’re made from and who made them. Second off, having a part number also serves as a “qualifier” to the new Jubilee builder. It’s an implicit promise that the parts made from these places have enough community support to merit some recognition in the form of some project identification. Finally, if any of these parts cause issues, any builder in the community can use the part number to reach out to the machinist who made the part to ask for support. This is true even if they didn’t build the machine themselves and bought one already assembled from someone else.
Printed Part Number Legibility
As far as print settings go, I found that printed part numbers were easiest to read when the text was printed on the side walls of the part. This spot makes part numbers legible even if they’re only 25 layer lines thick.
Furthermore, printing on this side seems to be fairly legible across most types of 3D printers–even budget machines like the Ender 3 Pro. While I definitely tried to print the numbers on the tops and bottoms of 3D printed parts, the small letter features simply don’t come out consistently and make the part that much harder to print across a range of machines.
Designing with Part Numbers
These days, every time I modify a part between GitHub Releases, I’ll update the part number. In practice, this is pretty easy to track. If I’m editing a part between a release, I just tick the number and re-export the STL in the preferred print orientation. The part number is stored as metadata in the model file, but if I get confused about what number I’m counting from, I can just lookup the STL from the last release. What that means is that STL files keep their names, but their contents change. This saves us from extra bookkeeping since part hyperlinks in places like the wiki don’t need to change every time the part number changes. This is also in-line with software practices. Every time we change a file, we don’t give it a new name. Version control software tracks the file’s history for us. And the same is true for design files that represent hardware if you track them with a tool like Git. Fun fact! GitHub will actually render a diff of two STL files from your commits if you dig for them.
Any time I change I part between a release, I’ll also make a note in the project’s Changelog. When a Jubilee builder encounters a new release, they can find a quick listing of all the non-stock parts that changed in some way. This is also the place to get a summary about what geometry changed on that part and why. That way they can decide for themselves if upgrading to the new part is worth the effort of reassembling part of their machine.
Communicating with Part Numbers
Remember that one part in the assembly instructions? It was that flibbity-jibbit-short-left-hand-edition–version-3?
Naming things is hard. Describing them is harder. With inscribed part numbers, communicating about the design becomes much easier. It’s easier between project builders and between builders and designers. There are two reasons for this. First, we don’t need to lookup any part names; they’re written directly on the parts themselves! That’s extremely useful when we want to have a conversation about these parts. Second, the name is highly specific and unique to that version of that part. By referring to the part with the part number, there’s no ambiguity to what we’re talking about.
The result is that some hiccups in communication just “go away.” If someone wants to talk about parts in the assembly process, they don’t have to struggle to describe them or look up their names; they just inspect them for their numbers. Second, if someone is building with versions of parts that are incompatible, we can catch it by cross-referencing them against the Changelog. And when your Discord community is over 1,000 people of various skill levels asking for help building different machine versions, eliminating any friction in communication is key to having an easier debugging experience.
Finally, what’s really special is that the part numbers are so specific that builders who aren’t the original project designers can have a conversation without needing clarification from the designer about the differences between the parts between them. That’s powerful. Adding part numbers removes the need from the designer to serve as mediator to clarify design details. The design works directly with the community instead of having it distilled from the original designer.
Part Numbers Build Community, Partly
I admit: coming up with a numbering scheme and then implementing it partway through the project was a ton of extra effort. So here’s a good question: if the machine already works for you, why go through so much extra effort to add something to the project that doesn’t directly enhance your machine? I think the answer comes down to sharing.
Speaking honestly, I don’t know how popular tool-changing machines will be in the future. But I know that designing them is hard. And, at the end of the day, I really want to see people build fun applications on top of them. But not everyone who comes to the table excited to play with them will have the time or skills to design one. So the question I try to ask myself now is: how can I take you with me?
I think part numbers are one way of doing that. They’re a way to give the whole crew of people building your project a common language to help answer questions from the new folks. They’re a way to help them identify whether a machine has issues that are design-related or related to modifications it received by its builder. And while I can’t keep up with every question new builders ask–the community can! And equipping them with a precise language is partly how we make them more capable of sustaining growth. And with more voices able to answer your build questions, you too can get yourself a working machine. So even if you can’t or don’t want to design up a nice toolchanging platform from scratch, you can still build on top of it.
I wish I could take credit for part numbers, but I can’t. Engineering teams in industry use them all the time to share and delegate complexity on big projects. What’s to stop us open source hardware hackers from borrowing some of their methods to build community?
Great–Where Do I Learn More?
And hey, don’t take my word for it. A few folks suggested part numbers to me back in the early days of Jubilee’s release. Eventually, this video also landed on the Discord server, and it really hit the argument home. Let Wintergatan take you through a fun discussion on his mission wrangling with the complexity of his machine.