3D printers, desktop CNC mills/routers, and laser cutters have made a massive difference in the level of projects the average hacker can tackle. Of course, these machines would never have seen this level of adoption if you had to manually write G-code, so CAM software had a big part to play. Recently we found out about an open-source browser-based CAM pack created by [Stewert Allen] named Kiri:Moto, which can generate G-code for all your desktop CNC platforms.
To get it out of the way, Kiri:Moto does not run in the cloud. Everything happens client-side, in your browser. There are performance trade-offs with this approach, but it does have the inherent advantages of being cross-platform and not requiring any installation. You can click the link above and start generating tool paths within seconds, which is great for trying it out. In the machine setup section you can choose CNC mill, laser cutter, FDM printer, or SLA printer. The features for CNC should be perfect for 90% of your desktop CNC needs. The interface is intuitive, even if you don’t have any previous CAM experience. See the video after the break for a complete breakdown of the features, complete with timestamp for the different sections.
All the required features for laser cutting are present, and it supports a drag knife. If you want to build an assembly from layers of laser-cut parts, Kiri:Moto can automatically slice the 3D model and nest the 2D parts on the platform. The slicer for 3D printing is functional, but probably won’t be replacing our regular slicer soon. It places heavy emphasis on manually adding supports, and belt printers like the Ender CR30 are already supported.
Kiri:Moto is being actively improved, and it looks as though [Stewart] is very responsive to community inputs. The complete source code is available on GitHub, and you can run an instance on your local machine if you prefer to do so. Continue reading “Open Source CAM Software In The Browser”
When you 3D print something, you probably adjust the layer height based on your desired print quality. Speed is another parameter that many people adjust. But what about extrusion width? The parameter is there, but most people leave it at the defaults. [Stephan] wondered about it, and after running some tests, made a video you can see below trying to determine if it affected strength and print quality.
The tests were pretty straightforward. Some Benchys and other test pieces at each setting were observed and — in some cases — destroyed. He ranged the width from 90% to 250% of a 0.4mm nozzle. Important to note, his results are from a nozzle that has a flat lip around the aperture. If yours doesn’t look like that, you will see different results.
Continue reading “Rarely Adjusted Slicer Setting Makes A Difference”
If you thought CADing designs for 3D printing was hard enough, wait until you hear about this
[Angus] of Maker’s Muse recently demoed a method for creating hidden geometries in
.stl files that are only revealed during the slicing process before a 3D print. (Video, embedded below.) The process involves creating geometries with a thickness smaller than the size of the 3D printer’s nozzle that still appear to be solid in a
.stl editor, but will not be rendered by a FDM slicer.
Most 3D printers have 0.4 mm thickness nozzle, so creating geometries with a wall thinner than this value will result in the effect that you’re looking for. Some possible uses for this trick are to create easter eggs or even to mess with other 3D printing enthusiasts. Of course, [Angus] recommends not to use this “deception for criminal or malicious intent” and I’d have to agree.
There’s a few other tricks that he reveals as well, including a way to create a body that’s actually a thin shell but appears to be solid: great for making unprintable letters that reveal hidden messages.
Nevertheless, it’s a cool trick and maybe one of those “features not bugs” in the slicer software.
Continue reading “There’s More To The 3D Print Than The Eye Can See”
If you own a desktop 3D printer, you’re almost certainly familiar with Slic3r. Even if the name doesn’t ring a bell, there’s an excellent chance that a program you’ve used to convert STLs into the G-code your printer can understand was using Slic3r behind the scenes in some capacity. While there have been the occasional challengers, Slic3r has remained one of the most widely used open source slicers for the better part of a decade. While some might argue that proprietary slicers have pulled ahead in some respects, it’s hard to beat free.
So when Josef Prusa announced his team’s fork of Slic3r back in 2016, it wasn’t exactly a shock. The company wanted to offer a slicer optimized for their line of 3D printers, and being big proponents of open source, it made sense they would lean heavily on what was already available in the community. The result was the aptly named “Slic3r Prusa Edition”, or as it came to be known, Slic3r PE.
Ostensibly the fork enabled Prusa to fine tune print parameters for their particular machines and implement support for products such as their Multi-Material Upgrade, but it didn’t take long for Prusa’s developers to start fixing and improving core Slic3r functionality. As both projects were released under the GNU Affero General Public License v3.0, any and all of these improvements could be backported to the original Slic3r; but doing so would take considerable time and effort, something that’s always in short supply with community developed projects.
Since Slic3r PE still produced standard G-code that any 3D printer could use, soon people started using it with their non-Prusa printers simply because it had more features. But this served only to further blur the line between the two projects, especially for new users. When issues arose, it could be hard to determine who should take responsibility for it. All the while, the gap between the two projects continued to widen.
With a new release on the horizon that promised to bring massive changes to Slic3r PE, Josef Prusa decided things had reached a tipping point. In a recent blog post, he announced that as of version 2.0, their slicer would henceforth be known as PrusaSlicer. Let’s take a look at this new slicer, and find out what it took to finally separate these two projects.
Continue reading “3D Printering: The Past And Future Of Prusa’s Slicer”
Having a great word processor won’t actually help you write the next bestselling novel. It might make it easier, but if you have a great novel in you, you could probably write it on paper towels with a crayon if you had to. A great 3D printer isn’t all you need to make great 3D prints. A lot depends on the model you start with and that software known as a slicer. You have several choices, and now you have one more: PathIO, a slicer sponsored by E3D, is out in beta. You can see a video about its features below.
The software has a few rough edges as you might expect from a beta. The slicer doesn’t feed Gcode to a printer directly, although Octoprint integration is forthcoming. Developers say they are focusing on the slicing engine which is totally new. According to their website, conventional slicers immediately cut a model into 2D slices and then decide how to realize each slice with respect to the shell and infill. Pathio works in 3D space and claims this has benefits for producing correct wall thickness and an increase in self-supporting geometries.
Continue reading “Pathio: New 3D Slicer From E3D”
If you’ve used a desktop 3D printer, you’re likely familiar with the concept of layer heights. Put simply: thicker layers will print faster, and thinner layers will produce better detail. Selecting your layer height is making a choice between detail and speed, which usually works well enough. For example, prints which are structural and don’t have much surface detail can be done in higher layer heights to maximize speed with no real downside. Conversely, if you’ve got a model with a lot of detail you’ll have to just deal with the increased print time of thinner layers.
At least, that’s how it’s been up till now. Modern slicer software is starting to test the waters of adaptive layer heights, which change the layer height during the print. So the software will raise or lower the layer height depending on the level of detail required for the current area being printed. [Dylan Radcliffe] wanted to experiment with this feature on his Monoprice Select Mini, but it took some tweaking and the dreaded mathematics to get Cura’s adaptive layer height working on the entry-level printer. He’s documented his settings for anyone who wants to check out this next-generation 3D printing technology without forking out the cash for a top of the line machine.
While Cura is a popular slicer, the fact of the matter is that it’s developed by Ultimaker primarily for their own line of high-end printers. It will control machines from other manufacturers, but it makes no promises that all the features in the software will actually work as expected on lesser printers. In the case of the Monoprice Mini, the issue is the rather unusual Z hardware. The printer uses a 7.5° 48-step motor coupled to 0.7 mm thread pitch M4 rod. This is a pretty suspect arrangement that was no doubt selected to keep costs down, and results in an unusual 0.04375 mm step increment. For the best possible print quality, layer heights should be a multiple of this number. That’s where the math comes in.
After enabling adaptive layers in Cura’s experimental settings, you need to define the value which Cura will add or subtract to the base layer height. In theory you could enter 0.04375 mm here, but while that’s the minimum on paper, the machine itself is unlikely to be able to pull off such a small variation. [Dylan] recommends doubling that to 0.0875 for the “variation step size” parameter, and setting the base layer height to 0.175 mm (4 x 0.04375 mm).
[Dylan] reports these settings reduced the print time on his topographical map pieces from 12 hours to 7 hours, while still maintaining high detail on the top surface. Of course print time reduction is going to be highly dependent on the model being printed, so your mileage may vary.
If Cura isn’t your style, our very own [Brian Benchoff] gave us a tour of “variable layer height”, the Slic3r version of this technique. Perfect for that Prusa i3 MK3 you finally spent the cash on.
If you were to make a list of the most important technological achievements of the last 100 years, advanced medical imaging would probably have to rank right up near the top. The ability to see inside the body in exquisite detail is nearly miraculous, and in some cases life-saving.
Navigating through the virtual bodies generated by the torrents of data streaming out of something like a magnetic resonance imager (MRI) can be a challenge, though. This intuitive MRI slicer aims to change that and makes 3D walkthroughs of the human body trivially easy. [Shachar “Vice” Weis] doesn’t provide a great deal of detail about the system, but from what we can glean, the controller is based on a tablet and Vive tracker. The Vive is attached to the back of the tablet and detects its position in space. The plane of the tablet is then interpreted as the slicing plane for the 3D reconstruction of the structure undergoing study. The video below shows it exploring a human head scan; the update speed is incredible, with no visible lag. [Vice] says this is version 0.1, so we expect more to come from this. Obvious features would be the ability to zoom in and out with tablet gestures, and a way to spin the 3D model in space to look at the model from other angles.
Interested in how the machine that made those images works? We’ve covered the basics of MRI scanners before. And if you want to go further, you could always build your own.
Continue reading “Walking Through MRIs With A Vive”