Note: This is a long one. I’ve been neglecting documenting the project so this post is a catch-up for the last few weeks of work. Future updates will be more frequent and bite-sized.
When I think about how to arrange and contain the single-board computers (SBC’s) that make-up the computational part of Raiden Mark II, there are some potentially conflicting requirements:
The key areas of improvement over Mark I are
- Lower power consumption
- Less expensive
To this list I also add “repeatable”, because I want to come up with a design that others can use. I don’t want to rely on any unusual, exotic or hard to fabricate components. I also want a design that gives a nod to the computers which inspired it, but not at the cost of the above requirements.
Aside from looking cool, there are some practical aspects to this design. The front panel laden with switches and blinkenlights is used to display status information for each node in the cluster, and the switches are used to control each node individually. These tactile, real-time feedback features are very useful when writing and testing software for a system like this. While the same could be accomplished via software, it’s often faster to be able to glance at an LED to see if there is a problem, or throw a switch to reset a single node. This also removes the need for any kind of video or keyboard connection to each node which is something that was a significant inconvenience when working on Mark I.
Another advantage to this design is that the largest part of the chassis (the cabinet) can be found fairly inexpensively on Ebay. This eliminates the need to fabricate large, strong parts and goes a long way toward making it easier to produce more than a one-off build.
Once I settled on the outside, I had to figure out how to arrange and connect all the components on the inside. I knew I wanted something modular and to minimize the amount of loose wiring. I determined that all the connections I needed to make (aside from network connections) could be found on the 40-pin GPIO header (the “Pi-2 Bus” as it is sometimes called). This being the case I could mount each SBC to a “backplane” using these connectors, similar to how PCI cards work in a regular desktop PC.
My first iteration of this was to design a printable backplane which would hold 8 40-pin IDE-style connectors. From these connectors I would run wires to a single connector used to make connections between the backplane and the LED’s, switches, etc. mounted in the front panel.
This backplane was also designed to align with the mounting holes of the 8-port Ethernet switch I’m including inside the case. The idea was to stack the backplane on top of the switch, that way all of the interconnected pieces could be removed from the chassis as a unit.
However, after experimenting with a few different layouts the part became somewhat large and exceeded the size in which my printer is capable of printing reliably. After a few failed attempts at making a printable backplane, I went back to the drawing board.
My second idea was to use a printed circuit board (pcb) for the backplane. This would not only eliminate the need to print a large part, but it would also allow my to “hide” the wiring between the sbc’s and the front panel connector. This seemed like a great solution, however after looking into several options for creating the boards, I ruled it out due to cost, complexity and lack of flexibility (I’m still at the experimental stage and I don’t know exactly how I want all the connectors wired together yet).
In parallel with work on the backplane I was giving thought to the front panel. I knew what I wanted it to look like, but I wasn’t exactly sure how to pull that off.
The panel requires many holes for the various indicators and switches and it also requires a number of “legends” as well. I really want to re-create the look of the old machines so the ability to apply these legends to the panel using the right lines and fonts is important, and the sheer number of holes and the accuracy of their locations rules-out my typical approach of grabbing a drill and free-handing it. Also I wanted to come up with a process that could be repeated by others, and might be applicable to some level of volume production.
It seemed like using a laser might be the right tool for the job, but the chassis is steel and I know that steel-cutting lasers are not the most accessible tool. So I started thinking about how both tasks might be accomplished using more common 40-50 watt cutting/engraving lasers.
The first step in this process is to draw the panel using a tool which can output something the laser can consume. I knew Inkscape was capable of this (since I had used it to create drawings for my first CNC project, a really crappy laser engraver ). After a bit of a learning curve I was able to produce a drawing of the panel that came off my laser (printer) while preserving the scale. Aside from scale the hardest part was reliably capturing the dimensions of the hole & attachment points the panel would need.
At this point I need to learn more about using a laser and do some experiments to proceed with the panel. I did a lot of reading and decided at some point I want to add a K40 laser to the laboratory, but for now I’m going to setup some time to visit the Idea Studio, learn how to use their laser and run some tests that I’ll elaborate on in a future post.
Now that work on the panel is blocked, I switched back to thinking about the backplane. One problem the previous backplane designs don’t address is how the components of the panel are mounted. In the old machines, there was a pcb for the backplane and a second one for the panel, and then holes were cut in the panel where the components mounted on this second board emerged. This means two large pcb’s and a lot of commitment to the connections between parts. Since both of these facts are not ideal for this project (at least at this stage) I started noodling on alternatives to the pcb backplane approach, and came up with something new.
I created a design for a modular backplane, where each module holds both one SBC and it’s associated front-panel components. This design solves a number of the problems described earlier and has the advantage of making each node a self-contained unit. This also makes it easier to scale the system up or down; while Mark II is designed around 8 nodes, the modular backplane system can easily scale up or down from there without changing the design (just the cabinet size).
This also eliminates the need for the front panel (although I still intend to create one for aesthetic purposes).
My first attempt at connecting the modules to each-other was to use printed “tabs” at the base of each module with the intention of fastening them using some short screws & nuts. However these tabs as originally designed were very weak, and increasing their strength resulted in increasing the size of the module to the degree that it might not fit inside the intended cabinet. This design also requires a lot of small fasteners and creates a sort of chicken-and-egg assembly problem, so it wasn’t ideal.
One night it occurred to me that I could both simplify and strengthen the connection between modules by using rods instead of tabs (I’m sure this was inspired by the threaded-rod construction of my Reprap). Not only would this solve my existing problem, but these rods could double as a power-delivery bus, eliminating the only remaining custom wiring harness needed for the system.
I ran a few test parts designed around the rod interconnect idea, connected them with some long screws I had laying around and it worked like a charm. The test parts I printed were a little warped so the fit wasn’t perfect, but it was very strong even with ill-fitting parts. The next step will be to find the smallest rods and electrical connectors that are suitable print another run of modules designed specifically to fit them and experiment with running power over the rods
Around this time my first PINE A64 board showed up. It’s dimensions and layout are different enough from the Raspberry Pi I had been prototyping with that I’ll need to spend some time re-working the backplane module, but this was expected. I don’t think the changes will be too much work or will invalidate the design.
At this point I have a few steps queued-up before I should need any additional hardware. I’m going to try and schedule some time in December to work on laser cutting the front panel, and I’m going to jump into “refactoring” the backplane module to fit the PINE A64 board (as well as some properly-sized connecting rod). After that, I’ll have some hardware and software tasks to do with wiring-up and configuring Linux on the PINE sbc, and sorting out a few remaining details around cramming everything back into the cabinet.
With any luck I should have the system to a point where it is assembled and operational with a single node by the end of December. Once that milestone is reached, I’ll order another 7 boards to round-out the hardware configuration and begin to dive deeply into the software-side of the system (just in time for the perfect time to write software in Wisconsin, the heart of winter).