Most of our beloved tools, such as Slic3r, Cura or KISSlicer, offer scripting interfaces that help a great deal if your existing 3D printing toolchain has yet to learn how to produce decent results with a five headed thermoplastic spitting hydra. Using scripts, it’s possible to tweak the little bits it takes to get great results, inserting wipe or prime towers and purge moves on the fly, and if your setup requires it, also control additional servos and solenoids for the flamethrowers.
This article gives you a short introduction in how to post-process G-code using Perl and Slic3r. Perl Ninja skills are not required. Slic3r plays well with pretty much any scripting language that produces executables, so if you’re reluctant to use Perl, you’ll probably be able to replicate most of the steps in your favorite language.
Continue reading “3D Printering: G-Code Post Processing With Perl”
Most 3D printing projects start with a 3D model of some kind. Slicing programs transform the model into gcode. The gcode file contains the commands that actually drive your printer. There are different ways to slice a model and sometimes you want to use more than one on a single model. I’ve been working on a way to make that easier.
When you slice a 3D printing model, you can select different attributes for the resulting gcode file. For example, you might set the slicer to produce different infill density, temperatures, or print speeds. These settings can have a big impact on your printing results. For example, a piece that needs high strength might require a denser infill than some trinket or key chain. You might want an artistic piece to have a finer layer height than some internal part for some gadget no one will ever see.
One Size Fits All?
The problem is that for most open source slicers, these settings will apply to the entire model. Cura has some plugins that can change settings at different Z heights, and Slic3r can vary layer height, but in the general case, what you set for the slicer will apply to the entire model. Of course, a gcode file is nothing more than a text file, so if you are industrious, you can manually merge two or more files into one.
A manual merge is a pain, which is why I wrote gblend. It can stitch together gcode files to get various effects. The program takes multiple gcode files in as inputs and can combine them in different ways. The most useful feature allows you to get a certain number of layers from each source file and combine them into a single print. Measurements are in millimeters, so you don’t have to worry about layer numbers. The entire process is much easier than anything else I’ve come across.
Continue reading “Better 3D Prints by Mixing Slicing Techniques”
After interviewing the creator of Slic3r and the folks at Shapeways, [Andrew] is back again with his adventures in 3D printer videography and an interview with [David Braam] of Ultimaker
About a year ago, [David] looked at the state of the art in 3D printer control and Replicator G. While Replicator G, along with Pronterface and Repetier-Host both convert 3D models into G-code files as well as control the printer while its squeezing plastic out onto a bed. [David] thought the current state of these RepRap host programs were janky at best, and certainly not the best user experience for any home fabricator. This lead him to create Cura, a very slick and vastly improved piece of host software for the Ultimaker.
Cura isn’t just a fancy front end on an already existing slicer engine; [David] created his own slicing algorithm to turn .STL files into G-code that’s immensely faster than skeinforge. Where skeinforge could take an hour to slice a complex model, Cura does the same job in minutes.
There are also a bunch of cool features available in Cura: you can rotate any part before sending it to the printer, as well as pulling voxels directly from your Minecraft world and sending them to your printer. Very, very cool stuff, and if you’re running a Ultimaker or any other RepRap, you might want to check it out.
Continue reading “An interview with [David] of Ultimaker”
When in Rome, most people visit great works of art, see masterpieces of architecture, or simply try to convince random tourists that a modern recreation of naval battles in the Colosseum would be really cool and somebody should really get on that. [Andrew] had a different idea, though. He thought meeting up with Slic3r developer [Alessandro Ranellucci] would be just as educational and entertaining as visiting a basilica and thoughtfully decided to film his interview for all to see.
Whenever a file of a 3D object is sent to a 3D printer, the object must first be converted into GCode – the language of lines, circles, and computer aided design that all 3D printers speak. To convert 3D objects to GCode, every piece of 3D printer software from Pronterface, ReplicatorG, and Repetier must first ‘slice’ the file up so the object can be printed one layer at a time.
As the lead dev for Slic3r, [Alessandro], a.k.a. [Sound] goes over the current happenings of his STL to GCode converter – he’s even getting a little support from the very cool people at LulzBot – and the future of Slic3r. There’s still a lot of work to be done optimizing the current software, improving the user interface, and getting rid of all those nasty edge-case bugs.
For as much as we at Hackaday focus on the hardware half of 3D printers, it must be said the current state of the art in desktop manufacturing wouldn’t be where it is without [Alessandro] and other software devs. There’s still a lot of room for improvement – try printing a single wall thickness cylinder without a seam, for example – but without software projects like Slic3r, 3D printing wouldn’t be where it is today.
We think in might be absurdly vain, but wouldn’t it be fun to give everyone in your family a chocolate modeled after your mug this holiday season? [Eok.gnah] has already worked out a system to make this possible. It consists of three parts: scanning your head and building a 3D model from it, using that model to print a mold, and molding the chocolate itself.
He used 123D to scan his face. No mention of hardware but this face scanning rig would be perfect for it. He then cleaned up the input and used it to make a mold model by subtracting his face from a cube in OpenSCAD. That needs to be sliced into layers for the 3D printer, and he used the Slic3r program which has been gaining popularity. Finally the mold was printed and the face was cast with molten chocolate. We’d suggest using a random orbital sander (without sand paper) to vibrate the bottom of the mold. This would have helped to evacuate the bubble that messed up his nose.
You know, it doesn’t have to be your face. It could be another body part, even an internal one… like your brain!