Skip to content

Archive for November, 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.


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.


Marlin 1.1.6 – FVM Kossel

Apart from putting a lot of hours on both of my Kossel printers, as a software nerd I try to stay current with the latest, and sometimes not the greatest, firmware that’s running the printers.

Specifically the Fraser Valley Makerspace Kossel’s.

What seems like ages ago now, but a mere two plus years, I started out with 1.0, and quickly moved to 1.0.2 since it was easier to adjust the software for any mechanical build discrepancies. Eventually the Marlin developers included most of my hacks into the product so it was easier and at the same time, more difficult, to update.

To my mind the stumbling block is that when the primary market for 3D printers uses the Cartesian system, anything else warrants less than a cursory glance and testing. At least this has been my experience. Fortunately, there’s enough of us in that small percentage who can usually figure things out that went amiss.

When I started updating the first road block was looking at my old firmware and trying to figure out what they called it now, where they hid it and what delta configuration to use as a basis. For example, take a gander at the number of different printers than Marlin supports:

Marlin Printers

Now imagine each of those directories can hold a number of “variations” of said parent printer. Ah yeah. In the delta area there are a number of choices:

Marlin Delta

Just like fishing for real Marlin, the key to success is using the right bait. To be honest I haven’t gone through each of the iterations to see exactly what the difference is. Thus I was using “Generic” as the basis. Until I tried to use version 1.1.4 of Marlin. It didn’t work.

After a couple days of trying different configs, I ended up with the “kossel_mini” and that’s the closest to what the FVM Kossel has. When I got 1.1.6 working, I used the kossel_mini again and again, that’s the one I managed to get working.

It would be great to simply copy over your old delta configuration files, but alas, the rest of Marlin has changed so much that it’s not possible to do that.

I’d love to say that once you find the right config file, the hard part is over. Sadly, maybe an hour later it might be. But there are some bugs in Marlin that seem to only affect delta printers that even the developers have no idea why that might be. So, back to hacking the firmware to make it work. The way it should.

Firmware 1.1.6

Before I outline all the steps, let me say that make darn sure you have a current copy of the firmware used by your printer, a duplicate copy, on a flash drive or somewhere you won’t screw it up. In the event you foul something up, you’ll have the old version to put back and get the printer running again!

Secondly, if you’re under the impression that newer is “better”, forget that notion. I’ve run 1.0.2 thru 1.1.6 in side by side tests on my printers and I’ll be hornswoggled if I can see a difference in print quality with the same settings. I’ve read the notes on what has been “fixed”, “enhanced” or “new” and okay. If they say so, all I have noticed is the planner in firmware seems slightly faster. Ergo my Kossel’s have always just printed.

So as they say, if it’s not broken, you can’t fix it. Or as I sometimes am the living proof of, if it’s not broken, you’re not trying hard enough. YMMV.


Download Marlin from the GitHub link. Click on the download/clone button and download a “zip” of the archive.

You’ll have to move that into your Arduino sketch folder and unzip it. In the “example configurations folder” look for the two “kossel_mini” configuration files and copy those into the main Marlin directory. It will replace the two cartesian files of the same name.

Run the Arduino IDE and open your original firmware and the new Marlin (yeah, its name is just Marlin). I’d suggest you instantly save the plain Marlin you just opened as something like “Marlin 116-1” so you know it’s version 116 and “1” (to indicate sort of a first modification to it). Subsequent “mods” would be 116-2, 116-3 and so on. Thus you can always “rewind” to a prior version that worked before you fouled it up…;-)


The changes you are going to make are in 116 and in three files. The main is “Configuration.h”, bug fix is in “ultralcd_impl_HD44780.h” and the hack fix is “watchdog.cpp”.

The #xx is the LINE number in 1.1.6 and the first line is what you will find in the file. The line UNDER it is what you need to change it to. You will be using some values from your OLD Marlin 1.0 or 1.0.2 file. I have commented the second line as well in some cases, you don’t need to add my comments in.

Also keep in mind that the lines MAY look identical, but pay attention to any “//” marks which simply disable the line. There’s a bunch we don’t use.


#77: #define STRING_CONFIG_H_AUTHOR "(none, default config)" // Who made the changes.
	#define STRING_CONFIG_H_AUTHOR "(YouWho, FVM_Printer)" // Who made the changes
#127 #define CUSTOM_MACHINE_NAME "Mini Kossel"
	#define CUSTOM_MACHINE_NAME “FVM_Delta”// your custom delta name
#226 #define POWER_SUPPLY 1
	#define POWER_SUPPLY 0

#286 #define TEMP_SENSOR_0 7
	#define TEMP_SENSOR_0 1// temperature sensor used by FVM

#325 #define HEATER_0_MAXTEMP 275
	#define HEATER_0_MAXTEMP 260

#330 #define BED_MAXTEMP 150
	#define BED_MAXTEMP 100// max EVER would probably be 110

#335 #define  DEFAULT_Kp 22.2
	#define  DEFAULT_Kp 20.03// look this up in your current configuration.h file

#336  #define  DEFAULT_Ki 1.08
	 #define  DEFAULT_Ki 1.25// look this up in your current configuration.h file

#337 #define  DEFAULT_Kd 114
	  #define  DEFAULT_Kd 80.01// look this up in your current configuration.h file

#442 #define THERMAL_PROTECTION_HOTENDS // Enable thermal protection for all extruders
	//#define THERMAL_PROTECTION_HOTENDS // disable thermal protection for all extruders

#443 #define THERMAL_PROTECTION_BED     // Enable thermal protection for the heated bed
	//#define THERMAL_PROTECTION_BED     // disable thermal protection for the heated bed

#493 #define DELTA_CALIBRATION_RADIUS 78.0 // mm
	#define DELTA_CALIBRATION_RADIUS 100.8 // mm

#499   #define DELTA_PRINTABLE_RADIUS 90.0 // mm
	  #define DELTA_PRINTABLE_RADIUS 108.0 // mm

#502   #define DELTA_DIAGONAL_ROD 215.0 // mm
	  #define DELTA_DIAGONAL_ROD 300.93 // mm// look this up in your current configuration.h file

#505   #define DELTA_HEIGHT 250.00 // get this value from auto calibrate
	  #define DELTA_HEIGHT 212.66 // look this up in your current configuration.h file

#510   #define DELTA_RADIUS 105.2 //mm  Get this value from auto calibrate

In your old configuration.h file, there are 3 values that make up this the DELTA_RADIUS value.
For whatever reason the developers combined them in the 1.1.4 and newer to make it, ah, easier. For them I think.


Pull out your calculator, look up the values for DELTA_SMOOTH_ROD_OFFSET, DELTA_EFFECTOR_OFFSET, and DELTA_CARRIAGE_OFFSET,
plug them in and figure out what the DELTA_RADIUS is and replace my 145.86 with your number.

#515 #define DELTA_TOWER_ANGLE_TRIM { 0.0, 0.0, 0.0 } // get these values from auto calibrate

If you have done a calibration for X, Y and Z, you can enter the correction numbers here.
I use a design and spreadsheet from Thingiverse for calibration and it’s how I ended up with the
numbers for the trim. If you haven't done it, leave them as 0.0, 0.0, 0.0...

	#define DELTA_DIAGONAL_ROD_TRIM_TOWER { -0.49, 0.14, 0.35 }// these are MINE, use the above to link to find yours!

#561 #define Z_MIN_PROBE_ENDSTOP_INVERTING false // set to true to invert the logic of the probe.
	//#define Z_MIN_PROBE_ENDSTOP_INVERTING false // disable, we don’t have a probe

#593 #define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 80, 760*1.1 }  // default steps per unit for Kossel (GT2, 20 tooth)
	#define DEFAULT_AXIS_STEPS_PER_UNIT   { 80, 80, 80, 145 } //look this up in your current configuration.h file

#600 #define DEFAULT_MAX_FEEDRATE          { 500, 500, 500, 25 }
	#define DEFAULT_MAX_FEEDRATE          { 500, 500, 500, 300 } //look this up in your current configuration.h file

#618 #define DEFAULT_ACCELERATION          3000    // X, Y, Z and E acceleration for printing moves
	#define DEFAULT_ACCELERATION          1400    // X, Y, Z and E acceleration for printing moves

Values higher can give ringing on outside perimeters/corners but print faster, values lower than this give clean corners but print slower.

#620 #define DEFAULT_TRAVEL_ACCELERATION   3000    // X, Y, Z acceleration for travel (non printing) moves
	#define DEFAULT_TRAVEL_ACCELERATION   2000    // X, Y, Z acceleration for travel (non printing) moves

If you have fans, or a hot end that has some mass/weight to it, lower values help reduce the shock of the move.

#630 - #633:
#define DEFAULT_XJERK                 20.0
#define DEFAULT_YJERK                 20.0
#define DEFAULT_ZJERK                 20.0 // Must be same as XY for delta
#define DEFAULT_EJERK                  5.0

Values lower make for smoother movement and print. Faster means more jerk and not as clean outside finish. I suggest the ones below:

#define DEFAULT_XJERK                 10.0
#define DEFAULT_YJERK                 10.0
#define DEFAULT_ZJERK                 10.0 // Must be same as XY for delta
#define DEFAULT_EJERK                 20.0

	// #define Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN // disable this

#767 #define Z_PROBE_ALLEN_KEY
	//#define Z_PROBE_ALLEN_KEY // disable this levelling option

#860 - 862
	#define INVERT_X_DIR false // DELTA does not invert
	#define INVERT_Y_DIR false
	#define INVERT_Z_DIR false

Change all to (make the false into true):

	#define INVERT_X_DIR true
	#define INVERT_Y_DIR true
	#define INVERT_Z_DIR true

#870 - #874
	#define INVERT_E0_DIR false
	#define INVERT_E1_DIR false
	#define INVERT_E2_DIR false
	#define INVERT_E3_DIR false
	#define INVERT_E4_DIR false

Change all to (make the false into true):

	#define INVERT_E0_DIR true
	#define INVERT_E1_DIR true
	#define INVERT_E2_DIR true
	#define INVERT_E3_DIR true
	#define INVERT_E4_DIR true

#1122 #define HOMING_FEEDRATE_Z  (200*60)// pretty fast!
#define HOMING_FEEDRATE_Z  (80*60)// more of a smooth speed

#1140 #define EEPROM_CHITCHAT   // Give feedback on EEPROM commands. Disable to save PROGMEM.
	//#define EEPROM_CHITCHAT   // Disable to save PROGMEM.

#1148 #define HOST_KEEPALIVE_FEATURE        // Disable this if your host doesn't like keepalive messages
	//#define HOST_KEEPALIVE_FEATURE        // Disable

#1149 #define DEFAULT_KEEPALIVE_INTERVAL 2  // Number of seconds between "busy" messages. Set with M113.
	//#define DEFAULT_KEEPALIVE_INTERVAL 2  // disable

#1150 #define BUSY_WHILE_HEATING            // Some hosts require "busy" messages even during heating
	//#define BUSY_WHILE_HEATING            // disable

#1170 - #1171
	#define PREHEAT_1_TEMP_HOTEND 180
	#define PREHEAT_1_TEMP_BED     70

Change this to what you normally print at (mine for example)

	#define PREHEAT_1_TEMP_HOTEND 200
	#define PREHEAT_1_TEMP_BED     60

#1174 - #1175
	#define PREHEAT_2_TEMP_HOTEND 240
	#define PREHEAT_2_TEMP_BED    100

Change this to an ABS setting (or a secondary filament for example):

	#define PREHEAT_2_TEMP_HOTEND 235
	#define PREHEAT_2_TEMP_BED    90

#1342 //#define ULTRA_LCD   // Character based
	#define ULTRA_LCD   // LCD 2004 (20x4)

#1352 //#define SDSUPPORT
	#define SDSUPPORT// our 2004 LCD’s have SD card slots

#1360 //#define SPI_SPEED SPI_HALF_SPEED
	#define SPI_SPEED SPI_HALF_SPEED// to help on some of the slower SD cards

	#define REVERSE_ENCODER_DIRECTION// rotation in a natural direction

#1456 #define PANEL_ONE
	//#define PANEL_ONE// disable this, wrong panel for 2004

	#define REPRAP_DISCOUNT_SMART_CONTROLLER// display and controller used on the FVM Kossel

Now go back and check it. Twice if need be… Then SAVE IT.


Next you are changing the time out. According to the dev’s, this shouldn’t affect our deltas. Except, it does.

So we have to fix it. Where it rears its ugly head is when you are doing a LONG STRAIGHT LINE with a high delta segments per minute count (like 200). If the line takes longer than 4 seconds to print, there is a “time out” and the Arduino Mega wanders off to never never land. I.e. it just crashes and the head sits exactly where it is and the heaters all shut off.

You have to reboot the printer to get some control back. The changes are done by changing the WDTO_4S (timeout in 4 seconds) to WDTO_8S to a time out in 8 seconds.

#36     _WD_CONTROL_REG = _BV(WDIE) | WDTO_4S;
	    _WD_CONTROL_REG = _BV(WDIE) | WDTO_8S;// we get time outs otherwise

#38	    wdt_enable(WDTO_4S);
   wdt_enable(WDTO_8S);// we get timeouts


On the current IDE, 1.8.4 I’m using it doesn’t like the word CHAR in caps, and in the ultraLCD file, sure enough, there are two lines in caps. Changed them to lowercase and it will compile.

#713 lcd.print((CHAR)LCD_STR_THERMOMETER[0]);
	lcd.print((char)LCD_STR_THERMOMETER[0]);// char should be lower case

#716	 lcd.print((CHAR)LCD_BEDTEMP_CHAR);
       lcd.print((char)LCD_BEDTEMP_CHAR);// char should be lower case


If I haven’t cured your insomnia by this point, you should have been able to upload the new code to your printer and be ready to go.

One last thing though, when ever I do a firmware change, I always check to make sure the bed is still level. Sometimes the math in the firmware is more or less accurate than what I was using so I just make sure. Don’t want the hot end smashing in the glass. Do we.

You know, for all the automation we have these days, you’d think someone would also come up with a program that would grab all our old configuration values, cram them into the new one, ask us specifics for old or updated items and we’d be done with it. To me, configuration should be seamless and painless. Please forgive me. I also believe in Santa Claus and the Easter Bunny.