Texture Map GCode Directly In Blender With NozzleBoss

We’ve seen this funky dual disk polar printer already recently, but [Heinz Loepmeier] has been busy working on it, so here’s an update. The primary focus here is nozzleboss, a blender plugin which enables the surface textures of already sliced objects to be manipulated. The idea is to read in the gcode for the object, and convert it to an internal mesh representation that blender needs in order to function. From there the desired textures can be applied to the surfaces for subsequent stages to operate upon. One trick that nozzleboss can do is to create weight maps to tweak the extrusion flow rate or print velocity value according to the pixel value at the surface — such ‘velocity painting’ can produce some very subtle surface effects on previously featureless faces. Another trick is to use the same weight maps and simply map colours to blender text blocks which are injected into the gcode at export time. These gcode blocks can be used swap tool heads or extruders, enabling blending of multiple filament colours or types in the same object.

Some nice examples of such printing manipulation can be seen on [Heinz’s] instagram page for the project. So, going back to the hardware again, the first video embedded below shows the ‘dual disk polar printer’ fitted with a crazy five-extruders-into-one-nozzle mixing hotend setup, which should be capable of full CMYK colour mixing and some. The second video below shows an interesting by-product of the wide horizontal motion range of the machine, that the whole printing area can be shifted to a nozzle at the other end of the gantry. This enables a novel way to switch extruders, by just moving the whole bed and print under the nozzle of interest! One final observation — is that of the print surface — it does look rather like they’re printing direct onto a slab of marble, which I think is the first time we’ve seen that.

Interesting printer designs are being worked on a lot these days, here’s a really nice 5-axis prusa i3 hack, and if you want to stay in the cartesian world, but your desktop machine is just too small, then you can always supersize it.

Continue reading “Texture Map GCode Directly In Blender With NozzleBoss” →

You Draw It, CNC Cuts It

[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

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.

Resuming a print

Multiple Ways Of Recovering A Failed Print

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

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!

Custom seal path made in Onshape

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 CO2 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

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

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]!