# Reflections on Clank-LZ from HTMAA

• machine_design
• teaching

this is a mirror of notes in the gitlab repo, where CAD files are also available

I’m closing out on Clank-LZ today, moving on to build out the toolchanger-complete Clank! platform so I thought I would do some summary notes & organize this repo for future observers of the project… / for my own peace-of-mind.

## What We Did

In around June 2020, I had been developing Clank as a machine system targetting ‘small’ CNC: 3D Printing, PCB Milling, Pick-and-Place, Automated Pipetting, etc. The broad plan was to have a friendly (easily fabricated, straightforward) set of machine designs (axis, tools, and a tool changer) to handle almost any CNC task outside of heavy duty / high load applications - a kind of generalist.

Given the state of the coronavirus pandemic, we realized that we would be teaching how to make almost anything in a largely remote fashion. While I originally hoped to complete a ‘multi-process’ machine that students could use for CNC Milling, 3D Printing, as well as PCB Milling, we later decided to downgrade the scope and develop a standalone PCB Mill.

So, this was:

• the design of a machine kit to be produced in-house on a printer farm
• the assembly of 30 kits,
• the development and assembly of a machine controller for the same,
• documentation for students: how to assemble the kit, how to run the controller

Given our small class size, this turned out to be a feasible exercise and in the end things ‘worked’ - students were all able to assemble their kits and used them to complete PCB fabrication assignments.

However, it is hard to say if this approach (designing our own machine, our own controller) was indeed any better than simply purchasing off the shelf machines and controllers. Our final machine BOM totalled around $400 for hardware and an additional$160 for controllers. In some regards, we were using this as an experiment to test our internally developed machine systems - so the value makes sense on our end, but doesn’t necessarily make it a repeatable exercise.

The primary interest was in building a machine that was easy to assemble and understand for students - that was largely a design exercise, and difficult to evaluate. Given that we didn’t appropriately query students on their experience, it’s hard to say whether this was successful. Some did use Clank design elements in their final project, and some were also able to use parts of it’s control system in their project (i.e. hijacking the power supply to drive their creation). This is the aspiration: that what we provide students is extensible so if i.e. they would like to develop a new end-effector for a machine, or some project driven with stepper motors, they can take design principles and entire parts of the machine kit in order to do so.

The cost of hardware - $400 - is largley eaten up in the spindle assembly, totalling$150, and a surprising amount of PLA, $72 worth per machine. Cables, plugs, and the PSU itself were another$90. Each of these aspects could be cost reduced.

The cost of 3DP fabrication was low initially but tending a print farm is not a small job, I found myself in the lab every day (sometimes twice) for about three weeks. A big take-away here was to organize build plates into long (~16 hour) and short (~ 6-8 hour) shifts - this minimized massive jobs of ~24 hours (liable to fail) but allowed me to be in lab twice a day (in the mornings, and then afternoons) to keep printers running around the clock. We used Prusa MK3 printers and I was careful to make sure bed adhesion was maximal whenever changing a print - cleaning and prepping (with glue stick) each job. I later discovered some specialized adhesion agents that work even better, and would use them if I were to do this a second time.

I think that the value for students of having on TA staff the individual who designed the machine is worth noting. This is my own experience: when I was younger, I never imagined I would become any kind of programmer. I understood it to be a thing that humans did, but it was only until I met some talented programmers myself that I realized this was indeed something that mortals did, and became confident enough to see myself doing it - that’s when I started learning. I would like to hope that, because students could meet and interact with me (although virtually) and also build my machine hands-on, they saw that this kind of project is something which can be undertaken without a huge amount of learning beforehand.

### Machine Documentation

While written documentation is great, I spent just two days filming a series of build videos for Clank - students reported that these were invaluable. I did this with an overhead camera, and simply built the machine start to finish on the desk. When I felt like it, I would make comments on the machine’s design, or other mechanical subtleties: the use of a flathead screw vs. a socket head screw, bearing preload, kinematics, belt stiffness, etc.

These videos are available in the repo’s build log.

We also provided relatively complete (i.e. having machine screws, bearings, etc in-model) CAD files in various formats to students, for their reference. Since they were simultaneously learning the same CAD platform that the machine was developed in, this was a great way to document as well as increase comfort in the program; a bit like seeing the source code of a piece of software while learning it’s API.

## In Conclusion

The exercise was certainly worth our time as researchers, and I personally understand better the scope of projects I am able to complete, when focused. However, given more time, it would have been valuable for other educators had we focused on developing a platform more well tailored to education. As it stands, Clank represents a research direction that was put on pause in order to develop what looks like a kind of ‘product’ - vestigial aspects (overbuilt mechanism and controllers) that did not have enough work on their front-ends to serve novices.

So the lesson, as in most projects, is to try to do better in defining scope & expected outcome at the start, instead of rushing in to make some cool machines and spend a lot of time without any clear output.

That said, looks like the frontier of labs-building-machines-for-labs is approaching, and this was a worthwhile first-shot random-walk for an answer. Next time we’ll choose machine specialization over machine generalization when we want to build extremely low-cost, low-complexity tools for students.

### Output

To see student work, you can browse the students’ documentation itself. There’s also a video of the final reviews where final thoughts / etc start around 2:14:54.

## Issues

Just to keep track, here are some things that arose during the course of the term, in no particular order:

### Controller Issues

• z motors overheating
• a configuration error on my part meant that default firmware for z-motor controllers drove 2x the necessary energy into the motors, causing them to get hot. a firmware fix (flashed by students, or TAs when they were unable to) fixed this
• stop-and-go buffers
• the browser interface dishes new moves to the controller on the JS event loop. when the browser is not in focus (another tab is open, for example) the event loop slows down. this would occasionally starve the buffer causing the machine to effectively pause, but bringing the tab back in focus ameliorated this.
• a workaround would involve some different buffering structure i.e. in the local node.js instance, which does not lose event loop timing performance ever
• again with the buffers, the embedded code buffered about 64 moves and the browser ‘pause’ only stopped new ones from being transmitted. so if a student ‘paused’ the machine, up to 64 (potentially long) moves had to clear from the low level buffer before the machine would actually stop
• motion control across scales is hard and requires some buffering. we are looking at cleaner motion control implementations that marry high & low level controller at higher fideltiy to do better
• a number of students had USB cables that included power lines, but no data lines (in the hardware… cable) these cables are commonly provided by vendors of (cheap) hardware, to charge via USB’s built-in 5v supply. they do not transmit data. these caused confusion, but swapping cables worked.
• provide a trusted cable, we forgot to
• some (still mysterious) electrical events caused flash memory on micros to be erased, meaning bootloaders and code needed to be re-flashed, normally by a TA.
• enable students to flash firmware more-better
• develop an isolated PHY that prevents these kinds of events from knocking out entire systems (likely that GND planes tied together on RS485 link caused these issues).
• loose connectors
• the circuits use IDC connectors on 0.1” pitch headers, nice and simple. latching and non-latching connectors (plugs) exist for both: pick the latching type, non-latching would sometimes vibrate loose and cause havok.

### Hardware Issues

• supply chain
• a late supply chain error meant that the spindle had to be re-designed. this was unfortunate, but surmountable. don’t use niche parts. in this case it was an C8-ER11A-100L Collet Chuck Extension Rod ‘collet holder’
• loose belts
• a few students did not properly tension belts, resulting in sloppy traces. this could have been stressed more in documentation
• loose screws
• the same: these kinds of things are largely ‘by feel’ and some missed, could do better in documentation to emphasize
• set screws
• also loose here: most hardware on the machine are nylock inserts, meaning that things do not come loose over time. the set screws that hold pulleys onto motors are just small threaded aluminum set screws, and were likely to vibrate loose over time.
• spindle direction
• some bad traces were eventually attributed to spindles rotating the wrong direction. this was only briefly mentioned in the doc, and some students missed it. changing direction is easy, but needed to be noticed.
• tool changing notes
• it wasn’t extensively clear how to properly change a tool: could do better to document this process