First off, don’t worry: this isn’t one of THOSE kinds of posts.

Well, I mean, it MIGHT be; depending on what you were thinking when I said “those”.

The point is that this is a story about failure but not, like, in a bad way? Like, no one died. I didn’t commit some kind of massive faux pa. I don’t need to apologize. I just tried something I’ve been wanting to do for a while, didn’t accomplish what I wanted to accomplish, but I feel totally okay with it.

Here; let me try this again.

I tried making a thing and it didn’t end up working but that’s okay because I finally learned to accept that failure is a fundamental part of growth and is intrinsic possibility to any attempt.

what a hook.

A pen plotter is a machine which, using a pen or other marking implement, draws shapes or text on paper. It’s a pretty nifty machine but has more or less been made obsolete by large format printers.

To make a pen plotter, what you need is a way to move a pen in both the X axis and Y axis relative to a peice of paper and a way to raise and lower the pen so you can make gaps between marks (to see what not being able to do that is like, play with an Etch-a-Sketch).

✿.｡.:* ☆::. 𝒯𝒶-𝒹𝒶𝒶𝒶 .::.☆*.:｡.✿

This is something I’ve been wanting to build for a long time. If you google “CD Drive Pen Plotter” there are is no shortage of examples. Basically, you take the drive tray mechanism out of two cd drives, attach wires to the stepper motors, make something to raise and lower the pen, and get an arduino to run the whole mess.

Easy Peasy.

BUT, there is “easy peasy in theory” and “easy peasy in practice”. The devil is in the details and he lives in integration hell: the final steps of any project where you try to marry several perfectly functional systems into one cohesive one. For software engineers, this can manifest in getting a bit of code you wrote to work correctly with an existing codebase. For mechanical systems engineers, it can come in the form of having to marry control interfaces for multiple systems. For game devs, it can be getting one physics system to work with a collision system. Whatever your particular niche, integration hell lives in the last 10-20% of any given project over a certain degree of complexity.

The hardware of the X and Y movement wasn’t easy per-se, but it was straightforward. Gather the critical dimensions, make some digital stand-ins in CAD (in my case, Tinkercad), and go from there. Most people, I imagine, use Tinkercad for 3D Printing; but I also use it for designing in 3D for laser cutting which is how I decided to make the frame for my pen plotter.

No one can understate how revolutionary 3D printing has been for the maker community. That said, if what you’re designing can be distilled to 2D shapes, laser cutting is orders of magnitude faster. I have a healthy amount of 3mm birch plywood that I’ve been using for another project, so I decided to use that for here as well.

The pen movement mechanism was a different kettle of fish, though. In designing it, I settled on three requirements:

1. It needed to use a Servo. This was mostly due to the accessability of the servo pins on the adafruit motor shield.
2. The pen had to auto return to the up position.
3. The system needed to have some flexibility because, well, it’s a machine made of recycled parts and krazy glue.

Here’s the breakdown of the mechanism.

The pen holder slides within the inner pen carriage. The bore is designed to be a little bigger than the widest diameter of a standard sharpie and has a hole for a M5 bolt (threaded with an M5 Tap) to thread into and keep the pen in place.

A 3d printed linear spring is slid into the inner pen carriage rail after the pen holder and krazy glued down at the top end, capturing the pen holder. When the pen mechanism is in the down position, this spring provides just enough downward pressure to keep the pen in contact with the work surface while also allowing it to move up a little in case there work surface isn’t perfectly perpendicular to the x-axis.

The inner pen carraige then slides into the outer pen rail, which is attached to the X-axis. Another linear spring is then sandwiched between the top stop of the inner carriage and the top surface of the outer pen rail. This spring is meant to keep the inner carriage in contact with the servo horn by compressing when it rotates clockwise to move the pen down and relaxing when the servo turns counter clockwise to move the pen up.

This combination of springs and rails has proven to be a pretty reliable motion system with no non-3d printed parts needed.

Where the rubber meets the code.

Arduinos are incredibly versatile microcontrollers. In fact, I feel safe saying the chips that run them are the foundation of most 3d printers and lasers out in the world today. When building this, I honestly felt like the software part was going to be the least hassle out of everything that needed doing.

This was very wrong.

My plan was to use the GRBL firmware which would have let this fun little gadget communicate and be controlled by just about any off the shelf software that can send GCODE. It was going to be EASY. After all, it’s an arduino which is what GRBL was made for. And the Adafruit motor shield is one of the most common motor shields for arduinos.

SURELY THIS SHOULD BE PLUG AND PLAY, RIGHT?

Turns out that GRBL dosent support the H-Bridge drivers on the adafruit motor shield. Not that it can’t work, but you would need to rewrite a major portion of it and I wasn’t willing to do that. There is a way to kind of half-ass it. Basically you tell the arduino how to parse the smallest subset of GCODE commands needed. Then you use a custom GCODE sender to take GCODE commands made in another program like Inkscape, perform some jiggery pokery on them, and then send those to the arduino.

Basically, it’s like instead of teaching a toddler how to read, you only taught them the words they’d encounter in “See Spot Run”. They could say those words in any order you gave it to them, but nothing else. They wouldn’t even know how to react to other words.

In the end, it doesn’t work. I could probably get it working if I spent a few days really trying but, honestly, I don’t feel compelled to do so. Functionally, this doesn’t even do anything I would need it do do. The total working area is around 40mm x 40mm, which isn’t even enough to fill a post-it note.

THEN WHY??!!

I wouldn’t go so far as to call it a bucket list item, but if there’s a maker/DIY-er equivalent, this is on it. And, in the end, I learned a lot. I learned a lot about 3d printable springs, about issues with motion systems, about how to compensate for slop in designs… lots of stuff.

But, mostly, because it was just fun to make something that didn’t have a purpose. To make something just because.

But then there’s the aspect of it that’s a failure. That part can be hard to reckon with. Objectively, the thing I set out to make does not work. Even if Iearned from it, it’s still a failure. Failing is simultanously the easiest thing to do and the hardest thing to accept. Because it’s hard not to make it a moral refferendum on yourself instead of the unavoidable part of the growth and learning process that it is.

SHAME. SHAME ON YOU FOR NOT GETTING SOMETHING YOU’VE NEVER DONE BEFORE RIGHT THE FIRST TIME. SHAAAAAAAAME.

Which is dumb. But here we are.

So growth is, I guess, being able to go “Whelp, that didn’t go as planned, but it’s not the end of the world and, really, I still got something out of trying, and it was all for fun anyways so why bring the whole situation down with having expectations and shame and shit?”