Archive for the ‘ Electronics ’ Category

A comparison of Simplify3D and Slic3r Prusa Edition

allBenchies_web

I printed so many 3dBenchies for this comparison….

Preface

I’ve been a 3d printing hobbyist for right around five years now:  I purchased my first printer, a Makerbot Replicator 1 (which I still own, still prints great) in March of 2012.  Since then I’ve used multiple slicers to generate my gcode, but mainly (and in order):  ReplicatorG, MakerWare (now MakerBot Print), and Simplify3D.  And for the time I used them, they’ve all been great.  I’ve also built my own printer a few years ago.

However, and as much as I like Simplify3D:

  • Despite it does so many things so well…
  • The fact that I paid cash money for it.
  • And that their updates are so few and far between…
  • And the updates don’t include fixes to some major issues I feel it has…

I thought I should revisit what slicer software 2017 has available.

I know that slicer software is like religion, politics, and CAD software:  People can get very attached to them.  And there’s a good chance someone out there is going to disagree with my findings : That’s great, I’d like to hear your perspective, leave a comment below.  Everyone uses the software differently, and the things I find important (or not) could be polar opposite of someone else.

Based on a general poll I posted, it looks like these slicers are out in the wild and commonly used.  Yes, there are more, but these seem to be popular:

After reviewing all of them, and for reasons listed below, I decided to investigate Slic3r Prusa Edition.  And mainly that edition over vanilla Slic3r because vanilla Slic3r hasn’t been updated since mid 2015, while the Prusa edition is being actively developed (+ extra fancy features).  I know vanilla Slic3r is still being developed, it’s just been a while since an official release has gone out.

Update:  As it turns out, dev releases of vanilla Slic3r are generated often, so it’s pretty easy to be on the cutting edge, find downloads here.

This is not a post designed to bash Simplify3D and espouse the values of some other slicer:  My goal is to make it an honest comparison of the two software.  It should be noted however, I have over two years of experience with S3D, and only a few weeks on Slic3r, but so many of the concepts of the software overlap, I feel I have a pretty good grasp of it.

Finally, why am I writing this? It’s taken quite a while to do all the research!  Mainly for myself actually:  I wanted to get all my research down on paper to see if I should make a slicer switch or not.  There are so many facets to all of this, I wanted to get it in one place to make sure I wasn’t missing anything.

I will continue to update it over time, see bold “Update” text below.

What I used for testing

  • 3D printer hardware:
    • My custom core-xy C-Bot : It has a 12x12x21″ build volume, auto-leveled on a heated, removable, mic6 aluminum bed covered in a PEI sheet.
    • Runs RepRapFirmware on 32-bit RADDS/Due electronic.
    • All steppers set to 1/128 microstepping using SD6128 drivers.
    • I currently print mainly MakerGeeks PLA out of a .6mm E3D-v6 Volcano nozzle at 230 degrees on a 60 deg bed, with active PLA cooling from a ducted 24cfm fan.
  • 3D Model:  I used the good’ol 3dBenchy as my test model for all comparisons, except the thin-wall compare, it’s linked to below.

So let’s get into it…

Simplify3D

Version Tested: 3.1.1

Unique things it does well

These are things I’ve found it to do, that other slicers may not.  Or it does better.

  • Multiple ‘Processes’:
    • A process in S3D is basically a print preset.  And you always need at least one.  The power comes into play however, that you can assign them per mesh to print (if there are multiple being printed), or by layer height.  You can even ‘group’ processes so as to link their similar parameters together, so changing one changes all others (see how this works here).  This is extremely powerful, and arguably one of the best parts of the software.  And when I need it, it’s great.  But honestly 95% of the time I don’t need it.
    • Not that it effects me so much, but it has pre-configured profiles for many printers, allowing a larger market-share to have success with the software sooner.
    • I should note that I’ve found no other slicer that treats “processes” as well as S3D.  This is a major selling point, and brings much power and convenience when needed.
  • Print options:
    • In its ‘Advanced Mode’, there’s a knob to tune just about every aspect of your print.
  • Post processing of gcode:
    • You can modify the output of the gcode via S3D’s own custom syntax.  You can see this post on an example of how to do it.
  • Printer communication & machine control panel
    • S3D has a robust “machine control panel” for operting your printer, issuing gcode, printing gcode either over USB, or via SD.  It also allows you to make your own macro’s that show up in the UI.
  • Manual supports:
    • An area where S3D really shines, is how easy it allows you to place and generate your own support material (vertical columns).
    • Even in ‘manual’ mode, you can place them ‘automatically’, then add/remove them as you need.  A nice feature is you can toggle on/off ‘from built platform only’, so you can generate automatic supports for everything touching the bed, the later add in manual supports as needed elsewhere.
    • Support removal has always been great.
  • Technical support:
    • Yes, they actually get back with you if you email them with a problem.
  • Active forums:
    • Linked above:  A very active community.
  • Gcode previewer:
    • Does a great job displaying gcode through a variety of filters (print speed, feature type, etc).
  • Slicing speed:
    • Fastest slicer I’ve ever used, 3DBenchy sliced in 1 second.
  • Print results:
    • There’s no question that once you get your settings tuned right, S3D produces great results.
  • Object transformation:
    • In addition to translation\rotation\scale of parts on the build platter (either via a manip, of numeric entry), you can also specify dimensions, and it will scale to match.  Handy.
  • Multi OS support:
    • I’ve used it on powerful PC’s, and pretty old Mac’s, and it’s never had a problem.

Things it does not do well

This list is the main reason I started looking for other slicer options.  The “Major Issues” are things that I personally feel really, really need to be addressed.

  • Thin wall detection:
    • Major issue“: If you have a wall that’s .5mm thick, but you’re printing with a .6mm nozzle (or extrusion width), S3D won’t print it.  This drives me (and many others) nuts, considering old slicers like Makerware handled this just fine.  Simply having the ability to ‘opt in’ would be great.  Since I print with large (.6 -> 1.2mm) volcano nozzles, it means many files are simply unprintable.
  • Automatic supports:
    • Major issue“: S3D does a great job with manual supports (that you place by hand, which can be accurate but time consuming), but it’s automatic supports (most commonly used) are some of the worst I’ve seen, because… it doesn’t support any type of stalactite (or icicle) like feature.  While the supports it creates are fantastic, and remove great (better than any other slicer I’ve used), when it fails to create them at all where it should ‘automatically’, that’s a major failure.   I have an ongoing thread here with plenty of pics showing this problem.  This is a straight up bug that other slicers don’t have any problem with.  In fact, Simplify3D, KISSlicer, (Update:) CraftWare and ideaMaker have this problem:  Cura, Makerware, Slic3r, and ReplicatorG all handle this just fine .  Here’s an informative pic with the problem.  Just imagine how this can make your prints fail, I’ve had many wreck because of it:
    • overhangCompare
  • Cost, no trial version:
    • That about says it all.  I’ve been told they’ll refund you if you don’t like it after you buy it.  But seriously, there should be a trial for software like this for new people
  • Timely updates
    • They have maybe one update a year… and since it’s closed source software, you have no idea when its going to be released, or what will be in it.  And the last update was pretty lackluster as far as major bugfixes (anything on this list) or improvements.
  • Listening to their community:
    • While they do have tech support (that does respond), they seem to be completely absent from the forum.  Which I personally find quite questionable, since it gives the impression they don’t care about their user base.   There can be a certain topic that has 5 pages of people voting it up, but you never hear if the developers know, or care.
  • Toolpath simplification of high res mesh:
    • Major issue“: This is another major gripe of mine I’ve talked with tech support about, and they seem to have no want to address:  If you pass in a very high-res mesh from zbrush (for example), that may have a much higher poly density that what can actually be printed, the software will do no sort of simplification on the tool path.  The result is that it still tries to print all the detail, and the fallout is your print having a surface quality of oatmeal.  I have example prints that show this off pretty well, as they transition from low-poly to highres mesh.  Their suggested fix is that you manually decimate all your models.  But this means any time I scale a model, I have to re-decimate it for that particular scale (and how do I know how much to decimate it?).  That’s horrible.  Considering other slicers, like ancient Makerware or Slic3r do this for you.\
    • UpdateThis post of mine talks about the problem more, but here are some pics showing it off.  If you enlarge the pic on the right the quality difference is pretty clear.
    • resCompare_s3d_web foot_web
  • Lumping printer settings, print settings, and filament settings into the same preset/Process.
    • Not the end of the world, but since all these things are saved together, it means I need to have… a lot of processes for every speed, resolution, and filament type combo.  Splitting these settings up (like Slic3r) would only make data management easier.
  • Process Storage:
    • Even though S3D does a great job with it’s ‘processes’, it took a step backwards with it’s v3 release:  Up until then, when you’d save a process, it would save on your hard drive, allowing for multiple people to easily share process values.  But with v3, all process are saved “internally” in the software, making it very hard to do any sort of distributed process sharing between employees.  Yes, you can export them out to your HD, but this creates an extra, unnecessary step.  The issue is discussed here.
    • Update:  In addition, if you ever ‘reset S3D to factory settings’, it will wipe all your custom process and firmware setups without warning.  Which would be a non-issue if theses were stored on disk.  I’ve been bit by this in the past, its painful.

Slic3r Prusa Edition

Version Tested: 1.33.8-prusa3d-win64

Unique things it does well

These are things I’ve found it to do, that other slicers may not.  Or it does better.

  • Splitting printer settings, print settings, and filament settings into different presets.
    • slic3r_printsettings_tabs
    • I love this feature.  I can mix and match printer settings, print settings, and filament settings as needed.  Cuts way down on the number of ‘profiles’ needed vs say, S3D.  Plus they’re all saved on disk, easily shareable.
  • Toolpath simplification of highres mesh:
    • You can specify a ‘minimum detail resolution’ that will help it print higres mesh better.  Great feature.
  • Thin wall detection
    • If two walls are close together, they can be collapsed into one, so as to not cause an overextrusion problem in that area.  In addition, within reason (and discussed below in more detail), it will print a collapsed single wall much thinner than your nozzle width, which is desirable.
  • Variable layer height
    • Powerful new feature allowing you to smoothly adjust the print resolution over height.  See an informative post here.
  • Unique infill:
    • In addition to what you’d expect out of a slicer (hexagona, triangluar, grid, etc) Slic3d has additionl types like cubic and 3d honeycomb.
  • Unique top layer infill:
    • Whoe doesn’t love a hilbert curve for their top layer, eh?
  • Notes
    • Simple, but handy:  There’s a notes page for your prefs, to jot down extra info.
  • Max volumetric speed:
    • A handy way, mainly when dealing with bigger volcano nozzles, to limit how much material you extrude.  Based on resarch, the common thought is a volcano heater can melt about 30 mm3/sec, so you can actually enter that in, to make sure you don’t try to extrude more material than you can actually melt.  Which I’ve done before, it’s not good.
  • Verbose cooling description:
    • A little thing, but they have a human-readable paragraph describing how your print cooling fan is going to work, based on the values you set.
  • gcode postprocessing via scripting language of your choice:
    • This is pretty great:  You can pass in code from any scripting language (Python, Perl, JavaScript, etc) to postprocess your gcode.  I found this valuable when I had to modify the gcode output to support my RepRap Firmwares, by writing a custom pos-tprocesser in Python.
  • Slicing speed:
    • Not as fast as S3D, but still pretty fast.  3dBenchy sliced in 4 seconds.
    • Update:  Based on the v1.34 release, which the release notes state moved to a parallelized slicing system, dropped the benchy to a 2 second slice time.  Nice!
  • Print options:
    • In its ‘Advanced Mode’, there’s a knob to tune just about every aspect of your print.
  • Update: Octoprint connection:
    • It can connect to, and upload gcode directly to Octoprint.
  • Update:  Run it from the command line.
    • Fully scriptable from the commandline, no window needed!  That’s great for custom toolchains.

Things it does not do well

  • Printer communication
    • Vanilla Slic3r  doesn’t have this option at all (yet, I hear it’s in the works).  It just means you need some other sender software like Printrun or Repetier Host (or, ironically, Simplify3D).
    • The Prusa edition has the option to connect directly to your printer over a serial/usb connection, but I’ve been unable to get it to work.
    • The current dev (non-release) version of vanilla Slic3r does have this option however, and I’d tested it successfully.
  • Thin wall detection:
    • This is a pro above, but I also found it to be a con:  There were issues on my 3dBenchy tests (mainly the flag-pole hole on the stern) where it would collapse thin walls, but not replace them, causing gaps to form in the walls.  Disabling this option caused noticeable over-extrusion in some areas.
    • Update:  You can track this issue here.
  • Mac support:  It crashes a lot on my (old) mac.  No problem on my PC.
  • Update : Adjusting settings per layer height:
    • Simplify3D’s process are great for this, and while Slic3r does allow you to modify ‘print settings’ per model, I’ve not found a way to vary it by layer height.  Sometimes I want to vary the filament temp over a z-height to see the effects:  Easy in S3D, I’ve yet to find a way to do it in Slic3r at all.  Finally, Slic3r only lets you modify the ‘print settings’ per model, you can’t adjust printer or filament settings, which would help greatly.
  • Update : x3g support:
    • This only matters if you have a Makerbot printer (like myself), but while you can export a Makerbot-flavored gcode, you’ll still need some external tool (like gpx) to convert the gcode to x3G.  Technically since Slic3r supports postprocessing of gcode, it could call out to a x3g converter via a scripting language of your choice as well.
  • Update:  Saving/loading ‘scenes’:
    • It seems a bit awkward to save and load a ‘scene’.  To me, a ‘scene’ is  the current 3d mesh on the platter, plus all the current machine, print, and, printer configuration states.  You can do it, but (instead of the File menu) via “Platter -> Export Plate as AMF…” (Additive Manufacturing File Format).  you can later “Add” the xml file that process generates, which has the effect I’m after, it’s just a weird/clunky process.
    • Update:  I’ve read that per v1.34.1 it now supports a .prusa format that should handle this… but I can’t actually find that functionality in the software.

Comparing Simplify3D & Slic3r’s successes & failures

  • Print Quality
    • They both print great, in my opinion, see the below section with all the pretty pictures.  After setting up similar profiles in both slicers and printing 3dBenchies, the results look different, but great.
  • Overall level of print settings:
    • They both provide a similar level of knobs to twist for designing your print settings.  A wash.
  • Setting organization:
    • While Simplify 3D’s ‘processes’ are great, based on the fact that I use multiple ones so infrequently, I give Slic3r the win here, since it allows you to split you printer settings, print settings, and filament settings to separate presets, while Simply3D lumps them all into one.  Plus Slic3r’s are saved on disk, while S3D hides them inside the software.
  • Gcode previewer:
    • S3d’s better than slic3r for the fact it has more ways to preview the gcode.  However, both of them physically render the gcode about the same.
  • Gcode postprocessing:
    • Slic3r wins here, with it’s ability to use any scripting language.
  • Printer Communication:
    • S3D does a great job with its Machine Control panel.  Update:  Slic3r’s only seems to currently work in a dev branch.
  • Supports:
    • The supports that S3D actually creates (manual or automatic) are fantastic, but when it completely fails to ‘automatically’ support certain features that cause print failure, it’s just sad.  Slic3r’s supports are pretty standard, but don’t fail when they shouldn’t, so it gets a win for just being status-quo.  Both software could learn from the other.
  • Object Transformations:
    • S3D wins here, providing more tools that are easier to use.
  • Tech support & forums : S3D for the win, just a bigger community (or better communication platform) it seems.  It’s not that Slic3r doesn’t have that, S3D’s just seems more active.
  • Thin wall detection : Even though Slic3r has some problems, the fact that it recognizes them at all (compared to S3d) is a win.
  • Cost : You can’t beat free, Slic3r FTW.
  • Software Updates:  The Prusa Edition of Slic3r seems very actively developed… who knows when S3D will get another update, or what it will even have.
  • Highres mesh toolpath simplification:  Slic3r clearly wins here, realizing this is an important aspect of any highres model.
  • Setting storage:  Slic3r for the win here:  All if it’s printer, print, and filament settings are stored on desk in ini files, easily accessed by others, while S3D hides all the settings in the software itself.
  • Update: x3g support:  S3D wins, supporting it natively, with no extra steps needed for export.
  • Update : Slicing speed:  S3D wins, but with the latest Slic3r release I tested, the gap got a lot smaller.
  • Update : Scene saving/loading : S3D wins, it behaves like you’d expect any software too.  While you can do it in Slic3r, it’s just a bit clunkier.
  • Update : Overall experience:  S3D feels like a more polished piece of software, while Slic3r sill gives me that ‘shareware’ vibe from the 90’s.
  • Update: Setting customization per model / height:  S3D clearly wins here with it’s processes, assignable per model, and per z-height.  Slic3r has some nice options, but they’re not nearly as robust.
  • Update:  Command line api access:  Slic3r has it, S3D does not.

Things I didn’t test

  • Supports : Since I did this entire test with the 3dBenchy, which requires no supports, I didn’t feel it was important to test them.  But I’ve used plenty of supports generated by S3D in the past, and they were always easily better than the older slicers I used like Makerware or ReplicatorG.  I’ve actually not ever printed supports in Slic3r, just looked at the gcode output.
  • Other slicers :  I was considering mixing ideaMaker, Craftware and Cura into this test… but I’d probably never have finished it.

3dPrint Comparison

I should be noted that all prints have had zero cleanup work done to them.  This is to show all possible flaws.

Print Stats

I did most of my testing with the 3dBenchy model, trying to make sure both slicers had similar values.  This is what I printed with:

  • 280 micron z layer heights (‘medium res’ for a nozzle this size, set to full z-stepper steps).
  • .6mm E3d-v6 volcano nozzle, extruding at .72mm.
  • 2 shells, 3 top and bottom layers.
  • Triangualr infill @ 30%.
  • MakerGeeks Urban Camo PLA extruded at 230 deg, with a .97 extrusion multiplier.
  • Printed at 60mm/sec with active filament cooling, and slowing layers down for details like the smoke stacks.
  • The gcode for both slicers were sent over USB, via S3D.

Printer issues:

  • It should be noted my bot has a slight z-wobble I’ve been working on addressing.
  • Even though I think I have it tuned in for that filament, I feel like my tests were slightly over-extruding.

Print time and weight:

  • Both slicers generated prints weighting 15g.
  • Both prints took exactly 41 minutes.

Visual Gcode Comparison

On the left is Simplify3D, on the right is Slic3r

s3d_bency_gcode slic3r_bency_gcode

You can note the nice on-screen legend that S3D provides, not to mention it has many other display modes.  With Slic3r, on the right is what you get.  Visually, they’re about the same aside from the colors used.

Poll Results

I know I’m biased about what I think are good/bad print results.  I though it would be interesting to see what others thought, that really have no experience with 3d printing.  I did a poll at work where I brought in benchies sliced in both software(shown in the pics below), put it in the kitchen, and over the course of the day let people vote on which they thought was ‘better’.

I had a total of 57 people vote, and by 2:1, they chose the Slic3r version over S3D.  I didn’t tell them anything about how they were made other than “I’m comparing two different prints, what do you think is better?”.  I should also note that a number of people abstained saying “I don’t see any difference”.

Do I feel Slic3r’s visual results outweigh S3D’s by 2:1?  Not at all.  But I still find the results interesting.  Take them for what you will.

Visual Print quality comparison

Click on images to expand.

Side By Side

Beauty shot, side by side, S3D on the left, Slic3r on the right:

s3d_slic3r_compare_web

Pretty darn close!  Slic3r has slightly more stringing, but at a glance they look like twins.

Individual Simplify3D & Slic3r closeups:

s3d_closeup_web slic3r_closeup_web

Thin wall comparison

Since the bencny wasn’t the best test for this, I down laded a “thin wall test” from Thingiverse, and ran them through both slicers.  I didn’t print these, but I didn’t need to:  The gcode preview tells enough.

FYI, the walls on the top start at .05mm (on the left), and end at 1.0mm (on the right).  The walls on the bottom start at 1.0mm (on the left) and end at 3.0mm (on the right).

Again, I generated this gcode with a .6mm nozzle, but with an extrusion width of .72mm (20% over).

Simplify3D

Did not do well at all.  It didn’t start printing until the wall with was greater than my extrusion width, so it left out all walls under .75mm.  Kind of hard to print anything architectural related at scale with this limitation.

s3d_thinWall_lines_web

Slic3r

Did great:  It was able to detect and deal with walls almost 1/3 the width of my nozzle, the first one being .25 mm wide.  Note, this was with “Detect thin walls” turned on in the settings.  With it turned off, it had the exact same results as S3D.

slic3r_thinWall_lines_web

Slic3r ‘Detect thin walls’ issues

Interesting findings:  As mentioned above, Slic3r allows for thing wall detection and collapse, S3D does not.  The above benchy pics of Slic3r have the “Detect thing walls” feature turned on.  But I figured out, it was collapsing more than it should, in the case of the flagpole : There’s a small hole in it, which is also shown in the gcode itself:

slic3r_thinwall2_web slic3r_flagpole_hole

Turning this feature off fixed the flagpole, but caused a slight over-extrusion in other places, like where the bow meets the sidewalls, visualized in this comparison:

slic3r_thingwall_compare_web

Note on the right benchy, the line running parallel to the bow, below it.  But also go look at the top/first pic of the S3D/Slic3r compare above:  You can see the same artifact in the S3D print as well.

The thin wall collapse does help give better definition to features though, compare the portholes in these to Slic3r prints:

slic3r_thinwall_compare2_web

Note how the porthole on the left has better definition.  It looks better than S3D’s as well.

In Conclusion

They’re both great pieces of software, and they both a have many features in my ‘pro’ sections.  But based on the cost involved, how Slic3r has matured, and how few cons Slic3r has in comparisons to S3D’s cons, I’d have a hard time recommending S3D off the bat to someone new to this:  Give the free software a shot.

For myself, I’m definitively going to give Slic3r Prusa Edition a look:  Considering how it addresses all my ‘major con’ issues with S3D (correct automatic supports, properly handles highres mesh, deals with thin edges), I’m going to invest some serious time in it.  I think sometime in the next few months S3D should have another release if they follow years past, I definitively look forward to that will bring.

Finally, I’d like to give some suggestions to the S3D dev’s if they ever end up reading this:

  • Regularly comment on the forums.
  • Expose upcoming features & bug-fixes that are in development:  If I knew all the problems I discussed above would be fixed in an upcoming release, I’d be far less likely to spend the hours I have looking at other slicers.
  • Release more than once a year.
  • Basically, stop being such a black box.
  • Charge a reoccurring fee rather than a single upfront lump-sum:  I’d happily pay, say 5$ a month for an ongoing subscription where the above issues were met.  The OctoPrint Patreon subscription model (that I contribute to on a montly basis) is a great example of this.

Building the C-Bot 3d Printer : Part 36 : Adding an inductive z-probe to RepRap Firmware / RADDS

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


Introduction

This post describes how I installed an inductive Z-probe on my C-Bot 3d printer, using RADDS hardware with RepRap Fimrware.

My C-Bot printer has a 12″ square build plate, with 4-point screw leveling: Not the easiest thing to keep level.  I decided to tackle installing an inductive Z-probe to help with the leveling, since RepRap Firmware supports it.

Very important:  Before you get started, you’ll either need an aluminum build plate, or some copper tape you can stick on your existing surface at the points you want to probe.

Other info:

  • This sensor works in conjunction with your Z-endstop:  You still home using the endstop.  But after the home, the probe takes over fine-tuning the leveling process.

Get the probe:

I picked up a LJ12A3-4-Z/BY inductive probe off E-bay some time back.  It’s stats:

  • 4mm sensing distance (to iron)
  • NO, PNP
  • 6-36v input, 300ma
  • Brown = Positive, Blue = Negative, Black = signal

Make a bracket:

I modeled up a bracket for it in Autodesk Maya, that would hang off the rear of my hotend gantry.

After the probe was mounted to the bracket, I adjusted the probe so it was about 1mm from the build-plate, if the nozzle was touching the plate.  Basically, a different in 1mm from nozzle to probe-base.

probebracket_web

You can download the bracket from Thingiverse here.

Wire it up:

Voltage Divider:

Update:  I’ve been told you can drive these sensor directly off 5v:  I’ve not tested this,but if you’re going to attempt it, it’s worth a shot.  Save you from having to deal with the voltage divider below, and it means you can wire + & – directly into the RADDS board itself.

The probe needs 6-36v, the signal input on the RADDS board only accepts 5v, and my PSU is 12v:  Need to make a voltage divider!  Generally speaking, you need two resistors, with the smaller one half the value of the larger one. Like 10k & 5k.  Of course none of my resistors worked this well, and even when I did find some that may ‘sort of match’, they value they split wasn’t 5v.

After MUCH combinations, I came up with this:  Big 2k (really 1970 on my meter).  Small was two in a series: 1k (really 970) and 670 (really 660) for a total of 1730:  1730 isn’t remotely half of 1970, not even close.  However when setup on my beadboard, it was splitting out to 5.6v, which was the closest I got all day.

Later I read that anything over 3v would trigger things fine, so I was probably making this way harder on myself than I should have.

Mockup on the breadboard, using my Macbook Air as the ‘inductive aluminum surface’ 😉

breadboard_web

Final shrink-wrapped setup.  Resistors hidden beneath the wrap.

voltage_divider_web

RADDS Board:

The signal line needs to run into the “Servo PWM3 pin” (aka Due digital 39, AKA E0_AXIS endstop[3]), which is located in a cluster of solder-points on the corner of the board:  I soldered in a header, so that I could plug my signal line into it.

radds_web

Connect the wires:

Signal from probe (since having it’s voltage lowered above) -> ‘Servo PMW3’ 5v pin on RADDS board (image above).

Positive & Negative probe leads -> PSU 12v +- terminals.

Update the Firmware:

G32 is the command that triggers the probing on the board.  But the probing can be setup two different ways:

  • Use a bed.g macro filled with M30 commands (and others).
  • Use config.g filled with M557 commands, no bed.g.

I like the idea of having a separate macro file to configure my probing:  If bed.g exists, when you execute a G32, the bed.g is parsed.  If there is no bed.g, G32 instead looks for pre-configured M557’s, that live in config.g.

Initial setup

Below, I discuss how I setup config.g and bed.g

config.g

When you first add the code for the probing in config.g, it’s important that you set the ‘Z offset’ in G31 to 0: You’ll later calibrate it and edit it with the final setting.  Here’s my probing section:

M558 P4 X0 Y0 Z1 ; M558 must come before G31.
G31 X49 Y52 Z.4 P500

To break it down:

  • M558 – Set Z Probe Type
    • P4 : Set the sensor type.  When using an inductive sensor plugged in to the PMW3 pin, you need to set this to 4.
    • X0 Y0 Z1 : Use the sensor for the Z axis only.
  • G31 – Set Current Probe
    • X49 Y52 : This is the distance in mm that the sensor is away from the nozzle (used my calipers to roughly figure this out).  Since my sensor is behind and to the right of my nozzle, these are both positive values, since 0,0 is in the front left of the bed.  You can leave these zero, but I’ve read that having them set makes the calibration more accurate.  However, it makes setting up bed.g more complicated (more on that below).
    • Z.4 : This is the difference in height between the sensor and the nozzle.  Set this to zero the first time you set it up, it will be calibrated later.
    • P500 : The ‘trigger value’ : Really only important if using an IR probe, but I read for switches just set this to 500.

bed.g

This is where you define the points to probe/sample.  I’m doing a 5-point probe, but you can use as few as 3.

The only really confusing part is if you’ve entered any probe offsets in config.g’s G31 (above):  They need to be accounted for below, since you’re telling the system where to send the probe.  If the probe has a 50x, 50y offset from the nozzle, and you tell the probe to go to 0,0, it’ll try to run the nozzle outside the bounds of your printer, and much stepper chattering / printer shaking will ensue until you kill the power.

To calculate the below values, this was my process:

  • Home the printer, G28.
  • In my software (Simply3D), manually jog the toolhead around to the 5 points I want to sample  When I get the probe to a sample spot, I note the current X,Y value (which is for the nozzle), and I add the offset values  to it.
  • Make sure the probe is always over the bed!  If you position the probe off-bed, when it goes to sample that point, it’ll drive the bed straight up into your nozzle :(

My bed.g:

M561 
G28
; Probe the bed and do 5-factor auto calibration
; These are the same toolhead points, but with the sensor offsets added. Note, to use these points, you must set config.g's G31 X49 Y52
G30 P0 X49 Y52 Z-99999 ; Four... - Front Left
G30 P1 X49 Y305 Z-99999 ; ...probe points... - Back Left
G30 P2 X299 Y305 Z-99999 ; ...for bed... - Back Right
G30 P3 X299 Y52 Z-99999 ; ...levelling - Front Right
G30 P4 X149 Y152 Z-99999 S5 ; 5th probe point + store the levelling - Center
G1 X0 Y0 ; Send X & Y back to zero before print starts. This is commented out during the initial calibration.

To break it down:

  • M561 – Set Identity Transform : Clear out any previous probing transformation done.
  • G28 –  Home : Must always home before probing.
  • G30 – Single Z Probe :
    • P# : Each sample point must be assigned an index, from 0-4.
    • X# Y# : the location on the bed to send the probe.  These include the offset set in config.g’s G31.
    • Z -99999 : A value less than -9999 tells the system to probe here.
    • S5 : The final probe has the S value entered, telling it to store all 5 points.
  • G1 X0 Y0 : Send the toolhead back to X0 Y0 before print starts.  Just something I like to do, since I purge the nozzle there.  Note, during the initial calibration stage this is commented out, which makes setting the probe to nozzle z-height easier (more below).

Calibrate the nozzle-to-probe height

As discussed above, I set my proximity sensor to be about 1mm above my nozzle height.  These sensors have a 4mm detection distance for highly inductive materials like iron, but for aluminum, it’s much closer, around 1mm it seems.

Once the config.g and bed.g have been updated, fire up the printer, heat up the nozzle and bed (if you can) and execute a G32:  This will both home, and then start the probing sequence (based on what you’ve defined in bed.g).  Be excited as you watch your printer automatically drive around probing for points!  It’s important the nozzle/bed is heated up, because thermal expansion.

When the probing is done (and everything is still hot), use this process to determine the nozzle-to-probe height difference:

  • You can either enter the below commands, or use some other control software (Simplify3D) to do it.
  • G1 Z0 ;  Send the bed\nozzle to the current Z0 position.  This should move the plate close to the nozzle, but not touch it: Should be 1mm or less away.
  • G92 Z10 ; This tricks the machine so it thinks the toolhead is actually 10mm above the bed.
  • Slip a piece of paper between the nozzle and build plate.
  • G91 ; Set Relative moves.
  • G1 Z-.1 ; Start raising the bed\lowering the nozzle by -.1mm values.
  • Track how many moves you make.  Keep raising the bed\lowering the nozzle until the paper just barely moves:  You should still be able to slip the paper under the nozzle.
  • Write that number down.  Mine was -.4mm.
  • Let your machine cool, power it down.

Update config.g and bed.g

Take the positive value of that number from above, and update your config.g’s G31 Z# with it:  This is now your calibrated offset!

G31 X49 Y52 Z.4 P500

In your bed.g, enable the last line to send the toolhead back to G1 X0 Y0 if you want.

The next time you run a G32 and then send the nozzle to Z0, it should be just touching the build plate, allowing you to slip a piece of paper under it with the same friction as above.  If not, something is amiss.

However, it’s possible this position still isn’t optimal for printing the first layer:  I did a test print with a hollow cube (no roof, no floor, 2 shells) just slightly smaller than my build volume.  The nozzle was still slightly too high for good first layer adhesion.  Rather than constantly updating your firmware value to try and tweak this, you can use your slicer software, covered below.

Update your print Profiles:

My slicer software is Simply3D, but I’m guessing other slicers (Slic3r, Cura, etc) work similarly.

Start Script

The start script is the gcode that is execute before a print starts.  The only change I had to make was switch out the line that did the home operation (G28) with the new G3d command, which calls to bed.g, which homes and probes.  This is what mine looks like:

G92 Z0 E0 ; Set current z position to zero.
G1 Z2 ; Lower Z to be safe 2mm.
G32 ; bed.g - home and probe bed - If not probing, this would be G28 instead to just home.
G1 E50 F600 ; Purge nozzle 50mm 10mm sec When a print ends it's retracted by 30mm.
G92 E0 ; zero extruder
G1 X0 Y10 ; Move nozzle to left front corner of build platform.
G92 X0 Y0 ; Zero X & Y here to start the build.

Refine the Z-height

As mentioned above, my first layer was a bit too high, and wasn’t quite sticking right.  Simplify3D has a section in its ‘G-Code’ menu called ‘Global G-Code Offsets’: These allow you to provide an additional global offset to all values in the gcode.  As it turns out, setting XYZ to 0,0,-.025 mm made for a great first layer.  Iterating with this value is far easier/faster than updating the firmware.

Thoughts for dialing this in:

  • With the Z value set to zero (the default), do a test print of a box with a solid bottom.
  • If the first layer doesn’t stick well enough, cancel the print, lower by -.02 and try again.  If you see the extrusion curling up and off the bed as it extrudes, it’s actually to close, and add .02 and try again.
  • Keep iterating on this process until you get a nice stuck first layer.

Final Thoughts

Now that it’s working, I’m so sad I did’t do this sooner.  Full-volume first layers are just ‘spot on’ now.  It’s almost magical to watch it work.  Get an aluminum plate and do this mod!

Resource List:


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

Building the C-Bot 3d Printer : Part 35 : Updating the heated bed controller

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


A few weeks ago the relay controlling my heated bed had a meltdown, literally.  Magic smoke released.  It’d been running for a year, and I guess it was time.  Since I never wanted that to happen again, and I was tired of the “click click click” sounds it made I decided to go solid state.

After querying  the C-Bot Google Group for this issue, this board was suggested: (ebay link, $12.69):  It’s a HA210NO6 mosfet in a nice breakout board.  And it has the longest product name ever: “3D Printer Power Module for Higher Power Heated Bed upgrade RepRap RAMPS 1.4″.  I’m guessing that’s a direct translation from the Chinese…

mosfet_module

But I didn’t like the idea of all the exposed electronics, so I built a nice little enclosure for it in Autodesk Maya, which includes an active cooling fan in the back.  According to the specs (Ebay link) and the current I’m drawing the passive cooling via heatsink should be enough, but better safe than sorry.

This pic shows the three stage prototyping process I went though:

mosfet_enclosure

It includes a top-hole for a screwdriver to access the terminals inside, plus other top-holes giving your hex-wrench easy access to the bolts below.

Each box took about an hour to 3d print, using a .6mm E3d-v6 volcano nozzle on the C-Bot, 450 micron, 60mm/sec-ish.  The final two were in MakerGeeks HD Vivid Blue PLA (& dishwasher safe to boot!).

After an hour or so of splicing & soldering, the electronics were in place, and it was up and running without a hitch:

mosfet_in_action

You can download the enclosure from Thingiverse here.

Heats up in no time, and no more “click click click” like the relay used to.  A red LED shows it has power, and a nice soothing blue LED kicks on when the bed is heating.

When I find a bit more time I’ll look into configuring RepRap Firmware to use PID to control it, rather than the default bang/bang.


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

Howto: Pause RepRap Fimrware for filament reload at a specific layer number

Like my previous two posts on the subject:

…since I’ve switched my C-Bot 3d Printer to RepRap Firmware, I needed to figure out how to pause it at a specific layer height in gcode.  The wrinkle this time is I have no LCD hooked up to it, so I wasn’t sure how to unpause it.

As it turns out, it’s darn simple (as it should be):  Enter a M226 at the line you want it to pause:

... bunch of gcode....
; layer 2, Z = 0.38
M226

And bam:  It’ll stop right there, executing what’s in your pause.g macro.  From there, you can change filament as needed, then enter a M24 (executing the resume.g macro) via a connected serial console to start the print back up.

Optionally, like mentioned in the above posts, you can use your slicer software (if it supports it) to post-process the gcode to add in the M226 where you need.  Look to those posts as examples of how to do this.

Note:  I’ve had this fail via Octoprint:  3 hours into a 6 hour SD print the gcode triggered an M226 where it was supposed to.  I watched as the print paused, and then I heard all the fans kick off:  The whole board reset, thus canceling the print.  I tried simple tests with Octoprint using small calibration cubes and got similar (negative) results after only a few lines of printing.  Doing the same tests via Simplify3D’s serial console (still printing off the SD) worked however.  In fact, as a sanity check, during the pause I’d disconnect S3D entirely and unplug the USB, then reconnect USB and reconnect the serial console:  I was able to successfully issue a M24 to restart the print, so right now I’m going that route if I need to do a filament change.

Installing RepRap Firmware on RADDS

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

This post can also be prefixed “Building the C-Bot 3D printer part 34:” 


Overview

This post covers the steps I went through getting RepRap Firmware (RRF) installed on my C-Bot’s RADDS/Due combo.   My goal is to lay out all the steps & pitfalls I went though to get it working, in detail, since I could find no page online that already illustrated this.  Even though I’ve used several other firmwares in the past there were may concepts that were new to me (and probably not new to those more experienced in programming), that I’ll hopefully illuminate to others that were as much in the dark as I was.

It is mainly about RRF, and not the RADDS hardware itself:  That is covered in depth by my C-Bot’s ‘Upgrade to Repetier‘ post, no need to dupe all that here.

Note, written in hindsight:  Had the “Duet Wifi” (Duet v2) been available at the time I’d done this hardware upgrade, I would have gone that route.  If you’re considering this firmware as an option, I’d highly encourage you to go that route.  The hardware is more expensive, but you’re no longer dealing with a firmware port.

For some context of my experience (and I’m not saying my experience is ‘high’, more of a squishy-medium), previous firmware/hardware combo’s I’ve used/installed/tweaked include:

  • Sailfish/Mightyboard on my Makerbot Replicator 1
  • Marlin/Rumba on my C-Bot
  • Repetier/RADDS on my C-Bot

Why do this?

I had two main goals for installing RRF on my C-Bot:

  1. See if these weird vertical lines that were showing up on my prints when I switched to Repetier/RADDS would go away (and also to check out it’s overall comparative performance differences):   I figured this had something to do with Repetier & CoreXY printers.  As it turns out, it does not:  The same lines still show up in RRF :S  You can see pics of that issue in this Repetier Forum Post.
  2. Does firmware designed for 32 bit hardware have a leg up on firmware (Repetier) ported to 32 bit hardware?  The jury is still out, but my initial impressions (now that I’ve been using it for a few weeks) are positive.

Resource Link collection by webpage

Notes on RRF & it’s history

Big Thanks

Goes out to Dan Newman for his patience & tireless forum replies helping to guide me through this, plus other forum posters David Croker\dc42 (who helped write the dc42 fork of RRF) and GroupB.


My build environment

Hardware

  • All of this work was done on an ancient Macbook Air running OSX Yosemite 10.10.5.
  • RADDS 1.5
  • Arduino Due R3 (Note, that version of the Due has a ‘reset bug’, described below under ‘Issues’.  You want a Due R3-E to avoid this issue).

Software

  • Mentioned below, I installed the older Arduino 1.5.8 to get access to Bossac.
  • I do my text editing in Sublime Text 2.

Build from source

Docs: https://github.com/dcnewman/RepRapFirmware-RADDS/blob/master/INSTALL.md

Note, I did not do this (build from source).  But I initially tried to do this thinking it was necessary, since this was all very new to me.  Scons is required to build from source, and I had a nighmarish time getting it installed, and around that time in the fourm posts someone said “why not just install a prebuilt binary” using bossac?.  Which I didn’t know how to do either :)  The key piece of knowledge from that was:

SCONS : Builds the source into a .bin
BOSSAC : Upload compiled .bin to the Due

For what it’s worth, here’s my notes for ‘building from source’:

Get the git repository

You’ll need this anyway even if you’re not building from source, since it has the precompiled binaries, plus example macros required later.

On my Mac, I have my git root set to:

~/git
$ git clone https://github.com/dcnewman/RepRapFirmware-RADDS.git

So it installs here:

~/git/RepRapFirmware-RADDS

Scons:

I could only get scons installed by doing a MacPort.  And again, you only need to do this if you want to build from source.

$ port install scons

And then spending an hour getting various packages updated.  It was a nightmare.

Get bossac & configure Arduino IDE

Mac

To get bossac (which you need to later flash the compiled .bin to the Due) for the Mac, you need an older cut of Arduino, 1.5.8:  I can’t seem to find bossac anywhere on my Mac based on the latest release.

https://www.arduino.cc/en/Main/OldSoftwareReleases#1.5.x

This is where you can find bossac on a Mac (note how I changed the Arduino App name so as to not clash with the more current install I also have):

/Applications/Development/Arduino_158.app/Contents/Resources/Java/hardware/tools/bossac

PC

bossac.exe seems to come packaged with the latest Arduino IDE:

C:\Users\<USERNAME>\AppData\Local\Arduino15\packages\arduino\tools\bossac\1.6.1-arduino\bossac.exe

Also, dc42 provides a download for it here:

https://github.com/dc42/RepRapFirmware/tree/dev/Tools/Windows

Configure the IDE

Since I’d already done it back when I installed Repetier, I’m not sure how important this next step is. But if you run into problems:  You may need to ‘install’ the Due board in the Arduino IDE:  The bare bones instal doesn’t know anything about the Due.  Check out my post here under ‘Configuring the Arduino Due with the Arduino IDE’ on how to do this.

I didn’t get any further, since at this point I realized I didn’t need to build from source at all…


Flash precompiled binary

Docs: https://github.com/dcnewman/RepRapFirmware-RADDS/blob/master/doc/RADDS-v1.5.md

You need bossac to flash a precompiled bin to the Due.  If you haven’t already get bossac installed, see the previous section for that.

BOSSA is an acronym for Basic Open Source SAM-BA Application.  Not sure what the ‘C’ is for…

There is a Mac standalone app for this, but it’s known to not work with RADDS, so spare yourself the trouble.

Issues

I had a number of problems trying to flash the bin:

  • The Due has two programming ports, the ‘Native port’ (furthest from the barrel-jack) and the ‘Programming port’ (closest to the barrel jack).
  • You’re supposed to be able to flash the bin over the Programming port, only having to press the (easily accessable) reset button.  I could not get it to work.
  • The only other alternative is to use the Native port, but to do that, you have to first press the Due’s erase button, then reset.  Issue is, the erase button is completely hidden by the RADDS shield.  So I had to unwire everything from the board to get it out of the case, pry the RADDS shield off the Due, and do the erase\reset\native port combo. But, it worked.
  • It appears this “can’t use programming port” may stem from a firmware issue on the chip that drives the Due’s USB (discussed at the bottom under “issues”).  Basically, whenever you power on the Due, you must also press reset before you can connect to it.

You need to know what USB port the Due is on.  The easiest way I found this was:  Power it on.  Press reset to get around bug.  In either the Arduino IDE, or in Simplify3D (the slicer I use), see what’s listed to connect to.

You also need to know which binary to install.  There are multiple ones available in the /git/RepRapFirmware-RADDS/Release/ folder: I started with RepRapFirmware-1.09r-dc42-radds-b.bin, being told that was the most tested and stable at this point.  I quickly later upgraded to RepRapFirmware-1.13a-radds.bin, which has the advantage of allowing future firward upgrades to occur directly off the SD card.  See the notes here, and here.

Process

Based on the above bossac install dir, this is what I used to flash the bin to the Due:

  • Connect USB to native port on the Due.
  • Press erase on the Due.  I waited 5 seconds (not sure how long to wait but that worked).  Note if the RADDS shield is on the board and the erase button is hard to access, you can use a popsicle stick cut in half to reach it, with the help of a flashlight and extra pair of hands.
  • Press reset on the Due.  Again waited 5 seconds (not sure how long to wait but that worked).
  • Ran the below command:  The shell showed me the progress, with a successfully completion.
$ /Applications/Development/Arduino_158.app/Contents/Resources/Java/hardware/tools/bossac --port=tty.usbmodem2621 -e -w -v -U true -b /Users/<USERNAME>/git/RepRapFirmware-RADDS/Release/RepRapFirmware-1.13a-radds.bin

The short version (without paths) for readability is:

$ bossac --port=tty.usbmodem2621 -e -w -v -U true -b RepRapFirmware-1.13a-radds.bin

Note if you can get the programming port to work, you need to set ‘-U false’.

If performed successfully, you should see something like this:

Erase flash
Write 195708 bytes to flash
[==============================] 100% (765/765 pages)
Verify 195708 bytes of flash
[==============================] 100% (765/765 pages)
Verify successful
Set boot flash true

Test initial connection

Once you’re flashed the bin, how do you know the firmware is actually working before moving foward?  These steps will let you know it’ safe to continue.  You can do this even before the RADDS is plugged into the Due.

Reminder:  Connect the USB cable in in Native USB port (the one furthest from the barrel jack) of the Due, then to your computer (order doesn’t matter).

The Due ‘reset’ bug

Note, it appears that my Due has a bug with the chip that drives the USB firmware : Because of this, after I power it on, I must press the reset button (on the Due or RADDS) for the firmware to actually load.  I had this same issue using Repetier.  If you don’t press the reset button after it turns on, your computer may not be able to communicate over USB correctly, and you’ll spend hours searching the internet like me trying to figure out why.  This is discussed in more details in the “Issues” section at the bottom.

Three different methods I used to connect to the machine, immediately after flash.  I’ve listed the USB ports that I used below, yours will most likely be different.

Connect via Simplify3D

  • Press reset on the RADDS board.
  • Via S3d ‘Machine Control Panel’, connect at 115200 baud to USB port /dev/cu.usbmodem2621 (on my Mac) or COM5 (on my PC)
  • See the section below for actually configuring Simplify3D for printing with RRF.

Connect via Arduino

  • Press reset on the RADDS board.
  • Tools -> Board -> Arduino Due ( Native USB Port)
  • Port -> /dev/cu.usbmodem2621 (on my Mac) or COM5 (on my PC) : Arduino Due (Native USB Port)
  • Open the Serial Monitor.  Set baud to 115200.
  • Make sure that “Newline” is set in the field to the left of the baud rate:  Fresh installs can have ‘No line ending’ set, which doesn’t work well…
  • Note that if the text “( Native USB Port)” doesn’t show up in the lists, the board isn’t connected properly, or the Due wasn’t configured properly.

Connect via Octoprint

  • It should be noted that as of Feb 2017, it’s possible the latest version of Octoprint auto-detects RRF now.  However, if you have issue, these older notes may help:
  • Based on this forum post, need this plugin in Octoprint to make it compatible with RRF:
    • https://github.com/markwal/OctoPrint-RepRapPro
  • Just browse the Octoprint plugin manager to this file to install:
    • https://github.com/markwal/OctoPrint-RepRapPro/archive/master.zip
  • To connect, press reset on the RADDS board, choose the serial port ‘/dev/ttyACM0’ (for the RPi) and ‘Connect’.
  • If no serial port shows up after pressing reset on the RADDS, reload the Octoprint page.
  • See the section below for actually configuring Octoprint for printing with RRF.

To test the connection

Enter M115 into your serial console to report config status and know it’s actually working:  If the SD is in there with a /sys/config.g file (more info on that below), it should print something similar to what I have below, otherwise it’ll report ‘no config file’ (which still means things are working).

Send: M115
Recv: FIRMWARE_NAME: RepRapFirmware FIRMWARE_VERSION: 1.09r-dc42 ELECTRONICS: RADDS 1.5 DATE: 16/02/27

Then I plugged the RADDS back on top of the Due, and hooked up all the wires (more on hardware hookup below).


Macro Config

Update:  Since I’ve written this blog, a new “RRF Configuration Tool” is out in the wild:  Seems very similar to how Repetier does it (and that’s a good thing).  I’ve not yet used this configurator myself, but it may be a good starting point.

Macro files are the way you configure RRF.  They are .g text files that live in the /sys folder on the RADDS SD card, and allow RRF to reconfigure itself every time you turn it on:  No longer do you have to recompile the source to make an adjustment:  Just tweak the file on the card and reboot.

To get started, copy the content of /git/RepRapFirmware-RAADS/SD-Image/sys-CoreXY (presuming you’ure using a CoreXY machine like me) to your sd card root, and rename it to /sys

From there you can start editing the file:  Each time you plug it back into the RADDS board and reboot (and press reset after…) the config will be in play.

Good overview post on initial config:  http://blog.think3dprint3d.com/2015/02/reprapfirmware-config-files.html

Good overview of macros in general:  http://reprap.org/wiki/RepRap_Firmware_macros

The Wiki lists defaults for many Mcodes here.  I’ve experienced these defaults to in fact be incorrect in some instances:  If you plan on using a default, be sure to enter that Mcode into a serial monitor to see what it returns, and is valid.

Primary macros I use are as follows:

config.g

config.g is the main macro that is executed when the machine is powered on.  It’s akin to Configuration.h in Marlin & Repetier.  Below are the main steps I went through getting it configured, and describing what the M & G codes do… mainly for my own sanity as I learn this.

Set CoreXY Mode

Per http://reprap.org/wiki/Configuring_RepRapFirmware_for_a_CoreXY_printer, presuming your bot is CoreXY:

M667 S1 ;              set CoreXY mode

Setting max feed rates

Via M203

The wiki lists default values for M203 to be the values I list below.  However, before I set that, when I’d enter a M203, they’d actually come out to 6000 (mm/min) for XYZ:  Substantially slower than what I put in:  This was clipping my speeds going much past 100mm/sec.  Values below freed things up.

My Values:

M203 X25000 Y25000 Z25000 E8000 ;

Defining nozzle and bed thermistor

Via M305

I’m using a E3d-V6 thermistor for my Volcano hotend.

They state:

RepRapFirmware
Use the Beta value 4267K.​
It’s 100k Ohm

M305 P T B R L H X

  • P : Heater Number : Not to be confused with the ‘P’ (tool) value of M563. 0 = heated bed (RADDS bed), 1 = first extruder (RADDS H0). 2 = second extruder (RADDS H1), 3 = third extruder (RADDS H2).
  • T : Thermistor resistance at 25c
  • B : Beta Value
  • R : Series Resistor Value

When communicating with the RADDS, if you enter a M305 P0, it’ll print the current state.

My Values (just a generic 100k one for the bed), RADDS has a 4700 ohm inline resistor.

M305 P0 T100000 R4700       ; P0 = Heater 0 = The bed.  Not sure the 'beta' value for this.
M305 P1 T100000 R4700 B4267 ; P1 = Heater 1 = The extruder nozzle. Beta per the E3D docs.

Note, you’ll know these values are wrong if at room temp (25C / 77F) your control software (like Simplify 3D) doesn’t read 25(ish)c : I had originally set R1000, and it reported the resting temp to be 60c, very, very wrong.

Note I’m using the default PID settings for both nozzle and bed, and they seem to be working just fine.

Defining ‘Tools’

Via M563

This is where you setup your hotend(s).

M563 P D H

  • P : Specifies the ‘tool‘ number, 0 -> infinity.
    • D : The drive(s) used by the tool : 0, 2, 3 : D0 <-(zero) Is the first drive after the XYZ steppers, so presumably the extruder stepper.
    • H : The heater(s) used by the tool : 0, 1, 3 : 0 = Heated bed, 1 = first extruder heater.

My Values:

M563 P0 D0 H1 ; Tool (P) 0 : D0 = Extruder stepper 1. H1 = First extruder heater.

To select a tool in gcode, use T# to select it, T99 to deselect (needed?)

Defining axis direction and enable values

Via M569

M569 P S R X Y Z E

  • P : Specifics the ‘drive‘ number, not to be confused with the ‘P’ (tool) value of M563.  0=X, 1=Y, 2=Z, 3=E (right?).
  • S : Whether the drive should move forward. 1 = forward, 0 = backward.
  • R : Logic level.  0 is Default.  Set to 1 to reverse logic if you’re using RAPS128.

My Values:

M569 P0 S1 ;  X
M569 P1 S0 ;  Y - I needed to reverse this.
M569 P2 S1 ;  Z
M569 P3 S1 ;  E1

Set Endstop configuration

Via M574

M574 X Y Z S

  • X, Y, Z : The switch type for the axis : 0 = none, 1 = low (min) 2 = high (max).
  • S : Logic level : Defines whether the endstop input is ‘active high’ (S1, the default), or low (S0).

My Values:

M574 X1 Y1 Z1 S0

You can use M119 to report the status of your endstops.  Makes it convenient to test them while holding them on.   I had a super nasty bug where my X endstop wasn’t seated properly in the RADDS board, so it always reported off.

Defining steps per mm

via M92

For all steppers, X,Y,Z & E

My Values, copied from Repetier (with X&Y divided by 2, since Repetier doubles the XY steps for core-xy machines), since I’m using the same SD6128 drivers at 1/32 microstepping.

M92 X199.743 Y200.542 Z804.91
M92 E325

Fans

They were an amazing pain:  I have a hotend cooling fan, and a PLA cooling fan.  I also have a case cooling fan I never could get working via the below config, so I just hooked it up directly to my power-supply so it’s always on (Repetier was able to control it, so +1 for it).

This is what finally worked:

M106 P0 T60 H1 ; Hotend cooling fan: Enable to auto kick on at 60c (make it 'thermostatic'). 
M106 P1 H-1    ; Filament cooling fan: Must do H-1, or it'll turn on with P0 for some reason.
M106 P1 S0     ; Filament cooling fan: Must do, or it will go full blast on start :S

Comments:

  • If I didn’t declare P1 (filament cooler) non-thermostatic (H-1) it would turn on with P0 (hotend cooler).
  • If I didn’t set P1 (filament cooler) to a speed of 0, it would go full blast on machine start.
  • Still haven’t figured out how to hijack pin H2 to double as a case cooling fan (see complaint above).

Stuff to comment out / delete

From the default config.g:

  • All M540, M552, M553, and M554 (network) commands, not supported by RADDS.
  • M906 (motor current) commands : Not supported by RADDS.

Setting up extruder and bed PID

I wasn’t aware of this info at the time of my initial build, but there’s a great overview here on how to configure the PID on both your extruder, and heated bed here:

https://duet3d.com/wiki/Tuning_the_heater_temperature_control

Note that with RRF v1.15, there’s a PID autotune feature that can be used.  As of this authoring though, only 1.14 has been ported to RADDS :-(

I will also note that the default PID tuning for the hotend has been working fine, and my heated bed has been on a bang/bang relay (also the firmware default).

Related MCodes (RRF v1.09 and newer):

  • M301 : Set PID for hotend.
  • M304 : Set PID for bed

And if you have RRF 1.15 or newer:

homeall.g

This macro is called to during a ‘home all’  G28 operation

+ homex.g, homey.g, homez.g are just like it, but only on those individual axes.

Per http://reprap.org/wiki/Configuring_RepRapFirmware_for_a_CoreXY_printer

Make sure you set the G1 commands when moving the head some amount past your build volume, so they’ll be sure to hit the end-switches no matter what.  For example, my X platform width is 305mm.  So when homing:

G1 X-330 F3000 S1

I set it to go -330, just to make sure it hits.

bed.g

If you want to use an inductive probe to help level you bed, you do all that magic in bed.g (or optionally in config.g with M557 commands).  I hadn’t set that up at the time of this post, but I did later:  Find a robust post here on setting up an inductive Z-probe: http://www.akeric.com/blog/?p=4062

Macro M & G code usage

Macros can live in the /sys folder, or in the /macros directory with any extension.

While in a macro, you can call another macro. Macros are searched in /sys directory and it is recommended to always specify explicitly the path.

M98 calls to other macros.

When are Macros called to?

  • config.g : Machine starting up
  • Pausing & Resuming:
    • resume.g :  M24 (Start/Resume SD Print)
    • pause.g :
      • M25 – (Pause SD print)  – From control panel\lcd\serial connection, not saved gcode.
      • M226 – (Pause SD print) – From gcode directly.
    • cancel.g : If a M25 is executed pausing a print, then you execute a M0, this is called to.
    • stop.g : Docs say this is called while M0 is executed, (or?) when a paused print is cancelled.  NOTE:  Mine doesn’t seem to execute at all though via a M0, paused or not.  I have no idea how to trigger this.
  • Homing:
    • homeall.g : G28 (Move to origin: Home)
    • homex.g, homey.g, homez.g : Called to for individual axes on G28.
    • bed.g : G32 (Probe Z and calculate Z plane) – If using auto leveling.  See my post here.
  • Tool selection:
    • tpre0.g : Before tool1 is selected
    • tpost0.g : After tool1 is selected
    • tfree0.g : When tool1 is freed

Wiring the hardware

I cover how to hook up hardware to the RADDS in depth in ‘this post‘, scroll down to the ‘Connecting the hardware’ section.

Some notes from this doc, for the RADDS board:

  • The minimum endstop headers are used for the endstops: X min, Y min, and Z min.
  • Thermistor position T4 is used for the heated bed.  This is the thermistor header farthest from the board’s corner.
  • Thermistor position T0 is used for the first extruder, T1 for the second, etc.
  • Controlling fans:
    • Fan0 with ‘M106 S# P0′.  Where S is 0-255 .  P0 is default, and can be omitted.  This if the hotend cooler.
    • Fan1 with ‘M106 S# P1′ :  This is the PLA  cooler on the hotend.

Configuring to print with RRF

If printing over SD, RRF expects your .gcode files to live in a /gcodes folder on the SD.

Print off the SD via MCodes & a serial connection

You can print via a serial connection by directly issuing M-codes:

M20                ; list sd card contents to see what's there
M23 myPrint.gcode  ; select the gcode to print by name
M24                ; start the print

Configuring Simplify 3D

  • In the ‘Firmware Configuration‘s’ FFF tab:
    • To tell it to control the second fan (PLA cooling fan) not the first fan (hotend cooler).
      • Set Fan Power: M106 S$ P1
      • Set Fan Off : M106 S0 P1
    • RRF uses M116 to stabilize temps (I’m told M190 & M109 are deprecated).
      • Stabilize Extruder Temp: M116
      • Stabilize Bed Temperature : M116
      • Note, you loose all serial communication while these are in use:  Including temp readings, so you’re a bit blind during that time if you have this setup to do so in your ‘start script’.
  • In the ‘Firmware Configuration‘s’ Communication tab:
    • Make sure that “Allow Command Buffering” is checked, and set the “Serial Cache Size” to 127 bytes:  When I had the default (63) set, I was unable to print over USB, it would lock the machine about half way though my ‘start script’, right after a G28 (home) operation.
    • Note, to print consecutively over USB, I have to reset the printer, and reconnect after each print, or it will lock up like mentioned above.  This is different behavior than Marlin/Repetier.
  • In the ‘Firmware Configuration’sMacros tab:
    • S3D’s default “Extrude/Retract” buttons in the Machine Control Panel don’t seem to behave correctly:  They want to extrude based on “absolute values”, not “relative” ones. The side effect is during a paused print, if you extrude 10mm, you can’t extrude any more unless you retract 10mm first.  To get around this, if you execute a M83 first, it’ll put the extruder in relative moves, and you can extrude as much as you want.
    • I make a Macro called “Relative Extruder Moves” and put a M83 in there.  I press that before I do any type of control panel extrusion.
  • Note you have to “Export” your firmware settings to get it to save.  The ‘save’ button doesn’t actually seem to save anything.
  • In a given Process:
    • Temperature Tab:
      • For all extruder and bed temp controllers, uncheck “Wait for temperature controller to stabilize before beginning build”.
        • You ask “Why?  This is a great feature”.  Indeed it is, and I agree.
        • However, while the temp stabilizes via M116, you’ll get no serial communication back from the board, making you both blind to what’s happening, and unable to communicate with it in any way, to (for example) stop it if needed.
        • You’ll need to pre-heat the machine and get it to temp before starting your print if you go this route.

Configuring Octoprint

  • Update 2: As of Feb 2017, it’s possible that Octoprint will auto-detect RRF, and the below plugins aren’t needed. I’ve note tested this myself though.
  • Update 1:  As of Octoprint v1.2.15, RepRapFirmware is now supported!  You still need to install the RepRapPro plugin, and update the “Settings->Features” section to “Select SD Files by relative path” & “Always assume SD card is present”, but otherwise it works!

Old notes below, before RRF was fully supported by Octoprint:

  • As of this authoring, the main branch of OP isn’t designed to work well with the RADDS SD card:  Doesn’t recognize it properly, so you can’t print off of it.  You can print off the Octop’s SD via USB however.  I’m not a fan of printing over USB, so I didn’t like this option.
  • Thanks to work by Mark Walker while I dealing with all this, he updated a dev branch of OP to recognize the SD card, making it possible to print from it like any other firmware.  To get this dev branch, follow the directions below.  It worked for me without a hitch.  Thanks Mark!
  • In the Octoprint’s settings, under ‘features’:
    • Check ‘Enable SD Support’
    • Check ‘Always assume SD card is present’,
      • …or you won’t be able to see the SD card on the RADDS.
    • Once you’re on the dev branch (below), also check ‘Select SD files by relative path’ to be able to print off the SD correclty.
  • Also don’t forget to install this OP plugin:  https://github.com/markwal/OctoPrint-RepRapPro/archive/master.zip
  • Finally, once you’ve switched to the dev branch, do not update Octoprint: It will overwrite the update, and you’re back to square one.  Hopefully they’ll roll these updates into mainline at some point.

Switch Octopi to the dev branch (again, no longer needed post 1.2.15) that supports printing off the SD card on RRF \ RADDS:

This is a condensed / modified version of this Octoprint FAQ.  Like they explain, only use sudo on the FIRST COMMAND listed below, and nowhere else.

SSH into your pi.  Then:

sudo chown -R pi.pi ~/oprint ~/OctoPrint
cd ~/OctoPrint
git pull && git checkout dev/rrpFileOpened
~/oprint/bin/python setup.py clean
~/oprint/bin/python setup.py install
sudo service octoprint restart

When Octoprint restarts, you should see this version at the bottom of the web interface:

1.3.0.dev784+gf8c67fd (dev/rrpFileOpened branch)


Updating the firmware

If you’re running v1.13 or newer, you no longer have to do the ‘press the Due reset button’ dance.  Instead, you can follow the process Dan Newman outline here, or follow the steps below (copied & modified from that page):

  1. Place the below file in the SD card’s sys/ folder the binary file iapradds.bin
    1. https://github.com/dcnewman/DuetIAP/blob/master/Release/iapradds.bin
    2. If there already was an iap.bin in there, remove it.
  2. Power down the RADDS board and remove the SD card.
  3. From a desktop computer, copy the desired RADDS firmware file to the file “RepRapFirmware.bin” in the “sys/” folder on the SD card.  <- be sure to rename your .bin file to that name, specifically.
  4. Eject the SD card and place it back into the RADDS.
  5. Connect to the RADDS over USB (or from a Panel Due) and send the command M997 S0.
    1. Important:  I was unable to get this to work using Simplify3D’s serial monitor, since S3D constantly pings the board for the temp. This caused the update to fail.  I was able to successfully get this to work via the Ardiuno IDE’s Serial Monitor.
  6. Wait about a minute and then reconnect to the RADDS board. The new firmware should be installed. The RepRapFirmware.bin file is removed from the SD card automatically.
  7. Note: When you do this with a RADDS board connected to peripherals (e.g., stepper motors), it is recommended to do this with the bot’s power on. Particularly if you have RAPS128 drivers which may, owing to their inverted enable, turn on during the upgrade and when the processor is running under the iapradds.bin firmware. Peripherals may draw more power than a computer’s USB port will provide (typically a max of 500mA).

Note however, I haven’t got it to work :(  I’m on 1.13a, and I follow the above steps to upgrade to 1.14, this is what I get from Simplify3D’s serial monitor:

SENT: M997 S0
READ: Heat class exited.
READ: Move class exited.
READ: Move class exited.
READ: Updating main firmware
WARNING: Device unplugged while connected to port

After I wait a minute, reconnect, issue a M115 and get:

READ: FIRMWARE_NAME: RepRapFirmware for Duet FIRMWARE_VERSION: 1.13a ELECTRONICS: RADDS 1.5 DATE: 16/06/21

So something isn’t working right….

I tried again via the Arduino IDE, and get this after sending M997 S0:

ok
Heat class exited.
Move class exited.
Move class exited.
Updating main firmware

I thought maybe S3D sending M105’s were screwing things up, but it still didn’t update via Arduino either.

Research will continue…


Issues

Outstanding:

  • Can’t update Firmware via “M997 S0” : See notes directly above.

Resolved:

  • M190 (Heat bed and wait for target temp) & M109 (heat hotend and wait for target temp) cause machine to loose communication during heatup.
    • The commands tell the machine to ‘do nothing until target temp is reached’.  This includes any serial communication in RRF (compared to Marlin\Sailfish\Repetier that keep the serial communication lines open in my experience).  The side effect is the appearance that you’ve lost USB connection:  Communication will come back when target temp is reached, but in the meantime you’re blind.  I don’t like it.
    • I’m told that M190 & M109 are deprecated in RRF, and to use M116 instead:  While this command works, it still also hangs all communication in the process as well.
    • Solved:  Don’t use any of those Mcodes, and just heat everything up before hand manually. I don’t like this, but it works.
  • Endstops not being detected no matter what combo of values is entered into M574.
    • Solved : X-endstop wasn’t seating correctly in the RADDS.
  • PLA Cooler fan turns on automatically when using M563 to define the first tool.
    • Solved : Setting Fan0 to thermostatic (turn on when hotend reaches certain temp) it aut0-fixed this.  Weird.
  • PLA Cooler fan doesn’t respect PWM control:  It’s either 100% on, or off.
    • Solved:  Needed tricky config.g, see above.
  • Extruder doesn’t seem to be reading the correct temperature.
    • Solved:  Wrong inline-resistor value: had 1000, should be 4700 (what’s on the RADDS boar).
  • RADDS case cooling fan is hooked to H2 (hotend heater2) in Repetier successfully : How to configure that as a fan in RRF?  Still haven’t figured it out yet.
    • In the meantime I rewired them to mains so they kick on automatically when the machine is powered on.
  • The Due reset bug: Whenever I power on the Due\RADDS, I have to press reset to actually make it boot the firmware.  This happens in Repetier too.
  • RADDS LCD is not supported at this time, but the PanelDue is.  Plus, it’s a touchscreen.

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