One of the things I have been realizing while working on the Phrankintosh project is that there is a very big difference between designing something that works and designing something that lasts.
The first version of almost anything answers one basic question:
Does it work?
Does the board fit?
Does the sled slide into the rail?
Does the fan move air?
Does the controller turn on?
Can I get the ESP32 to actually talk to the hardware?
Those are all important questions, but they are really only the beginning.
Once something works, the next set of questions gets harder.
Will it still work after I move the machine?
Will it survive being transported in a car?
Will a latch survive being pressed hundreds of times?
Will a 3D-printed part eventually split along the layer lines?
If something wears out, can I replace one small piece instead of printing the whole assembly again?
That is where this project has been taking me lately.
The Phrankintosh started out as a Macintosh Classic II case that I wanted to repurpose around a Raspberry Pi. That alone was enough of a project.
Then came the cooling system.
Then the mounting system.
Then the custom rails.
Then a system controller based around an ESP32-S3.
Then temperature monitoring, fan control, serial communications, system supervision, Wi-Fi, a web interface, and eventually the possibility of an SD card.
And, because mission creep apparently needed a mission creep department, we have now discussed serving browser games from the controller, including Doom.
That is another story.
The mechanical side of the project has become particularly interesting because the latest problem is not simply figuring out how to mount the electronics.
It is figuring out how to mount them in a way that survives real use.
I have been developing a dovetail rail system that lets different boards and assemblies slide into position inside the Classic II case.
The dovetail itself should carry the actual load.
That is important.
The retaining mechanism should not be expected to support the entire assembly. Its job is simply to keep the sled from moving along the rail once everything is installed.
That sounds simple until you start asking what happens when the computer is actually transported.
A snug dovetail may be perfectly fine while the machine sits on a desk.
Put that same machine in a vehicle, hit some bumps, turn corners, and subject it to vibration for an hour, and suddenly “snug” may not be good enough.
So now I am working on a positive locking mechanism.
One version uses a spring clip built into the center of the rail.
The idea is to use the shape of the latch itself as the cutting geometry for the rail. That way, instead of guessing where the locking notch belongs, the latch defines the exact shape it needs to engage.
The rail still guides and supports the sled.
The latch only prevents fore-and-aft movement.
The spring section provides enough pressure to keep everything tight and eliminate movement.
That also means I can think about the spring as a separate component instead of forcing the entire sled to flex.
That matters with 3D printing because layer orientation matters.
Printed plastic is not equally strong in every direction.
A part can be very strong along the printed strands and still fail by separating between layers.
So if I know that a particular portion of a latch is going to flex repeatedly, I can print that component in an orientation that makes the layers work with the motion instead of against it.
The thumb section of the latch creates another problem.
That area is going to be repeatedly pressed to release the sled.
Over enough cycles, the upper portion could eventually begin separating along the print layers.
One solution I have been considering is putting small steel pins through that section.
The steel would run across the print layers and act almost like reinforcement through laminated material.
The plastic would still create the shape of the latch and provide the spring behavior, but the metal would help keep the thumb section physically tied together through repeated use.
That is one of those little design decisions that probably would not occur to someone if the only goal was to make a prototype work once.
But once you start thinking about how something will fail, the design changes.
I am also considering spacers to fine-tune the preload on the latch.
Instead of redesigning the entire sled because the latch is half a millimeter too loose, I could print several thin spacers and tune the amount of pressure mechanically.
Maybe half a millimeter.
Maybe eight-tenths.
Maybe one millimeter.
Whatever gives the system a solid lock without making it difficult to release.
And if the spring-latch idea turns out not to be the best answer, the rail system does not have to disappear with it.
That may be the most useful part of the whole design.
The dovetail is the common interface.
The locking mechanism can change.
It could be a spring clip.
It could be a friction wedge.
It could be a cam.
It could use a thumb screw.
It could even use a magnetic assist.
As long as the rail remains the structural element and the secondary mechanism simply prevents movement, I can continue experimenting without redesigning the entire mounting system.
That is where I think GitHub is going to become particularly useful for this project.
I recently started putting the Phrankintosh project up there, and I want the repository to become more than simply a place where I dump finished files.
I want it to show the evolution.
One revision may simply prove that the sled fits.
The next revision may add a locking notch.
The next one may change the latch orientation.
Another may add steel reinforcement.
Another may add spacers.
Another may replace the spring entirely.
That revision history tells a story that the final STL file never could.
A finished design makes engineering look obvious.
The development history shows all the decisions that made it obvious.
That is one of the reasons I have enjoyed stretching back into projects like this.
A lot of my life lately revolves around driving, technology, computers, and whatever happens to be going wrong in the world that day.
But there is something satisfying about sitting down with a physical problem and working through it one failure point at a time.
Not theoretically.
Not just drawing something that looks good on a screen.
Actually asking:
Where is this going to crack?
What happens if someone pulls on this?
What happens after a hundred cycles?
What happens if the machine gets dropped?
What happens if I have to repair this two years from now?
Can the worn piece be replaced?
Can somebody other than me understand how it goes together?
Those questions are the difference between making a part and designing a system.
And maybe that is the larger lesson coming out of this ridiculous little Macintosh project.
The older I get, the less impressed I am by something simply working once.
I want to know whether it will still work after it has been moved, flexed, repaired, transported, and used by somebody who did not build it.
That is not just an engineering principle.
That is probably a pretty good philosophy for a lot of things.
The Phrankintosh still has a long way to go.
The sled is still evolving.
The latch is still evolving.
The controller board is still evolving.
There is probably going to be more mission creep.
Actually, there is definitely going to be more mission creep.
But if all that experimentation leaves me with a machine that is easier to service, harder to break, and better documented than when I started, then I am perfectly fine with that.
Because getting something to work is the beginning.
Designing it to last is where the interesting part starts.