3D Printering: The Past And Future Of Prusa’s Slicer

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”

3D Printering: Non-Planar Layer FDM

Non-planar layer Fused Deposition Modeling (FDM) is any form of fused deposition modeling where the 3D printed layers aren’t flat or of uniform thickness. For example, if you’re using mesh bed leveling on your 3D printer, you are already using non-planar layer FDM. But why stop at compensating for curved build plates? Non-planar layer FDM has more applications and there are quite a few projects out there exploring the possibilities. In this article, we are going to have a look at what the trick yields for us.

Continue reading “3D Printering: Non-Planar Layer FDM”

3D Printering: G-Code Post Processing With Perl

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”

A White Hat Virus For The Internet Of Things

The Internet of Things is going gangbusters, despite no one knowing exactly what it will be used for. There’s more marketing money being thrown at IoT paraphernalia than a new soda from Pepsi. It’s a new technology, and with that comes a few problems: these devices are incredibly insecure, and you only need to look at a few CCTV camera streams available online for proof of that.

The obvious solution to vulnerable Internet of Things things would be to get people to change the login credentials on their devices, but that has proven to be too difficult for most of the population. A better solution, if questionable in its intentions, would be a virus that would close all those open ports on routers, killing Telnet, and reminding users to change their passwords. Symantec has found such a virus. It’s called Wifatch, and it bends the concept of malware into a force for good.

Wifatch is a bit of code that slips through the back door of routers and other IoT devices, closes off Telnet to prevent further infection, and leaves a message telling the owner to change the password and update the device firmware. Wifatch isn’t keeping any secrets, either: most of the code is written in unobfuscated Perl, and there are debug messages that enable easy analysis of the code. This is code that’s meant to be taken apart, and code that includes a comment directed at NSA and FBI agents:

To any NSA and FBI agents reading this: please consider whether defending
the US Constitution against all enemies, foreign or domestic, requires you
to follow Snowden's example.

Although the designer of Wifatch left all the code out in the open, and is arguably doing good, there is a possible dark side to this white hat virus. Wifatch connects to a peer-to-peer network that is used to distribute threat updates. With backdoors in the code, the author of Wifatch could conceivably turn the entire network of Wifatch-infected devices into a personal botnet.

While Wifatch is easily removed from a router with a simple restart, and re-infection can be prevented by changing the default passwords, this is an interesting case of virtual vigilantism. It may not be the best way to tell people they need to change the password on their router, but it’s hard to argue with results.

[Image source: header, thumb]

The Pi 2 Means Faster GPIO

The Raspberry Pi is a great machine to learn the ins and outs of blinking pins, but for doing anything that requires blinking pins fast, you’re better off going with a BeagleBone. This has been the conventional wisdom for years now, and now that the updated Raspberry Pi 2 is out, there’s the expectation that you’ll be able to blink a pin faster. The data are here, and yes, you can.

The method of testing was connecting a PicoScope 5444B to a pin on the GPIO pin and toggling between zero and one as fast as possible. The original test wasn’t very encouraging; Python maxed out at around 70 kHz, Ruby was terrible, and only C with the native library was useful for interesting stuff – 22MHz.

Using the same experimental setup, the Raspberry Pi 2 is about 2 to three times faster. The fastest is still the C native library, topping out at just under 42 MHz. Other languages and libraries are much slower, but the RPi.GPIO Python library stukk sees a 2.5x increase.

Oinker Is Twitter For HAMs

oinker

Have you ever wanted to send a quick message to your HAM radio buddies over the air but then realized you forgot your radio at home? [Troy] created Oinker to remedy this problem. Oinker is a Perl script that turns emails into audio.

The script monitors an email account for new messages and then uses the Festival text-to-speech engine to transform the text into audio. [Troy] runs Oinker on a Raspberry Pi, with the Pi’s audio output plugged directly into an inexpensive ham radio. The radio is then manually tuned to the desired transmit frequency. Whenever Oinker see’s a new email, that message is converted into speech and then output to the transmitter.

The script automatically appends your HAM radio call sign to the end of every message to ensure you stay within FCC regulations. Now whenever [Troy] runs into some bad traffic on the road, he can send a quick SMS to his email address and warn his HAM radio buddies to stay clear of the area.

Gritz: An Open Source Speed Reading Tool

Here’s a hack to help you increase your reading speed. Gritz is an open source text file reader, which reduces the need to look around the screen. Words pop up one at a time, but at a configurable pace.

[Peter Feuerer] got the idea for Gritz from Spritz, a commercial product for speed reading. The creators of Spritz took three years to develop their software, and recently released a demo. They claim people can read at 1000 WPM using this technology. Spritz is taking applications for access to their APIs, which will allow developers to integrate the software into their own applications. However, a fully open source version with no restrictions would be even better.

Using Gritz, [Peter] claims to have read a book with a 75% improvement in his reading speed. He admits it’s not perfect, and there’s still much development to do. Gritz is written in Perl, uses Gtk2 for its GUI, and comes with instructions for running on Linux, OS X, and Windows. It’s released under the GPL, so you can clone the Github repo and start playing around with accelerated reading.