Howto: Pause Repetier for filament reload at a specific layer number

Last year I posted Howto: Pause Marlin for filament reload at a specific layer number.  Since then I upgraded (I consider it an upgrade) to Repetier, and wanted to do the same thing.

The above link has a chunk of G and M codes  that could be inserted into the .gcode script at a given line number to pause it, allowing you to do a filament reload by hand. I figured you could do the same thing in Repetier.  As it turns out you can, and actually it’s a lot easier… presuming it works in the first place:

Repetier allows you to ‘Reload Filament’ via the LCD.  However, I immediately ran into a problem:  After the reload, it wouldn’t return to the correct position on the build plate:  It was always offset by some amount.  Basically ruining the print every time I tried.  Long story short:  You need to configure the firmware to “not home” after filament reload.  Two ways to do this:

Via the online configuration tool:  In the features tab under the “Filament Change” section, I set the “Homing after Filament Change” to “No Homing”.

Or in your Configuration.h set:

#define FILAMENTCHANGE_REHOME 0

Now, I can reload filament successfully via the LCD.

And via the M600 Mcode:  Up until then, whenever I’d try this code (which starts the filament reload process the LCD uses) I’d run into the exact same problem.  But now it works, so we can add it to our gcode file.

Why was this needed though?  You can follow the play-by-play on the Repetier firmware form here, but in a nutshell:  In my ‘start gcode’, I move my toolhead to the corner of my buildplate and ‘zero’ it there.  During Repetier’s ‘rehome’ operation during the reoload, it basically nukes those coordinates, thus putting an offset into my print.

Repetier’s ‘reload filament’ code is so simple (just that one line) compared to Marlin, you can easily enough by hand go into your gcode file, find the line number like this:

; layer 4, Z = 0.78

And insert it in where needed:

M600
; layer 4, Z = 0.78

Or, like mentioned in the previous post, you can use your slicer software (if it supports it) to post-process the gcode to add this in where you need.  Snip from last years post:

I slice using Simplify3D:  In a given process, it has a section in its ‘Scripts’ tab, at the bottom, called ‘Additional terminal commands for post processing’.  This allows you to enter in script to do a text-replace in your file, to edit it for you.  I learned about it on a forum post here.

To do the above using that system, you’d need to enter this text into that field:

{STRIP ";   postProcessing,"}
{REPLACE "; layer 4," "M600\n; layer 4,"}

And (like last years post),  some really important things to note:

  • The fist line that says ‘STRIP’ is super important:  If you don’t do this, Simplify3D will embed a copy of the REPLACE line in the header of the gcode, but won’t properly comment it out, basically ruining the gcode.
  • In the STRIP line, there needs to be exactly three spaces between the semicolon ‘;’ and the ‘postProcessing text.  Any more or less will screw up the strip.  If you copy-paste this code, make sure there are three spaces in there.
  • As you can see, you need to insert newline characters (\n) into the string you’re building for it to show up properly in the gcode later.

I have been made aware that you can also do something similar via Repetier Host:  The goal of this is to print entirely untethered, with precisely defined pause-points in the code for filament change, so host software (Repetier or otherwise) is out  of the question what what I’m trying to solve.

Visual comparison of ballnose stepover values on the X-Carve

I built my X-Carve back in December:  It’s been a great new tool to learn.  I’m still very new to the world of CNC, and like to visually grasp the concepts.  So I decided to do a series of tests to understand how ‘stepover’ values effect the finish-pass quality of the surface both on X, and on the XY axes.

The MeshCAM blog does a great job of describing the fundamentals of stepover here.

Here are the stats for the cuts:

  • Hardware:  Inventables 1000mm X-Carve.
  • 1/4″ ballnose bit, 2-flute upcut.
  • Feedrate 60ipm, DeWalt set 1 to 2.
  • Wood type:  Unknown (came from an old bookshelf bottom), but if I had to take a guess, I’d say pine.
  • 3d Design Software: Autodesk Maya
  • CAM: MeshCAM
  • Sender: Chilipeppr

The specifics from MeshCAM below. All values for all cuts were the same except of the stepover, and either “Cut along X”, or “Cut X then Y”.

meshcamSettings_x

I wanted really extreme examples, so I set the following stepover percentages for my test: 100% (1/4″), 75%, 50%, 25%, 10%, 5% (only done on X, not XY).

I started by designing a model in Maya that incorporates a variety of surface angles.  The inside volume is just over 2×2″, by about 1/4″ deep.

stepoverCompare_maya (that’s a flattened sphere in the middle)

I then made multiple different gcode (nc) via MeshCAM, and started cutting them.


The whole piece for the X-cut:

stepoverCompare_all

And the whole piece for the XY cut:

stepoverCompare_allXY (note, no 5% test here)


Individual close-ups below.  X pass on the left, XY on the right.

Note the rough-cut for all pieces took just about exactly 2 minutes.  All the times listed below are for the X & XY-Axis Finish pass in min:sec.  So to get the total cut time, just add two minutes to the below values.


stepoverCompare_100 stepoverCompare_100xy

  • 100% stepover, .25″ : This is obviously super rough.  I honestly expected the segment to be closer together.
  • X Finish Pass Time:  0:47
  • XY Finish Pass Time : 1:34

stepoverCompare_75 stepoverCompare_75xy

  • 75% stepover, .1875″ : Not too much different than 100 really.
  • X Finish Pass time : 1:03
  • XY Finish Pass time : 2:03

stepoverCompare_50 stepoverCompare_50xy

  • 50% stepover, .125″ : Still really rough, but arguably could do something artistic with the ridges at this point.
  • X Finish Pass time: 1:30
  • XY Finish Pass time : 3:00

stepoverCompare_25 stepoverCompare_25xy

  • 25% stepover, .0625″ : Carry on, nothing to see here.  Even with the XY pass, it’s still pretty rough.
  • X Finish Pass time: 2:50
  • XY Finish Pass time : 6:40

stepoverCompare_10 stepoverCompare_10xy

  • 10 % stepover, .025″ : Now we’re getting somewhere: Ridges are still visible, but small.  Pretty smooth to the touch, but you can still make them out.  Sanding could take care of this.
  • X Finish Pass time: 7:10
  • XY Finish Pass time : 14:00

stepoverCompare_05

  • 5% stepover, .0125″ : Done.  Finished.  Can’t make out the ridges with the naked eye.  Very smooth to the touch.  No sanding needed really.
  • X Finish Pass time: 14:20
  • No XY pass done.  Not much point considering the quality already achieved.

Final thoughts:

  • Notice on all X-cuts that the lower-left section of the hemisphere is rough.  Must have to do with the direction of the toolhead (left<>right on X) and the spinning of the bit (clockwise).  The XY cuts removed these issues.
  • If you are ok with sanding, 10%/.025 stepover is ok.  If you want to avoid sanding entirely, go with the 5%/.0125″ stepover.
  • Even though the 5% X-only stepover and  10% XY stepover took the same amount of time, the X-only has a far better surface quality.  You’d still need to sand the 10% XY one.
  • What do I take away the XY Finish pass?  The XY Finish Pass times are generally 2x the X-only times, but don’t really increase the quality.  Not much point unless you’re looking for ‘that look’ in the cuts.
  • I feel like the speeds could be greatly increased on the finish pass:  I was only running the router on speed 1 to 2.  The smaller the stepover, the smaller the amount of material you’re removing, so arguably the faster the toolhead could move to compensate for this under load:  There’s a lot of speed left in the router…. sounds like another good test to try.

Building the C-Bot 3d Printer : Part 32 : New Cooling Fan shroud, and bulldog clips

Jump to C-Bot blog index to see all the posts.


New Cooling Fan Shroud:

Running PLA out of a volcano nozzle means you need a lot of cooling.  I’ve tried a number of solutions in the past, all of which were mainly just “point a really big fan at the hotend”.  I don’t think this is the best technique (although better than nothing) :  You want airflow directed at the filament immediately after it is extruded.

So I buckled down and designed a new cooling fan shroud in Autodesk Maya, specifically designed for the C-Bot, and the E3d-V6 Volcano nozzle I have attached to it.  You can download this file for print from Thingiverse here.  The most recent update allows you to adjust its mount location, hopefully allowing it to work with a greater variety of extruders on the C-Bot:

epfs_B03

Screenshot from Maya of B03

Here’s the previous version (B02) on my C-Bot:

cbot_filament_cooler

Low Profile Bulldog Clips

After installing the new shroud, it sits so close to the build platform, that it hits the side and rear bulldog clips I am using to secure the glass plate.  I looked all over the web for any sort of ‘low profile’ versions of these clips, but couldn’t find anything.

After a bit of thinking, I realized I could modify my existing clips instead:  Presuming you have two pairs of needle-nose pliers, a hammer, and a vice, you can do this too:

low_profile_bulldog New in front, old in back.

  • To get the clips out, jam one needle-nose into the hole of the clip, slightly opening it.  Use the other one to pull out each of the tabs.
  • Put the tabs together in a vice (with the lips of the tab in the vice), and pound it with the hammer over until they’re both 45 deg or more.
  • Slide one tab back into the clip.  Holding the clip with a needle-nose, work the other one in.  That’s it.

Next up, install on your removable bed.


Jump to C-Bot blog index to see all the posts.

New 3D Print: Maui

I’ve 3d printed a few other maps, and got a lot of enjoyment out of it:

I recently spent a week in Maui:  This gave me inspiration to do a (painted) 3d print of it on my C-Bot:

maui_painted_main

The below post is an overview of how I designed, printed, and painted it.


Getting the Mesh Data

I first headed to the web app Terrain2STL : This is the great little program that lets you download 3d-printable terrain data.

However, no matter what you set the capture-box size to, it captures the same resolution of data.  If you make the box the size of the whole island of Maui, you end up with a pretty low-resolution capture mesh, based on the detail I want to 3d print.  So the only way to get a ‘high-res’ Maui mesh is to download many small chunks, that will later be seamed together to build a high-res island.

In Terrain2STL, I set the box size (ARC seconds) to 360.  Based on that size, I can adjust the latitude & longitude values by .1 values, to offset the box by one length in either direction.  So stating at the NW corner of Maui, I started capturing squares of it’s mesh.  In total, I made 30 captures.

Assembling the Mesh Data

In Autodesk Maya, I created a new scene, and started importing in each STL that Terrain2STL generated.  Starting in the NW corner, I’d import in the next stl, line it up with the last, and repeat that process.  Which gave me something that looked like this upon completion:

maui_maya_chunks_raw

I then went through the process of deleting all the mesh that wasn’t part of the island, stretching all the edges down to make a cliff-like effect, making a base for it, and creating the text.  I also did a lot of mesh cleanup since the Terrain2STL tool isn’t perfect.  Final Maya result:

maui_maya_final

tried to boolean all the mesh together, but Maya just wouldn’t do it.  This left me frustrated, but I realized that Simplify3D (the slicer I use) allows you to import in multiple mesh:  In Maya, I made sure the pivots of all the mesh were at the origin (so they’d all show up in Simplify3D in the correct location), the transformations frozen, and I exported every individual piece as a new STL.

Slicing The Data

I imported all the stl’s into Simplify3D:  They appeared to all line up correctly.  I wanted the island to be scaled 2x on the Z axis, so I grouped all that mesh, and applied the scale transformation.

But when I sliced it, I noticed lots of little gaps between the mesh chunks:

maui_sliced

Come to find out, even though all the mesh was lined up correctly, in some cases… it just wasn’t enough for Simplify3D : This spawned a painful process of me moving pieces, re-slicing, checking gaps, etc.  But eventually I got rid of them all.  The general prints stats were:

  • 200 micron, .4mm E3D-v6 Volcano nozzle
  • Maker Geeks Gray’matter Gray PLA @ @210 deg.  Bed @ 50 deg.
  • 90 mm\sec print speed.
  • 2 shells, 4 roof\floor. 10% ‘fast hexagonal’ infill.

Took around 13 hours to complete.  Based on my 12″x12″ build platform, printed diagonally it came out to 14″ across:

maui_noPaint

Painting the model

I wanted to try a new (for me) dry-brush technique to show off the mountains.

To start, I shot the whole model in a pleasing Rust-Oleum ‘Meadow Green’ color:

maui_midPaint

After that dried, I sprayed “Maui Blue” (can’t believe I found a color that matches the medium I’m painting) onto a foam brush, and painted up the ocean.  Finally, I sprayed a light-brown onto a paper towel, and then brushed it across the mountain peaks for the final result.

maui_painted_NW maui_painted_SW

Was really pleased with the results!

Tuning jerk values in Repetier

(Note:  Based on continual feedback I’ve been rewording sections, to hopefully make it clearer)

Now that I’ve switched my C-Bot over to new electronics (RADDS) and firmware (Repetier), it’s time to start getting serious about tuning:  After running some initial test prints, I wasn’t satisfied with the ghosting/ringing that was occurring on the prints, so I decided to tweak the Repetier jerk settings, since I know they can have an impact.

The goal of this test:  Really, to compare how jerk impacts print quality, and print speed (the value you set in our slicer) vs print time (how long the print actually takes).  I’m not making any recommendations based on these results:  You can make your own decisions based on the data presented below, and how that may impact your printer based on it’s mechanics & firmware.


I adjusted the jerk on the fly from the LCD, storing them back to EEPROM before each print.  The default jerk values in Repetier are 20, and can also be set via the ‘Mechanics’ tab via the online configuration tool (requiring a re-flash of the firmware from the Arduino IDE).  There is also a nice description of Jerk via the Repetier Firmware Installation Page.  From that page though, the high-level important stuff:

You want high jerk values, because

  • Printing time is reduced.
  • Print shows less blobs.

You want low jerk values, because

  • It causes less mechanical stress to your printer.
  • Moves are smoother.
  • Filament has better adhesion at directional changes.
  • Reduces printer noise.
  • You loose steps with higher values.

Other Hardware\Slicer Stats:

  • Hardware is RADDS\Arduino Due (32-bit ARM).  Stepper drivers are SD6128’s, at 1/32 microstepping, turned to .55v
  • The C-Bot is core-xy kinematics.
  • I sliced these in Simplify3D:
    • 2 shells, 4 roof\floors, 10% ‘fast hexagonal’ infill.
    • Outline underspeed at 75%:  I didn’t realize this until after the test (since it’s sort of standard operating procedure for better quality), but in hindsight I wish I’d turned it off for this test.
    • 200 micron layer heights.
  • .4mm nozzle on an E3D-v6 Volcano.
  • Print speed adjustment for cooling is disabled (no slowing down for small layers):   I didn’t want the print times to be adjusted because of print cooling.  However, the filament cooling fan is enabled (since I’m printing in PLA).
  • Used MakerGeeks Gray’Matter Gray PLA, printed @ 210 deg (they recommended 230 on the spool, but it seemed unnecessary).
  • In Repetier, my xy acceleration values are 1000 (default).

I printed two sets of three #3DBenchy models:  I chose the benchy since it’s small, but complex.  The first set was with a jerk of 10, the second with a jerk of 40.  For each set of three, printed them with these speeds:  60/90/120 mm/sec.  Below are a list of the times it took to print each.

Stopwatch was started when extrusion began, after nozzle & bed warmup.  Stopwatch was stopped when print completed, and end gcode ran.

Print speed/time comparisons, sorted by jerk:

  • JERK 10 | 60mm/sec:50min | 90mm/sec:43min | 120mm/sec:40min
  • JERK 40 | 60mm/sec:50min | 90mm/sec:35min | 120mm/sec:30min

compare_all(click all images for bigger pics)

What does this tell us about speed/jerk tradeoffs?


Numeric comparison of print time:

Based on the above speeds (mm/sec) and print time (in min) from above.

Comparing JERK 10 to itself:

  • 90mm/sec had a print time 1.16x faster than 60mm/sec, even though the speed was set 1.5x faster.
  • 120mm/sec had a print time 1.075x faster than 90mm/sec, even though the speed was set 1.33x faster.
  • 120mm/sec had a print time 1.25x faster than 60mm/sec, even though the speed was set 2x  faster.

Comparing JERK 40 to itself

  • 90mm/sec had a print time 1.43x faster than 60mm/sec, even though the speed was set 1.5x faster.
  • 120mm/sec had a print time 1.17x faster than 90mm/sec, even though the speed was set 1.33x faster.
  • 120mm/sec had a print time 1.66x faster than 60mm/sec, even though the speed was set 2x faster.

Comparing JERK 10 to JERK 40:

  • 60mm/sec jerk 40 had the exact same print time as jerk 10.
  • 90mm/sec jerk 40 had a print time 1.23x faster than jerk 10.
  • 120mm/sec jerk 40 had a print time 1.33x faster than jerk 10.

Things observed from the numbers:

  • There is not a linear relation in increasing the ‘speed‘ in mm/sec and reduction in print times (which I knew, but it’s nice to see real data back this up).  Meaning, if 50mm/sec took 50 min to print, 100mm/sec won’t take 25min, it will be some value in-between (based on factors like jerk, acceleration).
  • Interesting that 60mm/sec speed had the exact same print times for jerk 10 & 40 :  Guess at that speed the jerk-clamping has a lower effect.
  • There is definitely a point of diminishing returns on high print speed and low jerk.  At a certain point the low jerk clamps the speed so much that it can never accelerate high enough to have an appreciable effect on print time (this is my theory at least).
  • The larger (40) jerk value had the widest range in print time variance (30 min -> 50 min) since (I presume) the jerk wasn’t clamping down the speed so much.

Visual comparison of quality:

Comparing Jerk 10 to itself:

compare_jerk10

Across the board all speeds of jerk 10 did well quality-wise.  Nearly no ringing at 60mm/sec, and minimal ringing on the 90 & 120mm/sec.   The only really visual differences is the discoloration of the PLA as it was printed faster.

Comparing Jerk 40 to itself:

compare_jerk40

Ringing across all speeds.  Passable at 60mm/sec, but I don’t like what I see at 90 & 120.

Compare 60mm/sec:

compare_60mmSec

While both had the exact same print time, there is virtually no ringing on the jerk 10, while ringing is visible on the jerk 40.  A strange random print artifact showed up on the smokestack of the jerk 10 that didn’t show up on any other prints.  Ghost in the machine.

Compare 90mm/sec:

compare_90mmSec

Very slight ringing on the jerk 10, ringing is quite apparent on the jerk 40.

Compare 120mm/sec:

compare_120mmSec

Ringing is just starting to show on the jerk 10, and jerk 40 looks like a train-wreck.  Or a ship-wreck.

Final Thoughts, Opinions:

  • The default jerk values in Repetier are 20, which is why I wanted to try two values on either side that would really show off the differences, since I was still getting rigging at 20 at 90mm/sec before this test.
  • I think that you need to make a decision when starting the print:  Quality vs speed?  All depends on what you’re printing.  If this is a structural part where the visual artifacts of ringing are tolerable, then crank up that jerk.  But if it’s a artistic piece, then lower it down.  What’s nice is that you can adjust this from the LCD in Repetier and set it in EEPROM per-print, not requiring any type of re-slicing.
  • Maybe I’ll just set it back to 20.  HA!