Author: Elliot Williams

1365 Articles

Matthias Wandel Hates CNC Machines In Person

February 9, 2025 by 18 Comments

Prolific woodworking YouTuber [Matthias Wandel] makes some awesome mechanical contraptions, and isn’t afraid of computers, but has never been a fan of CNC machines in the woodshop. He’s never had one either, so until now he couldn’t really talk. But he had the parts on hand, so he built a wooden CNC router. It’s lovely.

The router itself is what 3D printer folks would call a bed-slinger, and it’s cobbled together out of scrap plywood. Some of the parts have extra holes drilled in them, but “measure once, drill twice” is our motto, so we’re not one to judge. He spends a lot of time making “crash pads” that keep the frame from destroying itself while he’s building it – once the CNC is actually controlling things with the limit switches, we presume they won’t be necessary, but their design is fun anyway.

If you’re at all interested in CNC machines, you should give this video a watch. Not because it’s done the “right” way, but because it’s a CNC that’s being built on a budget from first principles, by an experienced wood builder, and it’s illuminating to watch him go. And by the end of the video, he is making additional parts for the machine on the machine, with all the holes in the right places, so he’s already stepping in the right direction.

He doesn’t love digital design and fabrication yet, though. If you’re making one-offs, it probably isn’t worth the setup time to program the machine, especially if you have all of his jigs and machines at your disposal. Still, we kind of hope he’ll see the light.

Of course, this isn’t the first wooden CNC router we’ve seen around these parts, and it probably won’t be the last. If you want to go even more fundamental, [Homo Faciens]’s series of CNC machines is a lovely mashup of paperclips and potential. Or, if refinement is more your style, this benchtop machine is the bee’s knees.

Continue reading “Matthias Wandel Hates CNC Machines In Person” →

Software In Progress

February 8, 2025 by 65 Comments

Open source software can be fantastic. I run almost exclusively open software, and have for longer than I care to admit. And although I’m not a serious coder by an stretch, I fill out bug reports when I find them, and poke at edge cases to help the people who do the real work.

For 3D modeling, I’ve been bouncing back and forth between OpenSCAD and FreeCAD. OpenSCAD is basic, extensible, and extremely powerful in the way that a programming language is, and consequently it’s reliably bug-free. But it also isn’t exactly user friendly, unless you’re a user who likes to code, in which case it’s marvelous. FreeCAD is much more of a software tool than a programming language, and is a lot more ambitious than OpenSCAD. FreeCAD is also a program in a different stage of development, and given its very broad scope, it has got a lot of bugs.

I kept running into some really serious bugs in a particular function – thickness for what it’s worth – which is known to be glitchy in the FreeCAD community. Indeed, the last time I kicked the tires on thickness, it was almost entirely useless, and there’s been real progress in the past couple years. It works at least sometimes now, on super-simple geometries, and this promise lead me to find out where it still doesn’t work. So I went through the forums to see what I could do to help, and it struck me that some people, mostly those who come to FreeCAD from commercial programs that were essentially finished a decade ago, have different expectations about the state of the software than I do, and are a lot grumpier.

Open source software is working out its bugs in public. Most open source is software in development. It’s growing, and changing, and you can help it grow or just hang on for the ride. Some open-source userland projects are mature enough that they’re pretty much finished, but the vast majority of open-source projects are coding in public and software in progress.

It seems to me that people who expect software to be done already are frustrated by this, and that when we promote super-star open projects like Inkscape or Blender, which are essentially finished, we are doing a disservice to the vast majority of useful, but still in progress applications out there that can get the job done anyway, but might require some workarounds. It’s exactly these projects that need our help and our bug-hunting, but if you go into them with the “finished” mentality, you’re setting yourself up for frustration.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Time Vs Money, 3D Printer Style

February 1, 2025 by 28 Comments

A few months ago, Hackaday’s own Al Williams convinced me to buy a couple of untested, returned-to-manufacturer 3D printers. Or rather, he convinced me to buy one, and the incredible success of the first printer spurred me on to the second. TL;DR: Lightning didn’t strike twice, but I’d still rate it as worth my time. This probably isn’t a good choice for your first printer, but if you’ve done the regular maintenance on your first printer already, I’d recommend it for your second or twelfth.

As background, Al has been volunteering with local schools to teach a 3D printing summer class, and this means outfitting them with a 3DP lab on the dirt cheap. His secret is to buy last year’s model which has all of the features he needs – most importantly for the kids, automatic bed height probing – but to buy it from the scratch-and-dent shelf at Creality. Why? Because they are mid-grade printers, relatively new, but on deep discount.

How deep? I found an essentially endless supply of printers that retail for $300 on discount for $90 each. The catch? It might work, it might not. I bought my son one, because I thought that it would at least make a good project for us to work on together. Those plans were spoiled – it worked absolutely flawlessly from the moment we bolted it together, and he runs 24-hour jobs on the thing without fear. From the look of the build plate, it had been used exactly once and returned for whatever reason. Maybe the owner just didn’t want a 3D printer?

The siren song of straightforward success was too much for me to resist, and I picked another up to replace my aging A8 which was basically a kit for a 3D printer, and not a particularly good one at that, but could be made to work. My scratch-and-dent Creality came with a defective bed-touch sensor, which manifest itself as a random absolute refusal to print.

I took it apart, but the flaw is in the design of the V1 touch sensors – the solenoid requires more current to push down than the 3DP motherboard can reliably deliver. It works 100% of the time on my bench power supply, but in situ it fails about 30% of the time, even after hitting it with graphite and making sure everything is mechanically sound. Creality knows this and offers a free trade-in, just not for me. The new version of the Creality probe costs $50 new, but you can get cheap knock-off BL Touch models for $14. Guess what I did?

And guess what bit me? The cheapo touch probe descends a bit slower than the Creality version should, and the firmware is coded to time-out in an extra-short timeframe. Thankfully, Creality’s modifications to Marlin are all open source, and I managed to tweak and flash a new firmware that made it work 100% of the time, but this was at a cost of probably eight hours of bug-hunting, part-ordering, and firmware-compiling. That said, I got some nice extra features along the way, which is the advantage of a printer running open-source firmware.

So my $300 printer cost me $105, plus eight hours of labor. I only charge one coffee per hour for fun hardware debugging tasks, but you may have a different valuation. Taken together with my son’s printer, we have $600 worth of printer for under $200 plus labor, though, which starts to sound a little better.

Is gambling on an untested return 3D printer worth it? For us, I would say it was, and I’d do it again in a few years. For now, though, we’ve got three printers running and that’s all we need. Have you gone down this perilous path?

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

Supercon 2024: Joshua Wise Hacks The Bambu X1 Carbon

January 29, 2025 by 36 Comments

Bambu Labs have been in the news lately. Not because of the machines themselves, but because they are proposing a firmware change that many in our community find restricts their freedom to use their own devices.

What can be done? [Joshua Wise] gave a standout talk on the Design Lab stage at the 2024 Hackaday Superconference where he told the tale of his custom firmware for the Bambu X1 Carbon. He wasn’t alone here; the X1 Plus tale involves a community of hackers working on opening up the printer, but it’s also a tale that hasn’t ended yet. Bambu is striking back. Continue reading “Supercon 2024: Joshua Wise Hacks The Bambu X1 Carbon” →

Networking History Lessons

January 25, 2025 by 34 Comments

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

This QR Code Leads To Two Websites, But How?

January 23, 2025 by 44 Comments

QR codes are designed with alignment and scaling features, not to mention checksums and significant redundancy. They have to be, because you’re taking photos of them with your potato-camera while moving, in the dark, and it’s on a curved sticker on a phone pole.  So it came as a complete surprise to us that [Christian Walther] succeeded in making an ambiguous QR code.

Nerd-sniped by [Guy Dupont], who made them using those lenticular lens overlays, [Christian] made a QR code that resolves to two websites depending on the angle at which it’s viewed. The trick is to identify the cells that are different between the two URLs, for instance, and split them in half vertically and horizontally: making them into a tiny checkerboard. It appears that some QR decoders sample in the center of each target square, and the center will be in one side or the other depending on the tilt of the QR code.

Figuring out the minimal-difference QR code encoding between two arbitrary URLs would make a neat programming exercise. How long before we see these in popular use, like back in the old days when embedding images was fresh? QR codes are fun!

Whether it works is probably phone- and/or algorithm-dependent, so try this out, and let us know in the comments if they work for you.

Thanks [Lacey] for the tip!

 

Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda

January 23, 2025 by 6 Comments

If hacking on consumer hardware is about figuring out what it can do, and pushing it in directions that the manufacturer never dared to dream, then this is a very fine hack indeed. [Portasynthica3] takes on the Yamaha PSR-E433, a cheap beginner keyboard, discovers a shell baked into it, and takes it from there.

[Portasynthinca3] reverse engineered the firmware, wrote shellcode for the device, embedded the escape in a MIDI note stream, and even ended up writing some simple LCD driver software totally decent refresh rate on the dot-matrix display, all to support the lofty goal of displaying arbitrary graphics on the keyboard’s dot-matrix character display.

Now, we want you to be prepared for a low-res video extravaganza here. You might have to squint a bit to make out what’s going on in the video, but keep in mind that it’s being sent over a music data protocol from the 1980s, running at 31.25 kbps, displayed in the custom character RAM of an LCD.

As always, the hack starts with research. Identifying the microcontroller CPU lead to JTAG and OpenOCD. (We love the technique of looking at the draw on a bench power meter to determine if the chip is responding to pause commands.) Dumping the code and tossing it into Ghidra lead to the unexpected discovery that Yamaha had put a live shell in the device that communicates over MIDI, presumably for testing and development purposes. This shell had PEEK and POKE, which meant that OpenOCD could go sit back on the shelf. Poking “Hello World” into some free RAM space over MIDI sysex was the first proof-of-concept.

The final hack to get video up and running was to dig deep into the custom character-generation RAM, write some code to disable the normal character display, and then fool the CPU into calling this code instead of the shell, in order to increase the update rate. All of this for a thin slice of Bad Apple over MIDI, but more importantly, for the glory. And this hack is glorious! Go check it out in full.

MIDI is entirely hacker friendly, and it’s likely you can hack together a musical controller that would wow your audience just with stuff in your junk box. If you’re at all into music, and you’ve never built your own MIDI devices, you have your weekend project.

Continue reading “Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda” →