Since my last fixture project was foiled by laser cutter kerf, I thought I’d try 3D printing the next fixture to avoid laser cutter kerf spoiling my fixture accuracy.
I started with the same idea as the previous project – just put two pieces together in a right angle joint. This time I put a hinge in the fixture. The idea is that the work pieces can be put in place separately (with acrylic cement already applied to joint surfaces) and then I rotate about the hinge to bring the pieces together.
I could have stopped there, but a single joint doesn’t do anything. If I’m using up acrylic, I prefer building something that can be nominally useful. So the ambition grew to building a little box: 5 pieces (four identical for sides and one for bottom) joined together by simple right angle joints. This is only a small box, just big enough to be useful for things like holding little screws, nuts, and washers. It seemed a suitable baby step since most of the projects I have in mind for acrylic (starting with the FreeNAS enclosure) basically boil down to acrylic boxes as well. So the fixture was designed in CAD, then multiplied to create three additional copies at right angles to each other, to create my box building fixture.
The end result demonstrated that, even though a 3D printer does not have cutter kerf to compensate for, it introduces other errors in the system. Maybe expensive industrial 3D printers would have enough accuracy to make this fixture work, but my little hobbyist level printer definitely did not. The corners of the box did not mate together as precisely as it did in my mind. The gaps are too wide and uneven for acrylic cement to bridge.
After this experiment, I decided I should go back to laser cutting and learn how to compensate for kerf and/or design around it.
I went back into Autodesk’s Fusion 360 learning resources for a refresher and to set myself up to learn the Fusion 360 CAM modules. The last time I went through the tutorials, I had skipped the CAM functionality because I had no machine tools and were not likely to get time on anybody else’s machinery. Now that I might be able to access Tux-Lab fabrication machinery, I wanted to make sure I won’t break the machine from doing anything stupid in Fusion 360.
Before I got to CAM, though, the “Foundational Concepts” section caught my attention. I either didn’t see it the last time or it made no impression on me at the time. I went through the set of short videos and they were surprisingly informative. Most tutorials for Fusion 360 (and most other software packages in general) are happy to tell users how to accomplish their tasks. This is a slightly different twist – the foundation concepts talk about whyFusion 360 is the way it is. About how they tried to restructure a CAD package for the cloud-based future, about how they restructured the workflow to take advantage of today’s level of computation power at our fingertips, so on and so forth.
I come from a software engineering background and I’m all too aware of the fact that the end user typically has no idea what the software developer had intended as they built the piece of software. It can be argued that the end user doesn’t need to know anything about the intent if the software is sufficiently well-designed. But for something complex like a CAD package, I believe there is value in learning the motivation behind the design.
And even if the user doesn’t need to know, sometimes the user is curious and wants to know. I appreciate the Fusion 360 user education team for putting this information out there available for those who want to know.
And now for something completely silly: let’s look at how our two competing hobbyist-friendly CAD offerings fare on the hobbyist-friendly single-board computer, the Raspberry Pi.
(Spoiler: both failed.)
I have on hand the Raspberry Pi 3 Model B. Featuring a far more powerful CPU than the original Pi which finally made the platform usable for basic computing tasks.
When the Raspberry Pi foundation updated its Raspbian operating system with PIXEL, they switched the default web browser from Epiphany to Chromium, the open-source fork of Google’s Chrome browser. Bringing in a mainstream HTML engine resulted in far superior compatibility with a wider range of web sites, supporting many of the latest web standards, including WebGL which is what we’ll be playing with today.
Autodesk Fusion 360
Fusion 360 is a native desktop application compiled for Windows and MacOS, so we obviously couldn’t run that on the Pi. However, there is a web component: Fusion 360 projects can be shared on the Autodesk 360 collaboration service. From there, the CAD model can be viewed in a web browser via WebGL on non-Windows/MacOS platforms.
While such files can be viewed on a desktop machine running Ubuntu and Chromium, a Raspberry Pi 3 running Chromium is not up to the task. Only about half of the menu bar and navigation controls are rendered correctly, and in the area of the screen where the actual model data should be, we get only a few nonsensical rectangles.
Before this experiment I had occasionally worked on my Onshape projects on my desktop running Ubuntu and Chromium, so I had thought the web-based Onshape would have an advantage in Raspberry Pi Chromium. It did, just not usefully so.
In contrast to A360’s partial menu UI rendering, all of Onshape’s menu UI elements rendered correctly. Unfortunately, the actual CAD model is absent in the Raspberry Pi Chromium environment as well. We get the “Loading…” circle and it was never replaced by the CAD model.
Sorry, everyone, you can’t build a web-based CAD workstation with a $35 Raspberry Pi 3.
You can, however, use these WebGL sites as a stress test of the Raspberry Pi. I had three different ways of powering my Pi and this experiment proved enlightening.
A Belkin-branded 12V to 5V USB power adapter: This one delivered good steady voltage at light load, but when the workload spiked to 100% the voltage dropped low enough for the Pi to brown out and reset.
A cheap Harbor Freight 12V to 5V USB adapter: This one never delivered good voltage. Even at light load, the Pi would occasionally flash the low-voltage warning icon, but never low enough to trigger a reboot. When the workload spiked to 100%, the voltage is still poor but also never dropped enough to trigger a reset. Hurray for consistent mediocrity!
An wall outlet AC to 5V DC power unit (specifically advertised to support the Raspberry Pi) worked as advertised – no low-voltage warnings and no resets.
Now that I’ve climbed the initial learning curve for OpenSCAD, it’s time to start working towards my goal for doing this: I want to visualize arbitrary motion between components as a rough draft to see how things move in virtual space.
This is not an unique capability in CAD packages. Both Fusion 360 and Onshape have ability to define object hierarchies and visualize their motion. However, they are both focused on the assemblies that have been mechanically defined in CAD. If I wanted to visualize a hinge-like motion between two objects, I first need to build that hinge in CAD or the software would “helpfully” tell me I’m trying to perform an impossible motion in my design.
In contrast, OpenSCAD does not care. I can place a rotate() operation anywhere I want and it won’t care if there’s no hinge in the design. It is happy to let me rotate about an arbitrary point in 3D space with no hardware around it. This makes OpenSCAD ideal for trying out how wild ideas would (or would not) work in virtual space, before getting down to the nitty-gritty about how to build the mechanisms to implement those wild ideas.
This means some cool-looking ideas would turn out to be impossible to implement, but that’s OK. I wanted something with a lot more freedom than I can get in the CAD packages that limit what I can do for (in their view) my own protection.
But that’s still in the future. For now I’m still climbing the learning curve of moving objects around in OpenSCAD in a way that ties into the built-in animation capability and generating animated GIF to illustrate concepts.
As a learning exercise, I’ve re-implemented the motion of the Luggable PC hinge. Thanks to OpenSCAD flexibility, I didn’t have to spend time building the hinge before I move it!
OpenSCAD is a very popular 3D modeling tool in the 3D printing community. Many of the projects available to print on Thingiverse were generated from OpenSCAD. This is most obvious when authors uploaded their .scad files for sharing with the community, but also visible as a core pillar of the “customizable things” section. The customization capability is made possible by variables the author made adjustable in OpenSCAD.
I started designing for 3D printing with the GUI CAD tools, Onshape and Fusion360, so the text-based approach of OpenSCAD seemed strange and foreign at first glance. The official OpenSCAD web site documentation pointed to several tutorials. Not knowing the comparative advantage of one versus another, I just clicked on the first in the list How to use OpenSCAD. It linked to several other tutorials, the most notable one being Know only 10 things to be dangerous in OpenSCAD as having the most compact words-to-content ratio.
I had initially approached it as “Boy it’s going to be hard to completely change my thinking” but as I got along in the tutorial I realized things didn’t feel as foreign as I thought it might be. Digging through musty memories, I realized I had encountered this type of 3D modeling (CSG or Constructive Solid Geometry) before many years ago in the form of POV-Ray. Back in the days when a 20-megahertz 386 was a pretty speedy CPU, and the floating point processor wasn’t a standard part of every PC. I had to upgrade my computer with the purchase of a 387 math co-processor in order to render my POV-Ray projects at a reasonable speed.
Editing CSG files for rendering in POV-Ray was my first exposure to 3D computer graphics, and I chose it because it was free. I couldn’t afford GUI graphics software (the flagship at the time was Autodesk 3D Studio) so I started with the basics and I learned a lot that way. In time, I might appreciate the straightforward simplicity of OpenSCAD in the same way.
When working on a CAD project, the majority of my time is spent focused on a single view of my subject. But when it comes to align parts into an assembly, it is very useful to have multiple views, and this is where Fusion 360 falls behind Onshape.
Fusion 360 can toggle between the standard single-view mode and a quad-view mode. In quad-view mode, the window starts with four equal-sized views and the user can adjust the relative sizes within the window.
This is a bare-bones baseline level of functionality. I can work with it, but I’m not happy with it. Onshape does it better.
Onshape takes advantage of the fact it runs in a browser. You can have multiple browser windows open on the same Onshape project, and each window can be a different view. Onshape infrastructure keeps all the windows in sync – any change made in one view is immediately reflected in all the others. Want four views? Open four windows. Want 6 views? (top/bottom/left/right/front/back) Open six windows.
And since these Onshape views are all separate windows, they can be placed on different monitors to build a great multi-monitor workspace. Fusion 360 is limited to a single window. Trying to use Fusion 360 across multiple monitors means manually scaling the application window across them. Toolbars get cut in half, resolution doesn’t match, problems left and right. It is not ideal.
What about opening multiple instances of Fusion 360, one for each monitor? It turns out that doesn’t work because the instances are unaware of each other. Change made in one instance is not reflected in the others until the user hits “Save” in one instance and “Reload” in all the other open instances.
The obvious conclusion is that Fusion 360 works best on a single high-resolution display instead of multiple screens. Sadly this is also false. As mentioned in my first Fusion 360 vs. Onshape comparison, Fusion 360 does not scale to high-resolution displays (4K, Retina, etc.) whereas Onshape takes advantage of the fact browser makers have long since handled the problem of scaling for high resolution.
The Luggable PC project page on Hackaday.io has been fully documented for anybody to build their own home-built 3D-printed computer chassis. All the components required for assembly have been listed, and all the steps of assembly documented with pictures taken at each and every step.
I expect to continue to make small tweaks to the design, improving little things here and there, but the machine is usable enough that I should stop tinkering with it and actually start using it. This means no new versions rebuilt from scratch for the foreseeable future. But if inspiration strikes, there will be!
When I’ve taken my Luggable PC to various maker events in the local area I’ve received generally positive reception and appreciation. Now I wait to see if anybody actually takes me up on the information compiled and build their own.
Here’s the 2.5″ drive bay in the initial iteration of the threaded-box Luggable PC design. It is a simple, basic place to hold one laptop-sized drive, but not a very efficient use of space.
The most obvious thing to do is to vertically stack another drives adjacent to the existing drive. Easy to do in CAD, but has problems in the real world.
Problem 1: How do you access the fasteners? The laptop storage market have mostly settled around two basic fastener schemes: four screws on the bottom of the drive, or four screws along the sides. If we use the side fasteners, they would not be accessible for drive replacement without taking the whole case apart. The bottom fasteners would be accessible, except that bracket would be impossible to print on a FDM 3D printer.
Problem 2: How do you connect the wires? While at first glance there is enough space to physically accommodate the drive and its plugs, it fails to take into account the wires. The wires for the existing drive barely clear the edge in the picture. Stacking another drive into that space (even if moving it another cm or two to the right) would demand wires make relatively sharp right-angle turns. This would place strain on the connectors including the fragile unsupported SATA connectors on the drive itself.
After some experimentation with the available space, keeping in mind the requirements above, I decided to angle the two stacked drives:
Now the Luggable PC has two independent drives: One for Windows 10, and another for Ubuntu Linux 16.10.
This design solves the fastener issue: in this arrangement, it is possible to 3D print the drive bay so both drives are held in place by the shape without use of any screws on the sides or on the bottom. Both drives are held in place by a single 3D printed clamp that is secured with just two screws. The downside is that the design only works when both drives are present. It is unable to hold a single drive in place.
This also solves the initial wiring issue: By angling both drives, the wires do not have to make sharp turns and would not place unreasonable strain on the connectors. However, this comes at a cost of usable interior volume. By angling the connectors, and avoiding sharp turns, the cables consumed more precious interior volume than the previous design.
Going back to the idea of drives stacked in the available volume, we revisit the problem of forcing wires to make sharp turns. The turns can be relaxed if we can find more room for the wires without angling it into precious interior volume. The solution turned out to be… turning the drives instead! By rotating 90 degrees a drive can be positioned to make room for the cables’ turns. It also allows two drives to exist side-by-side, allowing the bay to work with a single drive or dual drives.
This design was incorporated into the following iteration of the chassis, built using aluminum extrusions instead of threaded rods as the metal structure.
After some time using the assembled Luggable PC prototype, I wanted to adjust the screen ergonomics. While the screen has been raised to a height much more comfortable compared to a laptop, after a few hours of use I wished I could tilt the screen upwards a few degrees.
At first glance this would have been impractical – the screen hinge design is already complicated and adding a tilt adjustment mechanism would only make it more so. So instead of tilting the screen, let’s achieve the goal by tilting the entire Luggable PC by adding 3D printed feet that can be bolted to the bottom of the machine.
The easiest approach would have been to print a simple solid wedge with the desired angle, but I decided to be a little more experimental. I played with Fusion 360’s spline tool to sketch out feet that are designed to move and flex a tiny bit. The flexibility adds two features:
Shock absorption: We still need to be careful setting it down on a surface, but the minute bit of flexibility we gain will help cushion the harshest part of initial impact and make it feel less like we’re breaking the machine every time we set it down.
Flatness compensation: With a bit of flexibility in the feet, the Luggable PC can now conform to surfaces that are not perfectly flat. Previously, the solid bottom means it will rock on 3 out of 4 feet on any surface that isn’t perfectly flat (which is most of them.)
Here is the first iteration, which accomplishes the desired goals:
Unfortunately it also has a problem: by moving the contact points inward, the front feet are now uncomfortably close to the center of gravity. A slight push from the rear will send the whole thing toppling forward. The design needs to be adjusted to have a wider stance… but we are constrained by the fact the fastening nuts still need to be accessible.
In this case, the short-term fix is to move the feet as far front as possible while still allowing wrench access to fasteners.
The real solution is to redesign the bottom of the case to accommodate the feet while maintaining a sufficiently wide stance. This idea was incorporated into the following iteration of the Luggable PC. As it used aluminum extrusions for backbone instead of threaded rods, the new wider feet were installed on the bottom extrusion.
The use of threaded rods to hold the Luggable PC case together was borne out of necessity: The print volume of the 3D printer is much smaller than the volume of a PC case so it must be printed in pieces then fastened together. A threaded rod provides strength along its length, but how do we best handle the inevitable corners?
The key constraint is the strength of a 3D printed part, especially the adhesion between layers. This is an unavoidable fact of life for FDM-type printers: the part is weakest between layers, so designing for 3D printers must consider the layers similar to how designing for wood must consider the grain.
Version 1: basic asymmetric
In this design (as used in the “Easel PC” iteration) two of the rod axis are aligned with the direction of the layer. Stress along those two axis would mostly be held in check by the strength within each layer, but a fraction of the force would try to push the layers apart. To guard against this, the third axis is orthogonal so its fastening nuts would also try to hold the layers together.
The problem with this design is that the corners are asymmetric by nature. Not just in appearance, the loads it can tolerate are also asymmetric.
Version 2: symmetric but space consuming
The goal of a corner that handle loads symmetrically across the plastic layers means finding a way to make sure the plastic grain is equally strong across all three axis. The solution is to print at an orientation that lies at the same angle to all three axis.
While this design solved the problem of symmetric appearance and strength, it introduced a new problem: by printing this way, the hinge consumes a lot of the enclosed volume making it unusable. When the goal is to pack the computer components inside a minimalist PC case, every cubic centimeter counts!
This hinge was used in the “Threaded Rod Box V1” and the space it consumed severely hampered the packaging of that layout. It is definitely not the optimal solution so the search continues.
Version 3: Let’s All Huddle Close!
The previous two designs both depended on the plastic to take some part of the load and hold on to a few steel rods. These rods were a few centimeters apart because we needed room for a wrench to tighten the nuts. We needed the nuts to sit inside the corner because…
… um, why do we need them inside? The key for version 3 is the realization that we don’t need that. By offsetting the rods slightly, we can extend the rods past the corner so the fastening nuts are outside of the enclosed volume and not competing for space with the components inside the box.
When the nuts (and the required wrench clearance) are no longer inside the volume, it allows the rods to sit much closer to each other. Now the closest distance between rods are measured in millimeters instead of centimeters. It also means the three sets of fastening nuts help exert a clamping force across all three axis, compressing everything together. This compression means the alignment of the print layers become much less critical allowing significantly more freedom in designing the rest of the case.
This corner design was used successfully in Threaded Rod Box V2 as shown. (In these pictures, some of the threaded rods have yet to be trimmed to length.)