Manufacturing guy-at-large.

An interview with me!

Added on by Spencer Wright.

Over the past few years, I've had the growing sensation that my public life is primarily focused on being a commentator or analyst rather than a practitioner. This is largely due to my role on The Prepared, but I'm sure is also influenced by my professional priorities and the fact that ultimately, I'm interested not only in any specific trade but in the broader saga of product development and business maturation.

And so it was just a delight to be asked to appear on 100 Product Managers, and a total pleasure to be interviewed by Suzanne Abate. Our conversation spanned not only The Prepared and The Public Radio, but also my time building high end custom bikes and robot doors. Throughout, we focused not only on the products being sold but also the products being used to make them - manufacturing tools, fixtures, and software. 

For the whole interview, head over to the 100 Product Managers site. Thanks to Suzanne for having me on!

The 3MF Beamlattice extension: A better way to describe lattice geometries

Added on by Spencer Wright.

Today, the 3MF Consortium officially announced that its Beam Lattice extension has been ratified and released. And I'm proud to share that nTopology Element is the first piece of software to support it and that I (via nTopology) was a part of its development and adoption.

Brad and I first approached the 3MF Consortium about developing a lattice-specific file format almost two years ago. At the time, we had recently released nTopology's own LTCX file format, which we created and open-sourced in order to share files internally and with nTopology's early customers & research partners. LTCX is lightweight, portable, and high fidelity, and we wanted other companies in industrial 3D printing to have access to similar functionality. 

The 3MF consortium was an excellent fit for this, and late in 2016 I represented nTopology at our first 3MF meeting to discuss how LTCX could be adapted to meet the broader industry's needs.

For context: STL files have numerous well-documented issues, but they're particularly bad at representing lattice structures. STLs describe the surface of a part as a tessellated surface, which is (with large caveats) a fairly good general-purpose method of describing arbitrary geometry. But when you use STLs to describe lattices, you either end up with bad surface resolution or manifold/watertight issues, or both - and regardless, the file size is *enormous.*

The 3MF Beam Lattice extension solves this by describing lattices via their node and beam properties. This results in multiple orders of magnitude in file size reduction, while *improving* surface resolution. 3MF Beam Lattices live right alongside all of the other data that 3MF can handle: Not only meshes but materials, slices, etc. As a result, 3MF Beam Lattices are incredibly rich, and can be used for parts that comprise both lattices and solids with extremely high fidelity and portability.

Personally, the process of working on the 3MF Beam Lattice extension has been a pleasure, and I want to thank the entire 3MF Consortium for their dedication to our shared goals. In particular, Alex Oster, Scott White, Kris Iverson, Jordi Gonzalez, Mark Forsyth, Mike Facello, and Kurt Renap brought both enthusiasm and experience that was essential to the specification. I also want to commend the team at Netfabb for introducing 3MF Beam Lattice support with incredible speed, and for driving the development of the 3MF open source implementation. 

3MF has some great other projects in the works, and I can't wait to share them as well. For more information, visit the 3MF Consortium's website.

Looking for a laser marking vendor

Added on by Spencer Wright.

An open RFQ:

I am looking for a vendor who can perform laser marking services on stainless steel parts. This is a customization that we offer for The Public Radio as seen below; we purchase the laser marking in MOQs of 100+ and have an estimated total usage of 2500 this year. 

The Public Radio - Custom engraving - large.jpg

If you do laser marking or know someone who does, please get in touch here. Note, my preference is to find a supplier that's within 1 day of ground shipping from New York City. 

The Public Radio's assembly & fulfillment processes

Added on by Spencer Wright.

In preparation for our full rollout at our contract manufacturer, Worthington Assembly, I spent a bunch of time honing The Public Radio's mechanical assembly & fulfillment processes - organizing the workspace, testing each error check, scanning random shampoo bottles to make sure a weird barcode doesn't screw things up. The processes and tools we've developed will inevitably evolve yet, but at the current setup is solid.

So, video documentation!

Mechanical assembly

We begin by taking in printed circuit board assemblies and making mechanical assemblies. We typically do this in batches of 18, and once a batch is done they're scanned into inventory and put in a tray on a shelf:

Obviously, the mechanical assembly step is *not* done just in time; a mechanical assembly might sit on the shelf for a day or a week before its time comes. Then comes:

Order fulfillment

This is where the real engineering comes in. Here we have multiple systems - Tulip, our order management database, and a bunch of scripts & custom hardware to round things off.

So, two videos!

I gotta say - it's a pretty cool process :)

The Public Radio's inventory dashboard

Added on by Spencer Wright.

Every few weeks since The Public Radio went into production last summer, I've been struck with a pressing - and often urgent - need for some new and/or improved business or operations tool. One recent occurrence was particularly pressing, as we've had a few (ultimately manageable) inventory issues and are facing continually more complex logistics: We needed to know more about what parts and assemblies we had on hand at any given moment.

The Public Radio is assembled, programmed, and fulfilled from two locations: Worthington Assembly (our contract manufacturer and PCBA house in Massachusetts) and our corporate headquarters (a.k.a. my basement). The materials we use come from China (our speaker, potentiometer, and a few other electronic and mechanical components), Taiwan (our lid), a few stock component distributors in the US (our jar and a few SMT components), and a few custom US manufacturers (our box, and for radio station orders some laser marking on the lids). Some of these parts are used by Worthington to make our PCBAs; some are used to make our mechanical assembly; the rest are used to fulfill orders.

What we need to track is that conversion chain: Parts to PCB assembly, parts (and PCBA) to mechanical assembly, parts (and mechanical assembly) out the door.

For my current purposes, there are three events in this chain: Receive inventory, Create mechanical assembly, Fulfill order. (Note that I'm ignoring the components in the PCBA at this stage, and instead simply tracking the PCBA at the assembly level.) The first of these happens every few months and can be done manually, but the latter two will happen something like ten thousand times this year; it simply needs to be automated.

Luckily, our entire manufacturing process runs online. Our order database runs on Heroku, and each manufacturing cell needs internet connectivity in order to process orders. As a result, I had a perfect opportunity to build a quick and dirty cloud based inventory dashboard.

As these things go, I ended up only having a few days to build the system, and I was pretty sure that the early data would need a good amount of ad hoc massaging (i.e. I would need to use a database that could be manually edited whenever inventory needed to be reconciled). So, Google sheets it was :) 

With manual edits being sufficient for receiving (and reconciling) inventory, what I still needed was a way to record inventory events and then send them to Google. The result was two scripts:

  • The first records inventory events in a CSV that's stored locally to the event (on the manufacturing cell's Raspberry Pi). Each record contains a timestamp, the event type, and some username (either a string that's passed in as an argument or the Pi's hostname, which is unique).
  • The second script parses the CSV line by line and updates our Google sheet for each inventory event. 

Our Google spreadsheet contains many sheets: One for each inventory part/assembly, and a dashboard which sums up the current stock on hand for all parts/assemblies. As a result, our second script needs to make multiple updates for each line in the CSV. This took a bit of fiddling to get right (note: appending rows one by one is slow), but now the whole process only takes a few seconds, even with 1-200 events (which is about what one manufacturing cell can do in a day) to update.

The result is simple, but powerful: A real time (or nearly real time - the second script currently runs once a day on a cron task, as there's really no need for more granular data) dashboard showing on hand inventory of 8 different items:

 Critical levels all over the place. But also, just in time!

Critical levels all over the place. But also, just in time!

This will eventually get a few updates. The most important one is to track inventory of the two manufacturing locations (Massachusetts and Brooklyn) independently - a relatively easy task. I'll probably also create an interface for reconciling inventory, which is currently done by manually adding reconcile rows (instead it could probably be done by removing all old inventory events and adding a single "starting inventory" row). Lastly, there's a high likelihood that the work being done in the inventory scripts ends up being integrated directly into Tulip, which is already handling the vast majority of our operations.

But even without those improvements, these two simple scripts form an incredible tool. 

A year of commits

Added on by Spencer Wright.

For years - through at least my three most recent jobs - I've wanted to write more software. The desire has been vague at best, driven partly by curiosity, partly by FOMO, and partly by wanting to be more personally effective - to be able to do more stuff. My jobs have supported me in broad strokes, but in my experience real progress occurs in times of real need, and ultimately my (nonexistent) skills as a software engineer simply haven't been on anyone's critical path.

Screen Shot 2018-01-04 at 11.27.15.png

Until 2017.

2017 saw a totally new pattern of work. At nTopology, I spent much of the year building an integration between Element and Abaqus, using the workflow to optimize material use on metal 3D printed lattice structures. This laid a good baseline of commits, mostly during weekdays. 

Later in the year, as The Public Radio's operations spun up, my commit frequency jumped significantly. Some days see dozens of commits, as I pushed in-development code from my laptop onto one of the Raspberry Pis we use to fulfill orders. This is a somewhat weird process, and I'll admit that it has the effect of juking my stats. But I'll also note that a lot of these commits occurred on weekends, which feels like it should balance my credibility out a bit.

It's yet to be seen if 2018 continues this trend. I'm still no developer, and the level of complexity that I'm able to take on myself will probably remain pretty low. But it's nice to see some progress :)


Added on by Spencer Wright.

Over the past few years I've become fond of defining manufacturing as follows:

Manufacturing is just people
doing things
again and again
in a predictable way.

One of the main reasons The Public Radio exists today is that it's an effective instrument for honing our skills at manufacturing engineering & management. We've seen our volumes jump an order of magnitude a few times now, and each time our manufacturing skills have needed to evolve. But to a large extent those evolutions have been incremental, whereas upgrades to our logistics have followed a step function.

As suggested in the definition above, manufacturing is (perhaps more than most people believe) mostly about people; logistics is similar. But logistics, being transient, requires trust among parties that will never fully get to know one another - and that, by their very nature, are separated at great distances.

 Two TPR shipments make their way into the US.

Two TPR shipments make their way into the US.

Logistics also requires tools that aren't common in a shop (maps, week-of-year calendars) and is subject to delays that are often incomprehensible in their complexity (port labor disputes, weather, harmonized tariff schedules). And worse yet, logistics companies often impose strict firewalls between customer service and operations - making one's own self-eduction all the more frustrating.

That said, the magic of it - planning out a three month long production cycle and seeing it come together at the end - is remarkable. 

(He wrote, as he waited for packages to show up from around the world...)

A good, old, tool

Added on by Spencer Wright.

In early 2009 I purchased a used (and nonfunctional, at the time) Abene VHF3. It was a rite of passage: The machine was over 40 years old when I bought it, and at the time my knowledge of machine tools was tenuous at best. But I wanted the challenge, and I had decent intel that the VHF3 was a good machine, and (perhaps contrary to popular belief) the internet provides thorough documentation for even obscure machine tools. 


In retrospect, the experience was transformational. In addition to the mill itself (and in addition to the way wipers, bearings, oil, tooling, and other sundries needed to restore a machine that's probably been sitting for a decade), I purchased gallons upon gallons of kerosene. Stripping the machine down to its core components - and stripping every bit of caked up lubricant off with kerosene - took about a month, during which time I learned not only how the machine worked but also how to navigate a good portion of industry as a whole. Simply purchasing the right lubricant would require a half dozen phone calls, a purchase order, and a drive up the island to some sleepy distributor. Replacement parts aren't just unavailable; they're totally undocumented, lost in some Swedish file cabinet. 

On the other hand, this was a tool; a machine. Its complexity only went a few layers deep, and given a week or two almost any problem I came up against was tractable. And the more I worked on the mill, the more I realized that it would eventually make the things needed to improve itself.

It was a beautiful machine. It was strong, versatile, and capable of precision work. In the right hands it would have put in another century of service. But ultimately, mine were not the right hands. I sold it a few years later, and since then have not had a shop space that would support a tool of its caliber. 

I'm not sure when I'll own another tool like it. It was a treat: Empowering, challenging, terrifying at times. I recommend the experience thoroughly.

The Prepared - Call for sponsors

Added on by Spencer Wright.

Over the past year my little manufacturing newsletter, The Prepared, has grown up. It's bigger; it's gotten a bunch of design improvements; it started a podcast, got a real website, and has had a series of excellent guest editors.

So as 2017 comes to a close, The Prepared is officially looking for ongoing sponsors.

Sponsoring The Prepared gives brand and product marketers access to an extremely high value audience. It's easy, cost effective, and reaches engineers, managers, and operators at the most interesting companies in the world today.

If you're interested in exploring an ongoing sponsorship, get in touch

A Cell

Added on by Spencer Wright.

This has been fun:

This is The Public Radio's manufacturing process development cell, and with it I've built and shipped hundreds of lil' mason jar radios over the past month. 

As I wrote in The Prepared recently: 

TPR is a side project, and the vast majority of our process development this summer was done either on my kitchen table or on my desk, which had been pushed over to the side of what was once my office to make room for our baby's play room. But as the complexity of what I was doing increased, and as I accumulated stacks of cardboard boxes and started really tripping over all of the ethernet cable, I finally admitted that I needed to move myself into the basement and set up a proper assembly station.

In retrospect I was silly for waiting so long to make the move, and despite the low ceiling and the lack of natural light and the hum of the dehumidifier it's clearly a superior workspace. This is partly because I can implement a bit of maker time there, but mostly because it helps my empathy towards the folks *actually* doing our manufacturing. 

The hard part is knowing just how much of the work I need to do. And to be honest, I know that my own sense of empathy grows in proportion to my tendency to think that I've figured out the right way to do the thing, which is not something I like to bring into a relationship with a contractor. I prefer to delegate completely; to trust everyone in the process to bring full responsibility over their domains. I'm working on it; it's a process :)

A few additional notes:

  • Making customized-to-order products is *hard;* anyone telling you otherwise is either inexperienced or has some ulterior motive. We've put a *ton* of time into our order management and manufacturing operations systems (s/o to Gabe for the former and the whole team at Tulip for the latter), and there are still a lot of edge cases and error checks that I want to build out. It's either "you need humans with judgement on the assembly line at all times" or "you need to think through every single problem that someone would use judgement for and build its decision tree into your manufacturing system." It's *hard.*
  • I've always been a stickler about workplace organization, but setting up an assembly cell (where tasks are discrete rather than general and will be performed thousands of times each) brings up ergonomic issues that I have never had to confront. Of particular frustration is basic stuff like the way that countertop height interacts with stool height (and, optionally, footrest height).
  • If you're responsible for maintaining your product's (in our case, physical + digital) manufacturing tools, you should expect to be intimately involved in building thousands of units before handing the process over to someone who isn't a competent troubleshooter themselves. We needed to ramp up quickly, and rolled out to our CM a bit prematurely; the upshot is that Tulip an be updated on the fly and the majority of our physical infrastructure is purchased from McMaster-Carr and Amazon.
  • Torque limited electric screwdrivers are great. Also, stackable/hangable parts bins. If anyone has experience/tips for easy + affordable conveyor or onramp/offramp systems, LMK ;)

Since writing the above, we've come over the hump and are now focused on holiday orders. This has required a lot of energy, and has largely sapped my ability to  post updates here regularly. BUT never fear! We're posting semi-regular updates on The Prepared's podcast, and will have a bunch more interesting stuff to share soon :)

In the meantime, enjoy this twelve minute video of me building TPR boxes:

A month or so of TPR work

Added on by Spencer Wright.

The Public Radio is in preproduction.

First: I spent part of week in Taiwan, Shenzhen, and Dongguan in late June visiting a few of our component suppliers, and parts started trickling in at our manufacturing partner last week. Proof:

A few notes here:

  • A huge thanks to Lucas, who came with me to the speaker factory and was just generally a hospitable guy while I was in Hong Kong & Shenzhen. Thanks also to Kuji for showing me an awesome time (see this video) in Shenzhen. 
  • Visiting our speaker manufacturer for the second time (the first time was two years ago) was great. Knowing our suppliers is a real treat, and I've very much enjoyed working with them.
  • Seeing the mold for our new custom speaker was big. This was an investment - both in the tool itself and in our relationship with our speaker factory - but it makes The Public Radio more robust and *much* easier to put together. It reduces the assembly's total number of parts and allows us to use larger screws, which are easier to handle and will take less time to install. That both saves us money and makes TPR an overall nicer product. This is also the second injection molded part I've ever designed and is *slightly* more complex than the one before it, so from a personal standpoint it was *really* fun to actually touch.
  • China, as always, is just mind boggling. I especially appreciated Ofo, which is amazing.

Second: Since then, I've been dealing with our remaining procurement issues (mostly logistics & cash flow planning; some vendor management) and then hammering on our actual manufacturing plan. The Public Radio has an extremely simple user interface, and to create that there's a *ton* of work that goes into managing the assembly & fulfillment process. This involves a few special things:

  1. As Zach and I discussed with Gabe on The Prepared's podcast a few weeks ago, we've now got a fully custom order management database which coordinates customers, tuning frequencies, and shipping data (and a few other little things).
  2. An instance of Tulip, which will handle not only our assembly training but is also acting as the connective tissue between our database and the real world. Tulip will coordinate barcode scans, assembly steps, and our radio programming jig to keep everything in sync. It also logs productivity and can help track defects down the road. In short, it's awesome.
  3. Our radio programming jig. Josh is taking a crack at this (among other things :) now, and hoping to make it more reliable & robust than the ones that we used on the first batch of Public Radios two years ago. 

These three things are *just* starting to really come together this week; I've got maybe a third of it all running on my desk right now.

Next up: We should have a fully functional prototype of our manufacturing system running in two weeks. We'll be testing it in NYC for about a week, and will then bring the whole thing to Chicago to fit it into Accelerated Assemblies' processes. By then we'll have all of our materials on site and, after a short run or two to iron out any kinks, will be in full production mode.

More soon :)

On Makerism

Added on by Spencer Wright.

A few weeks ago, a reporter reached out to Zach and I to say that he was including us in a list of Brooklyn makers to know. He had a question as well:  How do you define "maker"?

This isn't something I've thought about in a while, and to be honest I've never really considered myself a maker in the first place. So while I was flattered to be on someone's top ten list, my response was nuanced: 

More than anything else, I think "maker" is a cultural signifier - something that denotes a certain sense of whimsy, combined with a bit of precociousness and craft. In the best cases, makerism is simply a gateway to something else; it's a stepping stone that eventually leads to a product business or a manufacturing operation. Zach and I have put a *lot* of energy into making this transition over the past few years, and most of the other people on your list have as well.

To be a bit more blunt: I've actively eschewed makerism in my own work. Not that I don't do makery projects or like cute things. But my tolerance for whimsy is relatively low, and the things that get me excited are real, sustainable businesses, and ultimately I find it difficult to maintain a strong sense of playfulness while my primary focus is on building something.

I'm sure other people have other definitions of what it means to be a maker, and those are perfectly valid. But I'd encourage everyone, as they're working on something new, to consider whether they're actually a maker - or if they're really just building a business around a cute product.

Now, to work

Added on by Spencer Wright.

In reality we've been chugging away nights & weekends for months, but it's nice to have it be official:

As I said on The Prepared's podcast a few weeks ago, it's still a bit crazy to me that people like this thing that we came up with. It's fun - a rare way for me to relate to people who are otherwise totally dissimilar to me. 

There'll be lots to share over the next few months, and I look forward to sharing it. Thanks *so* much to everyone who kicked in - we're really excited to have you with us!

The Prepared's podcast + A history of The Public Radio

Added on by Spencer Wright.

Some updates!

So, I've been working on some stuff. 

First: Thanks to The Prepared's *awesome* donors, I've redesigned and relaunched Awesome!

Second: In the spirit of expanding The Prepared's purview (which is why I'm taking donations in the first place), we now have a podcast! The goal of it, as with this newsletter, is to help people prepare for good work - and to share the results of the big things they've worked on. To kick things off, we've got two episodes: One with Zach on the history and future of Centerline Labs, the company we cofounded to create The Public Radio, and one with Zach and Gabe about some of the things we're thinking about on the eve of...

ThirdThe Public Radio's launch on Kickstarter! I'm very excited about this, and it deserves a bit of explanation:

The Public Radio started in 2013 as a longshot side project - "a product idea for a single-band FM radio," as I described it four years ago. Going back through my blog while filtering for the "publicradio" tag shows a funny story. Early on, I posted a lot of "this was my workday" posts. Then there was more topical content - my struggles finding the right potentiometer; little thoughts on how to take crowdfunding offline. In early 2014 Adafruit posted something short about us, and shortly after we soft launched

All of that was under looks-like prototypes; it wasn't until mid 2014 that we had a works-like, which we assembled (without SMT stencils! we were so naive) by hand. At this point the design iterations were more substantial, but it wasn't until late that year - after our first Kickstarter campaign - that things really became serious.

At this point we started getting some real attention, and a bit of backlash as well. It's worth mentioning that at the time, my days were spent consulting for Bank of America and GE on management & marketing strategy; The Public Radio was a weird thing to match that with. But it was getting *fun* - real engineering problems, real supply chain problems; real business problems; real press coverage; my first injection molded part. I was interviewed by New Hampshire Public Radio and by Matthew Lesko, the guy who wears the question mark suit on old '80s infomercials. 

And then, all of the sudden, we (with the oh-so-gracious help of friends/family/indentured servants) shipped 2500 radios to people all over the world. We missed our Kickstarter shipping goals by about a week; pretty good.

Almost immediately afterwards, we went to China to plan for v2.0. We visited our speaker supplier in Dongguan and roamed the Shenzhen electronics markets, and did all of the other things you'd expect. But as we were heading back to the US, my day job was in the process of vaporizing, and for the ensuing two years The Public Radio has largely been relegated to the odd warranty email.

So, this relaunch. The thing is, The Public Radio is a good product, and we want to find a way for it to live on. This is harder than it sounds. No matter how much the traditional supply chains are being (*cough*) disrupted, it's still really hard to run a hardware business in your spare time. The Public Radio is an incredibly simple device - intentionally so - and yet it's real work to get it made.

But we're trying anyway. We've got a pretty nice plan here - one that keeps TPR lean on capital requirements, keeps our supply chain short, and (most importantly) makes for a really nice customer experience. There's a lot to unpack here, and you can bet that I'll be sharing more here in the next few months :)

Anyway, that's that. Please, check out The Public Radio on Kickstarter and share it!!!! They look great, work great, and make for *excellent* gifts. And as we build out our manufacturing process, you'll be right there learning about it with us!

Desk right now

Added on by Spencer Wright.

A brief calm between many storms: 


I've spent a lot of time here over the past few months. Much of my work at nTopology  happens here; probably half of The Prepared's management and composition; a *lot* of reengineering & planning for The Public Radio. Plus the odd proverbial cat video, etc. 

I'm very lucky to have such a great work space; I'm looking forward to the next few (hectic) months.

The Prepared's Podcast

Added on by Spencer Wright.

As I've said here before, The Prepared was never meant to be a media operation. And yet, when I think of its place in my life and in (apparently) the lives of its readers, it's just that - and I can't help but want it to be more

So I'm happy, then, to announce The Prepared's first experiment into audio. Appropriately enough, the first episode of The Prepared (the podcast) is a conversation between myself and Zach Dunham, the better half of The Public Radio - which, as it happens, is *about* to relaunch on Kickstarter.

You can subscribe to The Prepared's podcast on iTunes or on my favorite posting app, Overcast. Heck yeah!

Stem prints

Added on by Spencer Wright.

Almost a year ago, I posted a rendering of my printed bike stem on my blog here. Now:

These parts were printed by my friends at Playground Global on their 3D Systems DMP320 in titanium 6/4. Like the titanium parts I've had printed (and written about extensively) in the past, these are done via laser metal powder bed fusion - the generic name that often gets referred to as "DMLS". These parts were, of course, designed in nTopology Element Pro; you can see more of my design process here

As loyal readers will know, I've put a lot of time into using Abaqus to predict these parts' mechanical properties; more on that in the near future. For the time being, the goal with this print was to test the manufacturing process - and use any lessons here to guide future design iterations. As you'd imagine, there's a *lot* that goes into printing a part that has ~45,000 beams; establishing manufacturing parameters was a good way to filter out nonviable design strategies.

It'll take a bit more work to characterize the as-built design fully, but at first inspection it seems to have been a total success. I was careful to keep most of the beams' orientations at a high angles, thicknesses above .45 mm, and lengths below 3 mm; the result is a structure that's almost completely self supporting.

At this point, the part has been roughly cleaned up and bead blasted to remove any surface discoloration. The next step is to tap the holes, clean up the clamp surfaces, and mock the entire assembly up.

More soon :)

See also: DMLS lattice sample prints, where I describe the part's design a bit more.

Stamping die changes

Added on by Spencer Wright.

So, Zach and I have been working on an updated version of The Public Radio, and I figure we're about due for a manufacturing update. So! Here goes:

This is the same progressive stamping die I've shown here, but with some small changes. The locations and diameters of our main assembly screws have changed, and as a result the tool needed to be modified. 

The cool thing about progressive stamping is that you have multiple stations - in this case five - to work with. As seen above, the stations go right to left. Initially the screw holes were punched in station one (far right), but now they're being done in station two. Making this change just requires removing four punches and then adding four new ones + corresponding holes; the old holes are simply left unused.

We've got a few other updates coming up, including visits to a few factories and a new assembly/tuning management process. Stay tuned :)