Last month I posted about installing a ducted fan on Squirty. After installing the fan I read issue 42 of MAKE magazine and became excited about two ideas to try for testing out the ducted fan. As is often the case, I got a bit distracted trying out these ideas so it’s taken me a while to get round to answering the original question of whether the ducted fan helps with print quality or not (short answer is yes, but more work needed for Squirty to match commercial desktop printers).
The issue of MAKE includes the 2015 3D printing buyer’s guide. This year they used a very nice quantitative approach to rank print quality across different printers. They created a set of test print items, each one designed to test a specific aspect of print quality such as bridging performance or dimensional accuracy. They also created a guide for evaluating each aspect on a scale 1-5. The nice thing about this is because they ranked all the major desktop printers against this guide I can use these prints to see how Squirty compares to printers made by PrintrBot or MakerBot.
The main idea of putting in the ducted fan was to improve bridging performance so I used MAKE’s bridging test piece. This is made up of a series of bridges of increasing span. The idea is to see which bridge the printer fails on. The shortest bridge is 20mm and the longest is 60mm.
I tried the bridge piece with three fan settings. The first was with no fan. The second had the fan on at 57% Pulse Width Modulation. When I installed the fan I worked out that 57% is the right setting to give 12V, which is what the fan is rated for. I did the 3rd run at 100% PWM which is 19.5V (I know the maths don’t quite work here – the values are based on trials). 19.5V is much more than the fan is rated for, so I don’t really want to run it like this for extended periods. I’ve got vague, half-formed fears of the fan sticking somehow, overheating and catching on fire. You can see the results in the photos below.
My photography skills are not great, but I think you can still see in the images that there is an improvement as the fan speed increases. I’ve evaluated them using the MAKE guide which says:
- Assign a “1” if any bridge has dropped infill.
- Assign a “2” if only the longest two bridges have dropped infill.
- Assign a “3” if none of the bridges have dropped infill, but all have dropped perimeters.
- Assign a “4” if the shortest two bridges compiled without any dropped perimeters.
- Assign a “5” if all bridges compiled without any dropped perimeters (drooping of less that 2mm is acceptable).
The wording is a bit off since you should evaluate “1” if any bridge has dropped infill, but evaluate “2” if only the longest two bridges have dropped infill. I think the only sensible way to interpret is that “1” should really read “if any bridge other than the longest two has dropped infill”. Based on this interpretation I think the 100% fan gets a “2” rating and the others get “1” ratings. The 57% fan is much better than 0% fan, but for some reason it dropped infill on the bottom layer (maybe because of the heated bed?).
I’ve annotated some pictures below showing what I’ve classified as dropped infill etc.
My conclusion is that ducted fan does help a lot, but it’s not the only piece of the puzzle. I think I will have to play with my slicing settings to get better prints. In particular I think the bridging speed is probably too low.
So that settles ducted fan for now. However, I mentioned that I got two ideas from MAKE about how to test the bridging. The first was to use the MAKE test piece, the second idea was to use OctoPrint. OctoPrint is a piece of 3D printing host software. Previously I have always used Pronterface which was the default for the RepRap when I bought my kit. To allow my printer to run in a different room from my computer I set it up to run on a Raspberry Pi and then controlled it using a VNC connection (see Stealth Printer I). This worked OK, but the VNC could sometimes be a bit slow and unreliable. The exciting thing about OctoPrint is that it comes with a web interface which makes everything faster and easier. It also has built in support for a webcam to allow you to view what the printer is doing over a network and create timelapses of prints. To complete all the coolness a kind soul created a Raspberry Pi SD card image called OctoPi that has everything you need to run OctoPrint on a Pi using the Raspberry Pi camera module.
The timelapse is what interested me from a bridging perspective because I thought it would allow me to see what’s happening when a print fails. In the end it wasn’t so helpful for working out what’s happening during bridging but it is fantastic for making setting up prints smoother and less frustrating.
Installing OctoPrint was very straightforward. I set it up with the camera on a long cable mounted on a set of helping hands (with the assistance of blu tack).
The performance was a bit iffy at first – it kept losing the connection to the printer half way through the print. I think this was something to do with my router and wifi adapter rather than the software though. I replaced the wifi connection with an ethernet powerline connection and it now is very reliable. It is very straightforward to use. Currently I have the camera mounted at the top of the printer which gives a reasonable view of what’s going on. I think it is a bit too close though – focus looks a bit fuzzy.
I’m still figuring out the timelapse. The timed mode has two settings: “Interval” and “Timelapse Post Roll (in seconds)”. The first setting is how often it takes a photo to make the timelapse video, but the second setting had me scratching my head. Initially I thought it was how long it would hold the final image on the screen “Post Roll” but it turns out that instead this is the total length of the video that it creates. E.g. if you have a 1 hr print with “Interval” = 60s and “Timelapse Post Roll” = 30s it will create a 30 second long video with 60 frames, i.e. framerate of 2 fps. The video below was created before I worked this out, which is why it is so short.
As you can see it is not so useful for working out what is happening during bridging. Even if you create a much longer video you can’t bring the camera close enough to the print head to a decent view of how it’s printing (it goes out of focus).
One more cool thing about OctoPrint – since it’s used over the network you can set up port forwarding on your router and then check on your prints when you are out of the house. You can even cancel a print that isn’t going well. I’ve tried this out and it works fine. Of course putting the printer on the web comes with the risk that someone hacks into it and sets your nozzle temp to 1000 deg C to burn your house down. The developers of OctoPrint recognise this and include a password feature that you are strongly encouraged to set up.
You can see in this post how easily I get distracted and sucked in to other projects. There is just so much cool stuff that can be done and so little time! Also I tend to get stuck solving problems that are tangential to the goal I start out with. I’ve got one more random aside that provides a good example of this – while trying to work out how fans affect bridging performance I ended up trying to work out how my ISP sets my IP address…
How did this happen? Well, setting up port forwarding for OctoPi drove me nuts initially because I couldn’t get DynDNS to work. You need dynamic DNS for accessing your home network from the internet because unless you pay for a static IP the address of your router on the internet will change at the whim of your internet service provider. DynDNS provides an address that your router can automatically link up to so that you effectively have a static IP. I first set up DynDNS about a year ago for accessing a NAS and it worked fine. However when I tried to set it up for OctoPrint I couldn’t connect. I also found the NAS connection wasn’t working any more. Long story short I changed ISP a little while ago to MyRepublic and they use some fancy virtual IP setup. The clue was that my router thought that my external IP was an address that was different from the address I saw when I asked google what my IP address was. This setup stops DynDNS from working, but MyRepublic solved the problem for me by selling me a static IP for a one-off fee of $50. Pretty reasonable!
OK that’s enough rambling for this time. Back to working on the web interface for BeerBot…