I was recently commissioned to re-3d-print my Oahu design from a year and a half ago. Since then I’ve built a bigger printer (the C-Bot), the terrain2stl software has been improved, I’ve gotten better at painting maps, and I built an X-Carve CNC. I’m quite pleased with the end results:
And the raw print:
If this is something you’d like in your home (or any other map) let me know and we can work something out.
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.
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:”
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:
I had two main goals for installing RRF on my C-Bot:
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.
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’:
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 clone https://github.com/dcnewman/RepRapFirmware-RADDS.git
So it installs here:
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.
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.
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):
bossac.exe seems to come packaged with the latest Arduino IDE:
Also, dc42 provides a download for it here:
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…
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.
I had a number of problems trying to flash the bin:
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.
Based on the above bossac install dir, this is what I used to flash the bin to the Due:
$ /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
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).
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.
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).
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 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.
Per http://reprap.org/wiki/Configuring_RepRapFirmware_for_a_CoreXY_printer, presuming your bot is CoreXY:
M667 S1 ; set CoreXY mode
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.
M203 X25000 Y25000 Z25000 E8000 ;
I’m using a E3d-V6 thermistor for my Volcano hotend.
Use the Beta value 4267K.
It’s 100k Ohm
M305 P T B R L H X
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.
This is where you setup your hotend(s).
M563 P D H
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?)
M569 P S R X Y Z E
M569 P0 S1 ; X M569 P1 S0 ; Y - I needed to reverse this. M569 P2 S1 ; Z M569 P3 S1 ; E1
M574 X Y Z S
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.
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
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
From the default config.g:
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:
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):
And if you have RRF 1.15 or newer:
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.
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.
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
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.
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:
If printing over SD, RRF expects your .gcode files to live in a /gcodes folder on the SD.
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
Old notes below, before RRF was fully supported by Octoprint:
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
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)
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):
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…
Jump to C-Bot blog index to see all the posts.
Jump to C-Bot blog index to see all the posts.
I’ve been using removable glass build plates for years on both my Makerbot Replicator 1, and my custom C-Bot: I get double-thick glass cut at my local hardware store (Orchard Supply Hardware has had a great price on this), always thinking it was ‘totally flat’. But is it really? My C-Bot has a 12×12″ heated build platform. When I go to level it with the glass, I get each of the four corners dialed in perfectly. But the middle always sags slightly… even though it’s glass. Double-thick glass. But glass is actually somewhat plastic, and this sag has always bugged me.
Back in December I assembled my 1000mm X-Carve CNC, and it’s been so much fun cutting wood. I knew it could do aluminum as well, but needed a project. And that’s what this post is all about: Using my X-Carve to machine a new removable build plate out of .25″ mic6 aluminum for my 3d printer. I am so happy with the results.
Before I started this, I had no idea what ‘mic6’ aluminum was. It’s also referred to as ‘cast aluminum tooling plate’ or ‘ATP’, since mic6 appears to be a trademarked brand name. Simplistically, it’s a standard for (among other things) a very flat aluminum plate, to .001″. After reading a plethora of forms, and researching my local options, I settled on Midwest Steel And Aluminum’s “Cast Aluminum Tool & Jig Plate“, .25″ thick, 12×12”, which came to about $20, and the ground shipping another $20. I could have bought it locally for $45 + tax (ugh).
A note on the order: The plate was packaged in one layer of cardboard, that was it. It appeared to have been dropped several times in-transit, 3 of the 4 corners were blunted, and there was an small indentation in the middle of plate itself. If I was using this for something really precision I would have returned it. Just a note to tell them to ship it better if you go this route.
Once it showed up, time to make some cuts!
When I first got the plate I knew I had to notch a section out of each corner, since the heads of the bolts that hold the MakerFarm heated build platform stick up about 1/8″ish from it: I didn’t want the plate resting on the bolt-heads, so I need to make little pockets for each. Before I even considered my X-Carve CNC, I figured I could use my drill-press to pocket these. Long story short: It did not work well, and made a mess of the corners. Based on that frustration I went down the ‘how about I use that dormant CNC right next to the drill press…” road.
For all below cuts, I used the same 1/8″ 2-flue upcut carbide endmill.
Since these cuts were so simple, I used Inventable’s Easel: I designed a circle with a diameter of .4″ across, .175″ deep, and used that to pocket each of the four corners already mangled by my drill press. I used the default ‘aluminum’ Easel setting (5 ipm, .003″ doc, DeWalt on speed 1) with the first pocket (which took about 20 minutes), then started cranking it up: By the final pocket I had it running at 20 ipm at .01″ doc, with the DeWalt on speed 2, taking about 5 minutes.. It did great, and the bit was cool to the touch after the cuts. When all four pockets were complete, it fit right on the bed with no collision with the bolt-heads:
I have four bulldog clips that hold the plate on, one on the middle of each side. The issue is even though I’ve bent them down to move them out of the way, parts of them still stick up slightly, and on a large print the nozzle could collide with them. So going back to Easel, I designed a new rectangular pocket that would keep the bulldogs out of the way of the toolhead. These were 2.25″ x .3″, cut .075″ deep. I positioned them in the center of the left\right sides of the build plate, but had to offset them on the front\back based on my leadscrew config.
An in-process cut:
And all four final cuts:
Installed on the printer: No more clearance problems with the bulldogs!
I use a highly secret (50% wood-glue, 50% water) slurry on my build plate to get PLA to stick. But the mic6 is so smooth, I first scoured it with steel wool for several minutes to give the glue something to bite into.
Note for the future: First, use something like lacquer thinner\acetone\mineral spirits to clean the plate of any oils: Quite to my surprise, after many minutes of scrubbing, I could clearly see my handprint on it. The oils deposited from my hand actually protected it from the steel wool. So I went back and liberally scrubbed it with lacquer-thinner soaked rag, then went back to the steel-wool treatment again: No more handprint. Be sure to wipe it down with lacquer thinner after the steel wool too: The wool actually leaves quite a bit of itself deposited into the aluminum.
After the plate was scrubbed, cleaned, and glue-slurry applied, I did some test prints. And while the flatness was super awesome, I realized something very quickly: The slicer said the bed heated up waaaay faster than it actually did: For big prints in PLA, I’ll heat the bed up to 60c.
It dawned on me that the thermistor that does the temp reading is taped to the bottom of the MakerFarm heated build platform, while the thing being printed is sitting above it on .25″ of aluminum… that is taking much longer to heat up.
After brainstorming, I came up with the idea of cutting a groove into the bottom of the plate, that I could tape the thermistor into: It should then be reading the temp from the removable plate itself, providing a much more accurate temperature. This means I’ll also need to snip the leads running to the thermistor and install a barrel-jack into the mix to allow for the plate to be removed, since there’s now a sensor taped to it.
Going back to Easel, I designed a .5″ wide groove cut .0312″ deep that I could recess the tape into, then another smaller groove .2″ across and .1″ deep to run the wires to the thermistor.
Here it is mid-cut:
To help with heat transfer (that is only a theory of mine) and to prevent any sort of plate-slip (which is legit), I shoot the bottom of the plate with rubberized undercoating. I then snipped my thermistor line, soldered barrel-jacks onto either side of it, then taped it into the groove on the bottom of the plate:
Putting it back onto the HPB, I reconnected the barrel-jacks:
It works, great.
When the HPB heats up, and it finally gets to temp…. it really feels like the top\bottom are the same temp. And I can level each of the four corners, and the middle is the exact same distance as the rest of them from the toolhead.
Super rewarding project with one machine improving another.
Jump to C-Bot blog index to see all the posts.