G-code is effective, easily edited, and nearly ubiquitous when it comes to anything CNC. The format has many strengths, but space efficiency isn’t one of them. In fact, when it comes to 3D printing in particular file sizes can get awfully large. Partly to address this, Prusa have proposed a new .bgcode binary G-code format. You can read the specification of the new (and optional) format here.
The newest version of PrusaSlicer has support for .bgcode, and a utility to convert ASCII G-code to binary (and back) is in the File menu. Want to code an interface of your own? The libbgcode repository provides everything needed to flip .gcode to .bgcode (with a huge file size savings in the process) and vice versa in a way that preserves all aspects of the data. Need to hand-edit a binary G-code file? Convert it to ASCII G-code, make your changes, then flip it right back.
Prusa are not the only ones to notice that the space inefficiency of the G-code file format is not ideal in all situations. Heatshrink and MeatPack are two other solutions in this space with their own strong points. Handily, the command-line tool in libgcode can optionally apply Heatshrink compression or MeatPack encoding in the conversion process.
In a way, G-code is the assembly language of 3D printers. G-code files are normally created when slicing software processes a 3D model, but there are some interesting tricks to be done when G-code is created directly.
I know people who have 3D printers that are little more than appliances. They buy it, they print with it, and they don’t change much of anything. That doesn’t describe me and, I’m guessing, it doesn’t describe you either. This does lead to a problem, though, when it comes to slicers. You have to keep changing profiles and modifying them. It can be hard to keep things straight. For example, if you have profiles for different nozzles, you get to make a choice: keep one profile and edit the parts that change, or keep multiple profiles and any common changes have to be propagated to the other profiles.
I’ve long wanted to create a system that lets me have baseline profiles and then just use specific profiles that change a few items in the baseline. Turns out, I didn’t need to do it. Prusa Slicer and its fork, SuperSlicer, have the capability already. Both of these, of course, are based on Slic3r, but the scripting languages are different and what I’m doing does require G-code scripting. The problem is, this capability is not documented very well and the GUI doesn’t really support it directly, which requires a little sidestepping. I’ll show you how I have things set up and where the limitations are. If you want to try your hand at it, I highly suggest you backup your configuration directory or switch to a new one.
Most desktop fused deposition modeling (FDM) 3D printers these days use a 0.4 mm nozzle. While many people have tried smaller nozzles to get finer detail and much larger nozzles to get faster printing speed, most people stick with the stock value as a good trade-off between the two. That’s the conventional wisdom, anyway. However, [Thomas Sanladerer] asserts that with modern slicers, the 0.4 mm nozzle isn’t the best choice and recommends you move up to 0.6 mm.
If you know [Thomas], you know he wouldn’t make a claim like that without doing his homework. He backs it up with testing, and you can see his thoughts on the subject and the test results in the video below. The entire thing hinges on the Ultimaker-developed Arachne perimeter generator that’s currently available in the alpha version of PrusaSlicer.
We’ve experimented with nozzles as small as 0.1 mm and, honestly, it still looks like an FDM 3D print and printing takes forever at that size. But these days, if we really care about the detail we are probably going to print with resin, anyway.
There are a few slicer settings to consider and you can see the whole setup in the video. The part where an SLA test part is printed with both nozzles is particularly telling. This is something that probably shouldn’t print well with an FDM at all. Both nozzles had problems but in different areas.
When you think of slicers for FDM 3D printing — especially free slicers — you probably think of Cura, Slic3r, or PrusaSlicer. There are fans of MatterControl and many people pay for Simplify3D. However, there are quite a few other slicers out there including the one [TeachingTech] has switched to: SuperSlicer. You can see his video review, below.
Of course, just as PrusaSlicer is a fork of Slic3r, SuperSlicer is a fork of the Prusa software. According to the project’s home page, the slicer does everything Prusa does but adds custom calibration tests, ironing, better thin wall support, and several other features related to infill and top surfaces. The software runs on Windows, Linux, or Mac.
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.