Speak To The Machine

January 28, 2023 by Elliot Williams 16 Comments

If you own a 3D printer, CNC router, or basically anything else that makes coordinated movements with a bunch of stepper motors, chances are good that it speaks G-code. Do you?

If you were a CNC machinist back in the 1980’s, chances are very good that you’d be fluent in the language, and maybe even a couple different machines’ specialized dialects. But higher level abstractions pretty quickly took over the CAM landscape, and knowing how to navigate GUIs and do CAD became more relevant than knowing how to move the machine around by typing.

a Reprap Darwin — Reprap Darwin: it was horrible, but it was awesome.

Strangely enough, I learned G-code in 2010, as the RepRap Darwin that my hackerspace needed some human wranglers. If you want to print out a 3D design today, you have a wealth of convenient slicers that’ll turn abstract geometry into G-code, but back in the day, all we had was a mess of Python scripts. Given the state of things, it was worth learning a little G-code, because even if you just wanted to print something out, it was far from plug-and-play.

For instance, it was far easier to just edit the M104 value than to change the temperature and re-slice the whole thing, which could take an appreciable amount of time back then. Honestly, we were all working on the printers as much as we were printing. Knowing how to whip up some quick bed-levelling test scripts and/or demo objects in G-code was just plain handy. And of course the people writing or tweaking the slicers had to know how to talk directly to the machine.

Even today, I think it’s useful to be able to speak to the machine in its native language. Case in point: the el-quicko pen-plotter I whipped together two weekends ago was actually to play around with Logo, the turtle language, with my son. It didn’t take me more than an hour or so to whip up a trivial Logo-alike (in Python) for the CNC: pen-up, pen-down, forward, turn, repeat, and subroutine definitions. Translating this all to machine moves was actually super simple, and we had a great time live-drawing with the machine.

So if you want to code for your machine, you’ll need to speak its language. A slicer is great for the one thing it does – turning an STL into G-code, but if you want to do anything a little more bespoke, you should learn G-code. And if you’ve got a 3D printer kicking around, certainly if it runs Marlin or similar firmware, you’ve got the ideal platform for exploration.

Does anyone else still play with G-code?

Too Many Pixels

January 14, 2023 by Elliot Williams 39 Comments

Sometimes simpler is more impressive than complicated, and part of this is certainly due to Arthur C. Clarke’s third law: “Any sufficiently advanced technology is indistinguishable from magic.”. It’s counter-intuitive, though, that a high-tech project would seem any less amazing than a simpler one, but hear me out.

I first noticed this ages ago, when we were ripping out the blue laser diodes from Casio XJ-A130 laser projectors back when this was the only way to get a powerful blue laser diode. Casio had bought up the world’s supply of the 1.5 W Nichias, and was putting 24 of them in each projector, making them worth more dead than alive, if you know what I mean. Anyway, we were putting on a laser show, and the bright blue diode laser was just what we needed.

RGB Laser show — A sweeter setup than mine, but you get the idea.

Color laser setups take three or more different lasers, combine the beams, and then bounce them off of mirrors attached to galvos. Steer the mirrors around, and you can project vector images. It’s pretty cool tech, and involves some serious fine-tuning, but the irony here is that we were tearing apart a device with 788,736 microscopic DLP mirrors to point the lasers through just two. And yet, a DIY laser show is significantly cooler than just putting up your powerpoint on the office wall.

The same thing goes for 2D plotting machines like the AxiDraw. The astonishing tech behind any old laser printer is mind-numbing. Possibly literally. Why else would we think that art drawn out by a pen in the hands of a stepper-powered robot is cooler than the output of a 1600 DPI unit coming from HP’s stable? I mean, instead of running an hours-long job to put ink on paper with a pen, my Laserjet puts out an image in ten seconds. But it’s just not as much fun.

So here we are, in an age where there’s so darn much magic all around us, in the form of sufficiently advanced technology, that comprehensible devices are actually more impressive. And my guess is that it’s partly because it’s not surprising when a device that’s already magic does something magical. I mean, that’s just what it’s supposed to do. Duh!

But when something beautiful emerges from a pair of mirrors epoxied to shafts on springs turned by copper coils, that’s real magic.

Happy New Year, Hackaday!

January 7, 2023 by Elliot Williams 4 Comments

[Tom Nardi] and I were talking on the podcast about 2022, and how it went from the hacker’s perspective. As the global chip shortage entered its second full year, we both thought back on the ways that we all had to adapt and work around the fact that we just couldn’t get the parts we were accustomed to picking up with ease.

What had previously been an infinite supply of knockoff Arduino clones and STM32 Blue Pill boards all of a sudden just dried up. Sometimes you just couldn’t get the DAC chip you wanted, or at least not without many weeks’ lead time, and even then, it’d cost you. Raspberry Pi single-board computers became hard to find. PCB designs had to change and new SDKs needed to be learned. I know I had to grab twice for unfamiliar microcontroller platforms this year.

We hacked around the problems. It would be absurd to say that the chip shortage wasn’t a pain in the posterior, but in the end we all managed to carry on and keep creating. We created more flexible footprints, learned to design around what we could get, and definitely had to do more planning. We pulled parts for projects out of the junk box or shelf stock. Or, as Tom noted, we did what everyone in the parts of the world who aren’t as fortunate to get free expedited shipping does – we made do.

Making do often meant learning new environments, questioning old habits, and double-checking pinouts. But if you’re like me, not all of that time was wasted. Sometimes it’s good to get shaken out of comfy workflows, even if by force. So while we wish you parts-in-stock and easy availability for 2023, don’t forget the lessons learned from 2022. Stay scrappy, Hackaday!

In Praise Of “Just Because” Hacks

December 31, 2022 by Elliot Williams 25 Comments

Sometimes you pick a project because the world needs it to be done. Or maybe you or a friend need it. Or maybe you don’t really need it, but it fulfills a longstanding dream. In my mind, the last stop before you reach “why am I doing this” is the “just because” hack.

The ideal “just because” hack is limited in scope. You don’t want to spend years on a whimsical project, and because of this a “just because” hack isn’t usually motivating enough to keep you going that long anyway, except for the tenacious few. A “just because” doesn’t necessarily have to be an easy win, but it makes sense for you to see your way out before you get in too deep.

I’m not sure if it’s the Baader-Meinhof phenomenon or not, but in the last week or so in the Hackaday universe, a lot of people have been singing the praises of “just because” hacks. (Check out this one discussion, for instance.) Mostly, it’s a combination of them turning out better than initially thought, or it’s about the learning that came along for the ride. Of course, many of them spin off into longer, serious projects even if they didn’t start that way.

Not everything in life can be frivolous, of course. But that makes the “just because” hack that much sweeter, and you should try to make mental room for them if you can. When the stakes are low, creativity can be high. You might still want to impose a deadline, lest you fall into eternal yak shaving, but take it easy. You don’t need a justification all the time: the journey can be the destination.

Yesterday’s Future Is Brighter Today

December 17, 2022 by Elliot Williams 31 Comments

The demoscene never ceases to amaze. Back in the mid-80s, people wouldn’t just hack software to remove the copy restrictions, but would go the extra mile and add some fun artwork and greetz. Over the ensuing decade the artform broke away from the cracks entirely, and the elite hackers were making electronic music with amazing accompanying graphics to simply show off.

Looked at from today, some of the demos are amazing given that they were done on such primitive hardware, but those were the cutting edge home computers at the time. I don’t know what today’s equivalent is, with CGI-powered blockbusters running in mainstream cinemas, the state of the art in graphics has moved on quite a bit. But the state of the old art doesn’t rest either. I’ve just seen the most amazing demo on a ZX Spectrum.

Simply put, this demo does things in 2022 on a computer from 1982 that were literally impossible at the time. Not because the hardware was different – this is using retro gear after all – but because the state of our communal knowledge has changed so dramatically over the last 40 years. What makes 2020s demos more amazing than their 1990s equivalents is that we’ve learned, discovered, and shared enough new tricks with each other that we can do what was previously impossible. Not because of silicon tech, but because of the wetware. (And maybe I shouldn’t underestimate the impact of today’s coding environments and other tooling.)

I love the old demoscene, probably for nostalgia reasons, but I love the new demoscene because it shows us how far we’ve come. That, and it’s almost like reverse time-travel, taking today’s knowledge and pushing it back into gear of the past.

Fossil Files: My .Emacs

December 10, 2022 by Elliot Williams 63 Comments

Last week, I wrote about cargo culting in a much more general context, so this week I’m going to come clean. The file that had me thinking about the topic was the worst case you’ve probably ever seen: I have a .emacs file kicking around that I haven’t really understood since I copied it from someone else – probably Ben Scarlet whose name is enshrined therein – in the computer lab in 1994! Yes, my .emacs file is nearly 30, and I still don’t really understand it, not exactly.

Now in my defence, I switched up to vim as my main editor a few years ago, but this one file has seen duty on Pentiums running pre-1.0 versions of Linux, on IBM RS/6000 machines in the aforementioned computer lab, and on a series of laptops and desktops that I’ve owned over the years. It got me through undergrad, grad school, and a decade of work. It has served me well. And if I fired up emacs right now, it would still be here.

For those of you out there who don’t use emacs, the .emacs file is a configuration file. It says how to interpret different files based on their extensions, defines some special key combos, and perhaps most importantly, defines how code syntax highlighting works. It’s basically all of the idiosyncratic look-and-feel stuff in emacs, and it’s what makes my emacs mine. But I don’t understand it.

Why? Because it’s written in LISP, for GNU’s sake, and because it references all manner of cryptic internal variables that emacs uses under the hood. I’m absolutely not saying that I haven’t tweaked some of the colors around, or monkey-patched something in here or there, but the extent is always limited to whatever I can get away with, without having to really learn LISP.

This ancient fossil of a file is testament to two things. The emacs codebase has been stable enough that it still works after all this time, but also that emacs is so damn complicated and written in an obscure enough language that I have never put the time in to really grok it – the barriers are too high and the payoff for the effort too low. I have no doubt that I could figure it out for real, but I just haven’t.

So I just schlep this file around, from computer to computer, without understanding it and without particularly wanting to. Except now that I write this. Damnit.

Featured image: “A Dusty Old Book” by Marco Verch Professional.