Slicing software needs to maintain a balance between ease-of-use and control, while handling handle any STL file you throw at it. If you eliminate the need to convert an existing 3D model, and create G-Code directly, you gain a lot of design freedom, at the cost of increased design effort. By taking advantage of this freedom and making it more accessible, [Andrew Gleadall] and [Dirk Leas] created the FullControl Design Library.
User-friendly slicing software is arguably the key software component that makes 3D printing approachable for most users. Without it going from a CAD design to a printing part would take hours, not seconds. As a trade-off you give up a lot of control over the exact path of the hotend, but most of the time it’s worth it. However, for some niche use-cases, having complete control over the tool path is necessary. Enter FullControl GCode Designer, a tool that gives you all the control without resorting to writing GCode directly.
FullControl takes an approach similar to OpenSCAD, where you define path geometries line by line. Need an array of circles? Choose the circle feature, define its origin, radius, starting position, and extrusion height, and define the spacing and axes (including Z) of the copies. Need a mathematically defined lamp shade? Define the functions, and FullControl generates the GCode. Non-planar printing, where your print head moves along all three axes simultaneously instead of staying at a constant Z-height is also possible. In the video after the break, [Thomas Sanladerer] demonstrates how he used FullControl to reduce the print time of a functionally identical part from two hours to 30 minutes.
FullControl is built on Microsoft Excel using Visual Basic scripting, which comes at the cost of long GCode generation times. It also doesn’t show the defined tool paths graphically, so the generated code needs to be pasted into a viewer like Repetier Host to see what it’s doing. Fortunately, a Python version is coming to should hopefully elevate many of these shortcomings.
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.
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.
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.
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!
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.
[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!