Blog – Page 4 – Alexander Evans

One Year Later – 3D Printing Advice

I bought my 3D printer back in January of 2018, about a year ago. The printer I bought was the Prusa i3 MK2. It’s been a year full of learning. 3D printers take time and effort to learn how to operate, especially if you’re printing with several different kinds of filaments (plastics). It’s not like a toaster, where it just works every time and doesn’t require much knowledge to operate. But don’t get me wrong, I don’t think that 3D printers are incredibly complex. Once you learn the little quirks of your 3D printer and find the right settings for each kind of filament it’s not very difficult. And it’s complete worth it to learn if you’re someone who loves to make things. In this article I’ll be sharing the advice I have for making getting into 3D printing easier.

I Recommend Prusa

I did a lot of research into which 3D printer I should get as my first. I ended up going with the Prusa because of it’s overwhelmingly positive reviews, it’s auto bed leveling, the wide range of filaments it supports, and the advice I saw over and over is that it’s a good printer for beginners. After over a year of using it I am completely satisfied with it.

I recommend the Prusa because it has several features that make it easier for beginners. When you first start your printer, you’ll have the printer run some calibrations. The printer will make sure your bed is level, your extruder is level, and everything can move properly. When you start your first print (and before every print), the printer will check how level your bed is. If the bed is slightly mis-leveled slightly off, it will automatically adjust.

I bought the MK2, but the MK3 is out now (so you can’t get the MK2 anymore). The MK3 has even more features that make it easier for beginners. It has a filament sensor, so if you run out of filament in the middle of a print it will automatically stop. Then you can load it with new filament and it will continue the print from where it left off. The MK3 comes with a removable, flexible bed. One problem I constantly deal with is it can be hard to get prints off of the bed. The MK2 comes with a bed that has a PEI sheet on it. Printed parts stick to PEI really well, too well sometimes. Getting prints off can be a challenge. With the MK3’s removable and flexible bed, you can remove the bed when the print is done and then bend it. This will cause the print to pop off.

One of my main concerns when researching what 3D printer to buy is how safe they are. I didn’t want my printer to cause a fire. I read that there have been many cases where cheaper Chinese 3D printers have caught on fire. These printers are often clones of other, higher quality printers, such as the Prusa, but assembled with lower quality parts. However, I still haven’t heard of a case where a genuine Prusa printer has caused a fire. The Prusa software has what’s called thermal runaway protection, which prevents the head block from heating up out of control. Still, even though the chances of it causing a fire are very slim, I still have a fire alarm right above it and a fire extinguisher in the room just in case, and I recommend you do the same. Some people have even installed automatic fire extinguishers over their 3D printer. I also never run the 3D printer if I’m not home. I started running it overnight after several months of running it when I was confident that it would be fine.

I also recommend the Prusa because it can print pretty much any kind of filament. PLA, ABS, PETG, Nylon, TPU, you name it, the Prusa can print it.

Preassembled vs. Assembling It Yourself

Whatever printer you decide to get, if you have the option of buying it preassembled or putting it together yourself, I recommend that you put it together yourself. As you put it together, you’ll learn how it works. When you run into problems with it later, you’ll have a much easier time troubleshooting and be much more comfortable taking it apart if you need to. For the Prusa, the instructions for putting it together are very easy to follow. I think it takes most people around 12 hours to assemble the MK2. It took me about that much time.

Save Your Settings for Each Type of Filament

When you start 3D printing you’ll need a slicer program. The slicer contains all of the settings the printer should use when printing the model. These settings include what temperatures to use for the extruder and the bed, how many solid layers and shells to print, what infill to use, whether to generate supports for overhangs or not, and many other settings. So you’ll open a 3D model file in the slicer, and the slicer will export a gcode file using all your settings and the 3D model file. Your printer will use the gcode file to print the model.

The slicer program I use is Slic3r (Prusa edition). With Slic3r, and probably most slicer programs, you can export your settings to a file. When you start printing with different types of filaments, you’re going to have to tweak the settings. For example, PLA and PETG need different temperatures for the extruder and bed. Once you have settings you like for the filament you’re printing with, export those settings to a file. Import the file whenever you print with that filament. I have different settings files for all the filaments I print with (PLA, PETG, TPU, Nylon).

This wasn’t obvious to me when I first started out, but you can store the Z offset in the slicer program. On the Prusa, you can manually adjust the Z offset using the LCD screen. At first I would adjust it on the LCD screen whenever I changed filaments. Don’t bother with that. Just store it in your settings file.

Layer, Shell, and Infill Settings

The number of layers, shells, and the infill percentage you use will depend on how strong your part needs to be. If you’re printing things that don’t need to be very strong, such as figurines and toys, then I think you can get away with 2 layers and shells and 10-20% rectilinear infill. If you’re printing parts that need to be strong, then increase the number of layers and shells. I’d recommend at least 4 layers and shells. Infill doesn’t matter as much. The cubic infill pattern will make the part stronger, so I recommend it. For the percentage I usually use 30%.

Use Thingiverse and Mcmaster-Carr to Find Free 3D Models

Thingiverse has 1000s of free 3D models you can download. If it’s something you can 3D print, chances are it’s already on Thingiverse. I’ve downloaded and printed figurines, a sword, gears, and many other things from Thingiverse.

If you’re looking for mechanical parts, such as gears and screws, McMaster-Carr is an excellent resource. Most of the items you can buy there have a step file you can download and import into your slicer or 3D modeling software.

How to Make Your Own 3D Models

If you want to make your own 3D models, there are many free programs you can use. Blender, FreeCAD, SketchUp, Tinkercad, Fusion 360, OpenSCAD, and Desigspark Mechanical are all free (or have free licenses). I mainly use Designspark Mechanical because I find it’s interface to be very intuitive and easy to use. For what I need, It works 90% of the time. The other 10% of the time I’ll need to do something that I can’t do in Designspark Mechanical, and I’ll use Fusion 360.

All of the programs I mentioned except Blender are meant for designing mechanical parts and machines. Blender can be used for making more artistic models, such as figurines.

Printing Time is Longer Than You Think

Many people who aren’t familiar with 3D printing are surprised by how long it can take to 3D print an item. For example, this item took about 3 hours to print. Larger items, like this tommy gun, took over 20 hours to print all the parts.

You can tweak your settings to make items print faster, but just know that 3D printing is slow.

I Hate ABS, Love PETG

When I first started printing, I printed with ABS a lot because I wanted it’s strength and heat resistance. I constantly had problems. It smells bad. It needs higher temperatures to print and is known for warping. Warping is where the part, well, warps, because of heat differences in the part. The bottom of the part will be hot because it’s touching the bed. The top of the part will be hot because it just came out of the extruder. The middle of the part will be colder, which will result in warping. Most people recommend having an enclosure around your 3D printer if you’re going to print with ABS. The enclosure will trap heat so that the part doesn’t get as cool, resulting in less or no warping.

I’ve seen many images of enclosures people have built for their 3D printers and read logs of guides and forum posts about it. The problem I have with making an enclosure is that it’s recommended that you move the electronics outside of the enclosure, because the extra heat can damage the electronics. Moving them just sounds like a hassle to me, and I just don’t want to take the time to build one. Plus, many DIY enclosures are made from wood, so if the printer ever actually does catch on fire, there’s now a lot more material to burn. If I ever do get an enclosure I’ll probably buy a metal server rack.

Instead of building an enclosure, I tried a quicker solution. I set up a heat lamp so that it pointed at the print. I hoped the heat lamp would keep the part hot enough to prevent warping. It worked very well to prevent warping.

A friend of mine recommended trying PETG, since it is similar in strength to ABS but can be printed at lower temperatures, doesn’t smell, and isn’t known for warping. I got a roll of Amazon Basics PETG and was amazed by how easy it was to print with. I haven’t had any problems, including warping, with PETG. PETG is now my go-to filament because of how easy it is to print with and how strong it is.

Printing with TPU

TPU is a flexible filament, meaning that the parts you make with it are flexible. Printing with it can be a challenge because of how flexible it is. You may find that it has problems where it gets tangled up, oozing, stringing, and prints getting stuck to the bed.

I recommend following the advice in this video from Maker’s Muse. After following that advice and doing a little bit of tweaking with the extrusion multiplier I was able to easily print TPU. However, I still continue to struggle with one problem, and that is that TPU sticks too the PEI bed too well. It sticks so well, that it ripped several holes in my PEI sheet. Advice I found online suggests to spray window cleaner on the bed, which is supposed to make the TPU not stick as well to the PEI, but it didn’t seem to work well for me. I also recently found advice to use a glue stick instead of window cleaner. I haven’t tried that yet.

What I found works for me is to put some Kapton tape on the bed. The TPU sticks just well enough to the Kapton tape to keep it on the bed, but not so well that it’s difficult to get off. Still, sometimes the tape rips, but it’s better than the PEI sheet getting ripped. Kapton tape also sticks well to the other filaments I work with, even Nylon, so I decided to just cover my bed with it. I’ll probably just leave the tape on my bed until I decide to upgrade my printer so I can get the removable and flexible bed.

Keep Your Failed Prints

You should keep your failed prints and keep them separated by filament type. Filament extruders, machines that allow you to recycle filament, are getting cheaper. Take a look at this video from CNC Kitchen to learn how you can get started.

What To Do If You Rip Your PEI Sheet

Like I mentioned above, you can use Kapton tape to cover holes in your PEI sheet. Take a look at this video from CNC Kitchen to learn how.

You can replace the PEI sheet. You can find replacement sheets on Amazon. Follow the guide in this video from SBS Extensions to replace the sheet, which involves removing the bed. If you don’t want to replace the bed you can follow this video by Chris Riley. However, I’d recommend that you not use acetone like he does in the video since it can melt the 3d printed parts on your printer. Use something like Goo Gone instead.

YouTube Channels I Recommend

There are lots of great resources out there to learn about 3D printing. I mostly watch YouTube videos about it. Here are the channels I recommend.

Software Tools/Concepts I Wished I Learned About In College

College prepared me to enter any kind of software job I would want to enter after graduating. I had the tools I needed to get a job in web design, embedded systems, or anywhere in between. I mostly wrote code in object-oriented programming languages, but I had a occasions where I wrote code in F# (a functional programming language), assembly, and got to try aspect-oriented programming in Java. I had many hundreds of hours of debugging code under my belt by the time I graduated, which made me confident that I could find and fix any bug in any program.

There is an enormous range of topics that professors need to teach students in the 4-5 years that the students are there. They can’t go over everything that you may encounter in any software job. Plus, technology is changing so quickly it’s hard to keep up. However, after working in the industry for 4 years now, I have some suggestions for new graduates and people who are just starting their first software job. These are topics or tools that where either not covered at all, or in my opinion not covered thoroughly enough when I was in college. I believe these topics and tools are incredibly valuable in most software jobs.

Devops

Back in school, programming assignments would usually consist of getting the specifications for the program to be written (the sample output being the most important part), writing the program, submitting it, then forgetting about it. Doing this for 4-5 years may make you think that when you’re working at your job, you just need to worry about coding. You’ll need to add new code for new features, or modify existing code to change features or fix bugs. But there are so many other activities you’ll be involved in, or at least need to be aware of, as a developer. These activities include, but are not limited to the following.

Updating a test machine with the latest build.
Deploy the latest build to a customer, including any configuration updates.
Versioning and storing all the builds in the correct spot. All versions should be easily accessible. It should be easy to see if a build is a snapshot or release. It should be easy to figure out which build introduced a new feature (or bug).
Creating new virtual machines for various people.
Regression testing. When you check in new code you probably tested the new feature, but you probably didn’t test all of the existing features to make sure you didn’t break them. Or what if code that another developer checks in breaks your new feature?

The above activities are also prone to error. A developer may accidentally update the wrong machine, or not update it correctly. Configurations are easy to get wrong. It’s easy to forget to test something. This is where devops comes in.

Devops is a set of practices with the goal of delivering software that is high in quality, as fast as possible. In devops, we want to automate as many processes as possible. All of the above activities I mentioned should be automated as much as possible. For example, when a developer checks in new code, a build server should automatically make sure the code compiles, and then run a regression testing suite. If any of the tests fail, an email can be sent to the developer telling them that their new code broke something. If all the tests pass, the new build can be automatically versioned and uploaded to an artifact repository. Then the build could be deployed to a test box automatically.

In devops, we use build servers and scripts to automate as much of the development process as we can. Ideally, developers can just focus on coding and have everything else be automated. Other processes that could be automated include the following.

Run integration tests nightly (because integration tests can take a long time)
Run static code analysis, using SonarQube for example.
Spinning up a new virtual machine.
Generating release notes.
Only allowing commits to your main branch (master) if all tests are passing.

Devops was a word that I don’t remember ever being brought up in college. Neither was continuous integration, continuous delivery (CICD). The words “build system” may have been mentioned once or twice, but I never understood what it meant. Now that I’ve had a couple real software jobs, I understand how important it is. I wish that in school we had the opportunity to set up a simple build server. For example, for one of our projects we could have set up a Jenkins server and created a simple job that compiles a simple program and runs a few simple tests whenever there is a new commit.

Design Patterns

Design patterns are solutions to common problems in software design. Observer, dependency injection, visitor, and factory are all examples of design patterns.

Design patterns were covered briefly in my schooling. I can remember two occasions. On the first occasion my professor just had a slide show where he showed the class diagrams for a bunch of different design patterns, which didn’t help me understand at all how to apply them. They just seemed like vague, abstract concepts when looking at the class diagrams. On the other occasion we were creating a program that required an undo/redo feature. My professor recommended we look into the command pattern for implementing it. I did, and it made implementing undo/redo very easy. I got a taste of the power they can provide, but it wasn’t clear to me how to apply other patterns.

It wasn’t until I started programming my game that I started to understand how powerful design patterns were. Games, even ones as simple as the one I made, are complex. At some point it became nearly impossible to add more features to my game, because I’d have to change too much code. Then I found out about the entity component system pattern. Then I read Game Programming Patterns by Robert Nystrom. I learned how several design patterns could be applied to the my game code. I ended up using a mix between the entity component system and observer pattern to make it easy to add new abilities to my game characters. I used the state pattern to make it easy to change an object’s behavior. I used dependency injection to make it easier to test the code.

You can’t teach design patterns by just showing class diagrams. For me, it took many examples to understand how to apply them. It took running into problems with my game before I understood how powerful they are. Back in school, I wish there were assignments where I couldn’t just code the program any way I wanted to, but required a specific design pattern to be used (one that makes sense for the assignment).

Testing

I remember one assignment where it was a requirement to write tests (in C#). But we weren’t taught how to write tests, or write testable code, and I didn’t know about any C# testing frameworks at the time, so it was a challenge. There should’ve been a whole class on writing tests, and for each class after that writing unit tests for assignments should have been mandatory.

Writing tests and testable code is, I would say, more important than anything else. When you get a software job, if the system you’re working in doesn’t have tests and testable code, then it will slowly accumulate bugs. Then each time you fix a bug, you introduce 2 more somewhere else in the system. It becomes harder and harder to test, and you’ll become scared of making any changes. Development becomes more and more costly and slows to a snail’s pace.

If the system your working in has automated tests for every line of code and every feature, then maintaining and adding new features to the system becomes monumentally easier. Whenever you add a new feature, or modify an existing one, you can run the tests to make sure you didn’t break anything. You can catch bugs before you commit code (the earlier bugs are caught, the cheaper they are to fix).

Testable code is always better than code that isn’t testable. This is because for code to be testable, it needs to be clean. It needs to be loosely coupled, highly cohesive, follow the single responsibility principle, follow the open-close principle, and probably use dependency injection, among other coding principles. It should be easy to write tests for code that is clean.

Taking the extra time to write testable code and tests for that code will end up saving you much more time and headaches overall. To get started, I recommend reading the following two books.

Package Management Systems

Back in school, I wasn’t aware of how easy it is to install open-source libraries into my project using package management systems. In the previous section, I mentioned that I had to write tests but didn’t know about any C# testing frameworks. It would have been great to use Nuget to easily install Xunit and use it to write my tests.

Package managers allow you to easily install, update, configure, and remove 3rd party libraries for your own projects. For .Net there is Nuget. For Ruby there’s gems. For Java there is Gradle (among others). Most languages have package managers. If you need a testing framework, IoC container, or an ORM, just to name a few, you’ll find many to choose from when using package managers.

Git

Back in school we used Subversion. At my first job I was exposed to Git and can say I’ll never go back. I’ve also used TFS, but Git is by far my preferred source control system. The thing that makes Git stand above all the rest for me is how easy it makes branching and merging. The ease of branching and merging makes many different branching strategies possible. It’s also distributive, meaning you can make commits offline. It’s runs using the command line, but there are many GUIs available for it (I use Git Extensions).

To get started, I recommend this guide.

Conclusion

Like I mentioned before, college prepared me to be able to enter any software job. It gave me the basics I needed to be able to learn whatever else I would need for the job. But if the above concepts and tools were included more in my classes, especially testing, I believe I would’ve been even more prepared.

Clash Weights

Clash Weights is a website I created, but no longer host, to help players of the popular mobile game Clash of Clans. In this game, you join a clan, which consists of up to 50 other players. Your clan can initiate a war with another clan, where you attack the other clan’s players. The way your clan is matched up against another clan is based on your war weight. All of your troops and defensive structures have a weight assigned to them. Using the Clash of Clans API and the player’s player tag (a unique identifier for each player), Clash Weights calculates a player’s war weight.

The website was built using Ruby on Rails (my first time using Rails). The IDE I used was Aptana Studio 3. It was hosted on my Linode (Ubuntu server).

You can view the source files here.