Model 2, Part 3 - Failures and Lessons From Design

Last Updated: 2022-07-19 07:30:00 -0500

The first two articles in this series talked about designing and building a mechanical keyboard - the Arcana Labs Model 2. This is a speciality keyboard that I custom designed to fit a very specific set of space and functionality constraints, and while a fair amount of work went into meeting those constraints broadly, there was a lot that did go wrong from a design perspective before laser ever met stock and solder ever met iron.

Visualizing an Object and Understanding Scale Are Not The Same

In part one I shared some guidance on tooling I used to design the keyboard’s layout, and also its base plates, which were both expedient and convenient ways to generate the SVG plan views that my laser cutting manufacturer needed in order to cut the parts. This made it pretty easy to have the part validated because I didn’t have to mess around with measuring the specific dimensions of the key holes (for example), and also, apart from the breakup of a few layers I did to make the laser cutting cheaper, I didn’t have to modify anything. I was able to go ahead and directly order the keyboard’s largest parts in reasonable confidence that they would all fit and work together, and technically, they did.

However, what I didn’t do - at any point - was a quick sketch or model of the device assembled. I could picture it clearly in my head, and it’s a simple enough design I didn’t think I’d need a full assembly plan. This allowed the keyboard case’s largest flaw to rear its ugly head; the assembled stack does not have the internal space to allow for the space consumed by the wiring harness inside it.

If I had done even a quick 1:1 scale mockup in the lab grimoire, or better still, broken out a CAD tool to mock it up, I’d have been able to see pretty quickly that things were getting crowded, and that would have made it easier to realize “hey, you know, I should really make sure that I have all the internal layers cutout of the thicker stock to give myself more room on the inside.

At the time what I did was open a pair of calipers to what the height was going to be and say “yeah, that’s roughly the same as my current keyboard”, but that keyboard has entirely different internal construction and really wasn’t a good example.

Squareness Always Requires More Than One Point of Registration

An overhead or side-on examination of the Model 2 reveals a pretty stunning flaw in the interior layers of the case - especially in the case of the “open” layer - which is that all four of its corners are out of square. Naturally, they’re designed to be square.

The source of error here really comes from two places:

The “wall thickness” for these layers is a bit too thin, especially considering the overall thickness of the layer is also quite thin. The Acrylic has a moderate amount of flexability available to it at that size, and that is not accounted for with restraint.
The squareness of the corners, after my modifications, comes entirely from a single joint, which is square only if (a) the cuts themselves were made perfectly to spec and (b) no error is introduced from the curing of the CA glue or workholding during that curing process.

Both problems would have been easily solved with an additional pair of screws along the top and bottom edges of the keyboard’s face, and perhaps by having simply eaten the cost and chosen not to break up the corners, though I would then have been left with much more waste acrylic.

Simpler is Not Always Better

I chose a sandwhich case design for a few reasons, all of which fall under the general category of “ease of manufacture”. Laser cutting is an extremely easy process to work with, especially when you’re outsourcing the bulk of it, but it’s limited over other manufacturing methods in that it is, effectively, two dimensional. Because of that, I didn’t really put any thought into a number of features I feel the case is still missing:

Lack of Structural Support for the Microcontroller

The keyboard’s microcontroller and its attendant hardware are broken out as a Teensy 4.0 by PJRC. My design made no provision, whatsoever, for holding this device in place inside the keyboard, and indeed it is entirel held in place by the collective rigidity of the 20-odd 22 AWG leads connected to it and the relative tension they create. This is probably sufficient, so long as the USB cable is never sharply yanked, but it’s not as secure as I would have liked.

I think given time I might have at least put some kind of provision in to build up a strap-down for it, though I haven’t put much thought into how that would have worked mechanically.

Lack of Gasketing for the USB Cable

While it’s not the most pressing concern to me as I still don’t have the “right” USB cable attached to the device (I intend, eventually, to find one with certain charactersitics that will make my life easier for the intended use cases of the keyboard), I made no provision whatsoever to gasket the USB cable in place. In fact, it kind of just floats freely around inside the keyboard, loosely bound by the passthrough slit in the “open” layer and by its point of attachment to the controller.

I think the solution to both problems in a laser-cutting regime might be a product like suguru, but again, proper thinking through of the design would have exposed this problem earlier and made whatever solution I settle on less of a hack and more of a proper solution.

Measurement Errors Abound

There’s no shortage of measurement errors present on the keyboard, either:

The base plate is too thick (this deserves its own discussion)
The overall height of the case stack did not account for the inclusion of the thickness of the screw heads in the measurement of the length of the screw, and therefore even with the too-thin layers originally specified in, the screws were too short to fit, requiring modifications to the back plate.
The thickness of the walnut face plate in comparison to the available fastening collar on the rotary encoders is almost exactly equal, meaning the encoders cannot be secured in place, and will have to be re-ordered.
The knobs for those encoders were not checked against the placement of the encoders, meaning that they are too large to be used together and must also be re-ordered.

No Provision Was Made For Registering Or Securing the Nameplate

There is an engraved brass name plate on the device that proudly prolcaims it to be the Arcana Labs “Model Two Arcane-Human Interface”. While I did get it largely square relative to the rest of the elements nearby, the fact remains it’s really just held on with CA glue and it was a mixture of knack and luck that got it affixed correctly in the right orinatation. A smarter design would have provided for some kind of fasteners.

Insufficient Research Was Done on “Standard” Keyboard Construction

It shouldn’t surprise anyone, considering how easily I was able to obtain these parts and how much FOSS tooling is out there for doing this sort of work, that mechanical keyboards are something of a major industry, a culture in and of itself at the intersection of the gamer, compsci, and elctronics hobbyist subcultures. The commodification of keyboard parts has driven, and is driven by, standard ways of doing things.

The most important and glaringly obvious example of this is the key base plate. My design has it made from solid acrylic as one of the thickest elements in the keyboard, and that’s wrong for two reasons:

Elements in the key body that spring back slightly to “clip” into their base plate are suppressed, and key fitment now is entirely a matter of either friction, tension from the solder joins to the wiring harness, or in a few places, adhesion by CA glue (a repairability problem), and
Stabilizers needed to allow larger keys, most especially the spacebar, to function correctly are not manufactured in any style that suits this configuration, and the stabilizers I do have are (a) heavily and crudely modified, and (b) provide most of the problems with the keyboard to date.

The whole point of this project was to be the Grand Unified Keyboard for all the machines in the lab, so anything I’ve done that limits its repairability or causes it to be annoying to use is a major detriment to the project.

Insufficient Thought was Given To the Host

The host device for the keyboard is a Teensy 4.0, which has a very convenient physical envelope in terms of figuring out how to place it within the case, but was very inconvenient to work on. Alternatives existed, even above and beyond points I outlined last time about it being a supported device for the firmware I ended up using.

Bottom Line: Would I Design Another Keyboard?

Yes, though it would take much longer. I don’t think it would be too difficult to start from the SVGs we generated and extrude them in CAD software out to objects with actual thickness. It follows, then, that it wouldn’t be hard to fully model the entire assembly, and with a bith of thought I think I could even figure out some internal assemblies that would have better held a microcontroller board in place.

If you wanted to show your support financially, for free tools and toys like Pyminder, Tapestry, and PETI, your best avenue is via my Github Sponsors account or by making a one-time donation to Arcana Labs via Ko-Fi.com or through other avenues detailed here. Supporters also get access to a special patrons-only section of the Arcana Labs Discord Server, where we talk about the ongoing and upcoming super-secret project.