Skip to content

November 26, 2017

Octoprint vs SD

I’ll be the first to admit that being retired gives me way too much time to try out different things. Lately with the monsoon season upon us, golf is notably absent from my to do list, so I’ve been spending a fair bit (okay too much time) in the shop.

Which means I’ve been printing up 3D stuff doing tests to see “what if”. And some of it has been pretty darn eye opening. You know, the kind you don’t see coming.

Like new filaments on Amazon, stepper driver tests and the last one, Octoprint VS SD card prints. When it comes to 3D print quality, I tend to be a little OCD about it, and like most I have my brands of PLA that I go to, and others that I avoid. But the filaments I’ll leave for another day. Today, it’s my little shoot out between Octoprint and SD card printing.

3D Print Servers

I originally started out using Astrobox, but found out I’m not the target market for it.

I want more hands on with a printer controller than what Astroprint wants to do. Apart from my head not being in the “cloud”, when I print I want local control, I want complete slice control, I want it all. See, OCD.

Thus I’ve been using Octoprint for quite a while and haven’t had any issues with it at all. Til now. And I’m not sure why, but I have a suspicion….just no proof. So keep that in mind.

Essentially you send a GCODE file to the Octprint server running on a Raspberry PI3, then connect it via any computer on the LAN, away you go. I like the way it works, the connection, the information it gives me.

Then I happened to be reading that some people were saying that the SD card gave a better print quality. And in some cases faster…which, really doesn’t make a fat lot of sense…unless you dive in and look at some of the issues.

Curiosity got the best of me and I like to verify things I read about rather than just relying on Twinkles spouting off on some forum.

Print Test Setup

I found a design on the Thingiverse, Toms Simple Chunky Rocket…this is a picture of his print out.

Rocket

I used PRUSA’s 1.34.1 Slic3r, vase mode, .2 layer height, 30mm/s. The rocket is 200mm tall, diameter in the fat section is 80mm or more. So, tis a biggie. At the speed I chose, three hour print time.

I used Hatchbox Transparent Red so not a solid colour, easier to see print issues.

Marlin firmware 1.1.6 was used for both prints.

Octoprint Output

I was surprised when Octoprint was printing I could see the printer almost jog once in a while. Which didn’t make any sense since it’s going pretty darn slow. But when the print was complete, yeah. Wow.

Fullsizeoutput 2be8

One look at the surface and you can see the staggered looking tracks that oscillate all around the rocket body. When I saw the staggering, apparently I wasn’t dreaming. Those are lumps you can feel.

SD Card Output

I saved the SAME GCODE from the slicer onto the SD card and used the front control on the printer to select the rocket and print it. I did not use Octoprint so I could upload the GCODE to the SD card, nor did I use Octoprint to initiate the print. I did it all from the printers control panel.

In the middle (these are the front views of the prints), there is exactly one “pimple”. And that’s it. For all I know the SD card had a bit of a read problem at that one point.

Fullsizeoutput 2be7

Other Differences

For whatever reason, on the Octoprint print output there is a rather large seam right up the back. The camera washed it out but if you look at the top of the tail fin, you can see the start of it, and that wide streak goes right up to the top. Kind of a skunk stripe if you like…:-)

Fullsizeoutput 2be9

This is fascinating because in vase mode because the hot end never stops and just keeps going around and up. How it created the seam is beyond me.

But WHY?

Well that’s the $2 question isn’t.

I went looking for answers and all I can say is, I have a suspicion.

Octoprint sends the data through the USB connection to the Arduino MEGA that runs the RAMPS control board. There’s more than a few people who seem to have problems with communication like this. As in missed lines of GCODE, repeated sends of GCODE, or simply a failure to connect.

I put on my Tom Terrific thinking hat and looked at the MEGA I have in the printer. Then I tried connecting up Pronterface to the printer and I noticed something right off. Pronterface had some issues connecting to the MEGA via USB. For grins I tried Repetier Host, same delay in connecting and then it seemed “ok”.

But it got me thinking. My other printer connects instantly. mmmm. What’s the difference?

The Arduino MEGA used on my test printer is an off shore knock off that uses the low cost CH340G chip to handle the USB to serial connection. My other printer that just works, has an ATmega16U2 chip that performs the USB to serial.

I run at 250000 baud, 25 kilo bytes per second. This doesn’t seem like much, but I’m thinking that the low cost CH340G is fine in 90% of the cases it’s used in, but when it comes to 3D printing, the ATmega16U2 will blow the doors off it.

So yep, my plan is to remove that Arduino board and replace it with the better communication chipped one.

Will that fix it? My logic says it can’t make it any worse. Nothing to lose and from the printed samples, a lot to gain if it works.

[UPDATE] – So after swapping out the MEGA for a official one, the seam is still there, slightly less pronounced and the lumps are still there as well, but it more of a pattern. Which tends to make me think this is more of a firmware thing than anything else.

Read more from 3D

Comments are closed.