You Draw It, CNC Cuts It

March 24, 2022 by Elliot Williams 13 Comments

[Jamie] aka [vector76] hit us with a line-tracing plugin for OctoPrint that cuts out whatever 2D shape you draw on a piece of wood. The plugin lets you skip the modeling step entirely, going straight from a CNC-mounted webcam that reads your scribbles and gives you a Gcode toolpath in return. The code is on GitHub and there’s a demo video embedded below.

Under the hood, OpenCV is doing a lot of the image processing, including line detection, and the iterative “find the line” and “move the toolhead” steps really show off what computer vision can do. It starts off with a fiducial arrow for scale and orientation, then it mores the webcam around the scene. The user can enter the usual milling parameters: speeds, feeds, depth of cut, tool offset, milling direction, etc. And then it gets to work.

Right now, it’s limited to paths with non-crossing lines, and probably with good contrast and a nice dark line — all the usual CV restrictions. But mounting a webcam to a CNC toolhead and using it for various pathing problems really opens up tons of possibilities: visual homing, workpiece edge finding, copying parts, custom fitting odd shapes, and more. This project is clearly an invitation to keep on hacking, an appetizer. Once you see the girl pirate robot that [Jamie]’s daughter made, you’ll get the idea.

We’ve seen a similar OpenCV approach used for center-finding bore holes, but while we’ve seen a few webcams used with laser cutters, the CNC mill applications seem largely untapped. Let us know in the comments if you’ve got some other good examples.

Continue reading “You Draw It, CNC Cuts It” →

Make It Compatible

March 12, 2022 by Elliot Williams 25 Comments

I’m probably as guilty as anyone of reinventing the wheel for a subpart of a project. Heck, sometimes I just feel like working on a wheel design. But if that’s the path you choose, you have to think about whether or not it’s important that others can replicate your project. The nice thing about a bog-standard wheel is that everyone has got one.

The case study I have in mind is a wall-plotter project that appeared on Hackaday this week. It’s a really sweet design, and in many ways would be an ideal starter project. I actually need a wall plotter (for reasons) and like a number of the choices made. For instance, having nearly everything, including the lightweight geared steppers on the gondola makes it easy to install and uninstall — you just pin up the timing belt from which it hangs and you’re done. Extra weight on the gondola helps with stability anyway. It’s open source and based on the Arduino libraries, so it should be easy enough to port to whatever microcontroller I have on hand.

But the image-generation toolchain is awkward, involving cutting and pasting into a spreadsheet, which generates a text file in a custom plotting micro-language. Presumably the designer doesn’t know about Gcode, which is essentially the lingua franca of moving machines, or just didn’t feel like implementing it. Where in Gcode, movement commands are like “G1 X100 Y50”, this device expects “draw_line(0,0,100,50)”. They’re essentially equivalent, but incompatible.

I totally understand that the author must have had a good time thinking up the movement commands and writing the spreadsheet that translates SVG files into them. I’ve been there and done that! But if the wall plotter spoke Gcode instead of its own dialect, it would slot instantly into any number of graphics processing workflows, which would make me, the potential user, happier.

When you are looking at reinventing the wheel, think about your audience. If you’re the only person likely to see the project, go ahead and scratch whatever itch you’ve got. You’ll learn more that way. But if you want to share the project with as many people as possible, adhering to the most widely used standards is a good choice for your users, even if it is less fun than dreaming up your own movement language.

Multiple Ways Of Recovering A Failed Print

February 4, 2022 by Matthew Carlson 5 Comments

It’s a special gut-dropping, grumbly moment that most who use 3d printers know all too well. When you check on your 13-hour print, only to see that it failed printing several hundred layers ago. [Stephan] from [CNC Kitchen] has a few clever tricks to resume failed prints.

It starts when you discover your print has failed and whether the part is still attached to the bed. If it has detached, the best you can do is whip out your calipers to get a reasonably accurate measurement of how much has been printed. Then slice off the already printed section, print the remainder, and glue the two parts together. If your part is attached to your print bed and you haven’t shifted the plate (if it is removable), start by removing any blemishes on the top layer. That will make it smooth and predictable as it’s starting a new print, just on top of an existing one. Measuring the height that has been printed is tricky since you cannot remove it. Calipers of sufficient length can use their depth function, but you might also be able to do a visual inspection if the geometry is unique enough. After you load up your model in a G-Code viewer, go through it layer by layer until you find what matches what has already been printed.

The last (and perhaps most clever) is to use the printer as a makeshift CMM (coordinate measuring machine). You manually step the printer until it touches the top of the part, then read the z-axis height via a screen or M114 command. A quick edit to the raw G-Code gives you a new file that will resume precisely what it was doing before. If you can’t rehome because the head can’t clear the part, [Stephan] walks you through setting the home on your printer manually.

If all the doesn’t work, and the print is still unrecoverable, perhaps you can look into recycling the plastic into new filament.

The Wanhao Duplicator CNC Heat Sealer

February 2, 2022 by Dave Rowntree 19 Comments

One custom, compliant heat exchanger, coming right up!

[Thane Hunt] needed to find a way to make a variety of different heat-seal patterns on a fluid heat exchanger made from polyolefin film, and didn’t want all the lead time and expense of a traditional sealing press machined from a steel plate. Pattern prototyping meant that the usual approach would not allow sufficient iteration speed and decided to take a CNC approach. Now, who can think of a common tool, capable of positioning in the X-Y plane, with a drivable Z axis and a controlled heat source? Of course, nowadays the answer is the common-or-garden FDM 3D printer. As luck would have it, [Thane] had an older machine to experiment with, so with a little bit of nozzle sanding, and a sheet of rubber on the bed, it was good to go!

Now, heat sealing is usually done in a heated press, with a former tool, which holds the material in place and gives a flat, even seal. Obviously this CNC approach isn’t going to achieve perfect results, but for proof-of-concept, it is just fine. A sacrificial nozzle was located (but as [Thane] admits, a length of M6 would do, in a pinch) and sanded flat, and parallel to the bed, to give a 3mm diameter contact patch. A silicone rubber sheet was placed on the bed, and the polyolefin film on top. The silicone helped to hold the bottom sheet in place, and gives some Z-axis compliancy to prevent overloading the motor driver. Ideally, the printer would have been modified further to move this compliancy into the Z axis or the effector end, but that was more work. With some clever 3D modelling, Cura was manipulated to generate the desired g-code (a series of Z axis plunges along a path) and a custom heated indenter was born!

This isn’t the first such use of a 3D printer we’ve seen, here’s an earlier failure, and like everything, there’s more than one way to do it – here’s a method of making inflatable bladders with a defocused CO₂ laser.

(warning! Two minutes of a 3D printer head-banging into the bed!)

Continue reading “The Wanhao Duplicator CNC Heat Sealer“ →

3D Print In The Air With A Little Software Support

July 19, 2021 by Al Williams 11 Comments

We all love 3D printing, but printing anything that has an overhang requires support, right? Maybe not. [Create Inc] has a video showing some 3D prints that seem to hang impossibly in the air — not bridges, but loops just floating in the air. You can see the effect in the video below.

The first part of the post covers gcode basics. Around the 5:30 mark, [Create] talks about his inspiration: FullControl Gcode Designer. You can do a lot with this tool and it inspired [Create’s] similar web-based version.

The point of these tools is to make it easier to create gcode directly instead of using a slicer. You can think of it as assembly language for 3D printing — you can do almost everything in the high-level language — 3D models — but if you want ultimate control you use assembly language, or, in this case, gcode.

The original tool uses Excel which didn’t visualize the output directly and could not provide proper error checking. The new tool solves those problems and is much easier to use.

If you know gcode, you can do a lot of interesting things. You can even put a spring in your step.

Continue reading “3D Print In The Air With A Little Software Support” →

This GCode Post-Processor Squeezes Lines Into Arcs

November 3, 2020 by Sonya Vasquez 34 Comments

When the slicer software for a 3D printer model files into GCode, it’s essentially creating a sequential list of connected line segments, organized by layer. But when the features of the original model are dense, or when the model is representing small curves, slicers end up creating a proliferation of teeny segments to represent this information.

This is just the nature of the beast; lots of detail translates into lots of teeny segments. Unfortunately, some printers actually struggle to print these models at the desired speeds, not because of some mechanical limitation, but because the processor cannot recalculate the velocities of these segments fast enough. The result is that some printers simply stutter or slow down the print, resulting in print times that are much higher than they should be.

Enter Arc Welder, a GCode compression tool written by [FormerLurker] that scrutinizes GCode files, hunts for these tiny segments, and attempts to replace contiguous clusters of them with a smaller number of arcs. The result is that the number of GCode commands needed to represent the model drop dramatically as connected clusters of segment commands become single arc commands.

“Now wait”, you might say, “isn’t an arc an approximation of these line segments?” And yes–you’re right! But here lies the magic behind Arc Welder. The program is written such that arcs only replace segments if (1) an arc can completely intersect all the segment-to-segment intersections and (2) the error in distance between segment and arc representation is within a certain threshold. These constraints act such that the resulting post-processing is true to the original to a very high degree of detail.

A concise description of Arc Welder’s main algorithm as pulled from the docs

This whole program operates under the assumption that your 3D printer’s onboard motion controller accepts arc commands, specifically G2 and G3. A few years ago, this would’ve been uncommon since, technically, 3D printing and STL file only requires moving in straight line segments. But with more folks jumping on the bandwagon to use these motion control boards for other non-printing applications, we’re starting to see arc implementations on boards running Marlin, Smoothieware, and the Duet flavor of RepRap Firmware.

For the curious, this program is kindly both well documented on operating principles and open source. And if [FormerLurker] seems like a familiar name before–you’d be right–as they’re also the mind behind Octolapse, the 3D printing timelapse tool that’s a hobbyist crowd favorite. Finally, if you give Arc Welder a spin, why not show us what you get in the comments?

Thanks for the tip [ImpC]!

The Mother(board) Of All CNC Controllers

July 17, 2020 by Dan Maloney 38 Comments

If you’re building a CNC machine from scratch, the number of decisions you have to make is nearly boundless. Metal or wood construction? Welded or bolted? Timing belts or lead screws? And even once the mechanical bits are sorted, you still face a universe of choices in terms of control electronics. That’s where something like this modular CNC controller could really prove to be a game-changer.

The idea behind [Barton Dring]’s latest creation started with his port of GRBL to the ESP32. In fact, the current controller bears a strong family resemblance to his version 1.0 dev board, with a few conspicuous and intriguing additions. First, everything is modular — the main PCB is basically a motherboard with little more than a 5-volt power supply and some housekeeping electronics, plus a lot of headers. There’s support for up to six channels of steppers, either directly on the board with Pololu-style modules or as external drivers using pluggable screw terminal blocks. There’s also room for five IO modules; the current collection of modules includes a four-channel switch input, a relay output, an RS-485 module and a 0-10-V interface for talking to a variable frequency drive (VFD) spindle controllers, and buffered 5-V output module. The best part is that the IO module spec is completely open, so designing custom modules should be a snap.

The video below gives a quick tour of the controller. We’re really impressed with the thought that went into this, and we’ll venture a guess that having something like this available is going to kickstart a lot of stalled CNC machine projects. We can think of one shop that finally lost its last excuse for making the move.

Continue reading “The Mother(board) Of All CNC Controllers” →