Amass a library of reusable parts and dimensions: acrylic thicknesses, T-slot designs, mounting hole layouts for Arduino or other boards, etc. After iterating and eventually nailing a design, you can then carry elements over to new designs without reinventing the wheel each time.
Case in point: I’d found that the ChipKIT Uno32 (a Microchip PIC32-based Arduino compatible) had one mounting hole slightly offset from a true Arduino. But an oval-shaped hole could accommodate both the true and derivative boards. Though I don’t use the Uno32 a whole lot, I still incorporate this same mounting hole set in any new design…the work is already done, there’s no reason to lock out those boards, and there’s a subset of users who will appreciate it.
After assembling a prototype, write changes directly on the parts with a Sharpie marker. Then dismantle and use the notes for the next iteration. Sometimes these are just lines or arrows. This visual representation is quicker and more intuitive to follow than written “move USB cutout left 1.5mm” notes. Set aside each sub-part as the changes are made in the design.
Save the parts for each design iteration in a separate Zip-Loc bag in case you need to refer back to these later (or just as a nice history of your progress). Write “V1”, “V2”, etc. on the outside of each bag (or on a larger front piece inside the bag) to avoid confusion.
Once a design is well-settled upon, it’s okay to discard this history. They’ll fill up your life otherwise.
Once a design is well-settled upon, it’s okay to discard this history. They’ll fill up your life otherwise.
Similarly, save each major iteration in a separate file, perhaps with a sequence number like “Foo Case 01”, “Foo Case 02”, etc. Sometimes a direction you take will prove to be a dead-end, and it’s handy to take a step (or several) back.
Backup software like Time Machine isn’t suitable for this, since it’s based on regular time intervals, not immediate file changes. Some applications may support a version history…or the version control systems used in software development (e.g. Git) might be viable; I’ve not explored this yet as the sequential files have been sufficient to provide a basic “rewind” capability.
Backup software like Time Machine isn’t suitable for this, since it’s based on regular time intervals, not immediate file changes. Some applications may support a version history…or the version control systems used in software development (e.g. Git) might be viable; I’ve not explored this yet as the sequential files have been sufficient to provide a basic “rewind” capability.
After finalizing (you think!) a case design, assemble, disassemble, and reassemble it repeatedly. Find the optimal path with the clearest explanation and the fewest potential pitfalls. Then document that one. If it’s just too complicated — if the process can’t be completed without specialized tools or seven fingers on one hand — consider iterating the design again to simplify it.
Ideally a design should be “keyed” to only fit together one way. This avoids missteps during assembly. I’ll totally admit to running afoul of this rule way too often, mostly because asymmetry irks me. But it’s a sound principle.
Sometimes a design can’t be keyed asymmetrically, but there are other ways to work around it. Case in point: the front flap on our Internet of Things Printer relies on two identical “hinge bumps” to pivot upward. It seems that about half the time, users install this part reversed…it’s still perfectly functional, but the stylized “@” symbol is flipped horizontally and many don’t recognize the mistake. In the second version of this kit, the fix is simply to use an image that doesn’t “read” one way or another: the language-centric @ sign was switched out for a cloud and makes sense either way.
Sometimes a design can’t be keyed asymmetrically, but there are other ways to work around it. Case in point: the front flap on our Internet of Things Printer relies on two identical “hinge bumps” to pivot upward. It seems that about half the time, users install this part reversed…it’s still perfectly functional, but the stylized “@” symbol is flipped horizontally and many don’t recognize the mistake. In the second version of this kit, the fix is simply to use an image that doesn’t “read” one way or another: the language-centric @ sign was switched out for a cloud and makes sense either way.
