Posts Tagged ‘ firmware ’

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.

2016
06/15
CATEGORY
Electronics
TAGS










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

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” (or Ethernet) 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 #1:  I did not do this (build from source).  Nor do you actually need to, but since I did so much work not knowing this, I listed it below.

Note #2 : You mostly like will still want to clone the git repository, shown below.

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 want 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

This is my original install location:

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

So it installs here:

~/git/RepRapFirmware-RADDS

But since authoring this, DC42 has taken over, so instead you’ll want:

$ git clone https://github.com/dc42/RepRapFirmware.git

Which includes the RADDS builds.

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 / manual firmware update

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

Update:  If you’re using 1.18.1 or newer (the docs say 1.13 or newer, but it didn’t work for me until 1.18.1), you can use the auto-update function instead of this method.  See that section at the bottom.

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’s‘ Macros 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

(According to the RRF docs) 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. Power down the RADDS board and remove the SD card.
  2. Download the latest RADDS compiled .bin file from:
    1. https://github.com/dc42/RepRapFirmware/tree/dev/Release/RADDS/Edge 
    2. Rename this file to “RepRapFirmware-RADDS.bin”, and copy it to the “/sys” folder on the DS card.
      1. As an aside, if you were doing this for a normal Duet, the name would be “RepRapFirmware.bin”
  3. Also, download and place the below file in the SD card’s sys/ folder.
    1. https://github.com/dc42/RepRapFirmware/blob/dev/Release/RADDS/Edge/iapradds.bin
    2. If there already was an iap.bin in there, remove it.
  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. You’ll probably have to reconnect to the board via the Arduino serial monitor, but if you execute a M115, the new version info should be displayed.
  8. 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).

Update:

Up until versions 1.18.1, I was unable to get this process to work.  It “just wouldn’t”, and I’ve have to manually update the firmware by pressing the on-board reset button via a broken-in-half Popsicle stick.  But when upgrading from 1.18.1 to 1.19.2, it magically started working.  So much easier now!

Issues

Outstanding:

  • None

Resolved:

  • Can’t update Firmware via “M997 S0” : See notes directly above.
    • Solved:  Up until 1.18.1, this didn’t work.  But, when I upgraded from 1.18.1 to 1.19.2, it started working.  Finally!
  • 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.

2016
05/30
CATEGORY
Electronics
projects
TAGS






6 comments

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

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

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

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

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

Or in your Configuration.h set:

#define FILAMENTCHANGE_REHOME 0

Now, I can reload filament successfully via the LCD.

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

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

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

; layer 4, Z = 0.78

And insert it in where needed:

M600
; layer 4, Z = 0.78

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

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

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

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

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

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

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

2016
05/10
CATEGORY
Electronics
TAGS





1 comment

Tuning jerk values in Repetier

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

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

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

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

You want high jerk values, because

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

You want low jerk values, because

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

Other Hardware\Slicer Stats:

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

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

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

Print speed/time comparisons, sorted by jerk:

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

compare_all(click all images for bigger pics)

What does this tell us about speed/jerk tradeoffs?

Numeric comparison of print time:

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

Comparing JERK 10 to itself:

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

Comparing JERK 40 to itself

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

Comparing JERK 10 to JERK 40:

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

Things observed from the numbers:

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

Visual comparison of quality:

Comparing Jerk 10 to itself:

compare_jerk10

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

Comparing Jerk 40 to itself:

compare_jerk40

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

Compare 60mm/sec:

compare_60mmSec

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

Compare 90mm/sec:

compare_90mmSec

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

Compare 120mm/sec:

compare_120mmSec

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

Final Thoughts, Opinions:

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





Comments Off on Tuning jerk values in Repetier

Building the C-Bot 3d Printer : Part 31 : Upgrade to RADDS, Repetier

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

This post could also be called:

How the C-Bot experienced catastrophic failure, and survived

The short version of what led up to this point is:

  • Decided to print a 3d quad-copter frame on the C-Bot, but needed to swap to my .6mm nozzle from the 1.2mm one that I had installed.
  • The last time I used the .6mm nozzle and removed it, I burned out the filament with my butane torch, so it’d be clean for next usage.  However, I was a dummy and gripped the threads with my pliers.  Even gripping lightly, it marred the threads, compounded by the extreme heat of the burnout.
  • When I threaded in the .6mm nozzle, I encountered resistance I didn’t expect.  So I just ‘twisted a little harder’, and popped the head off the nozzle.  It’s now stuck in my hotblock.
    • snapped_nozzle  Sad, so sad…
  • Ordered a new hotblock, and a .4mm nozzle at the same time:  Why not, I’d never tried a .4mm nozzle on the C-bot before.
  • Got the new hotblock and .4mm nozzle installed.  But when printing at 90mm\sec with Marlin, I got a lot of stuttering, even when printing directly over SD.
  • It was suggested I drop the microstepping of my DRV8825’s to 1/16 from 1/32 : This will halve the number of instructions the machine needs to process.
  • Pulled the drivers out of the Rumba, flipped the dip switches, plugged them back in, and turned on the machine:  Terrible squealing sound, bad smells, etc.  Turned it off immediately, but the damage was done:  Rumba dead.  Even though I double-checked, I had plugged one of the drivers in one-pin off.  Magic smoke = released.
  • Now I need an all new mainbord.  After much research, I decided on a Arduino Due/RADDS combo, running Repetier:  I liked the idea of the 32-bit system, and a new firmware that was wasn’t Marlin.  Plus if I didn’t like Repetier I can always swap to RepRap Firmware.

So that’s what this post is about:  Swapping out my old Rumba for a new Due/RADDS combo, and installing Repetier on it.  I’ve made it so verbose mainly for myself, as reference in the future.  It is definitely a living document that will be updated over time.

The final product looks pretty slick:

radds_repetier

(I do have a fully 3d-printed case for them both now, I just like that pic…)

Installation Notes

My notes below are in the order I performed them to do the swap from my existing hardware.  Prettymuch the same order you’d do it in if you were doing this new, from scratch.

After I did my upgrade, I also found this great setup guide: http://reprap.me/media/manuals/RADDS_UserGuide_V2_reprapme.pdf

My development environment:

  • OSX 10.10.5
  • Arduino IDE 1.6.4
  • Repetier 0.92.5
  • RADDS 1.5

Hardware Sources:

  • Arduino Due : I got mine via an Amazon Prime special for $15.
  • RADDS : $61, via MakerFarm.
  • LCD : $37, via MakerFarm.
  • SD6128 Drivers: 4x, $11.50, via Panucatt.
    • Note, there are other stepper driver options out there.  One of which is the RAPS128.  From the forums, it sounds like there are reason to not get this driver because of it’s ‘inverted’ state (compared to the SD6128).  Discussed below in the watchdog section below.

Configuring Arduino Due with the Arduino IDE:

  • The Due wasn’t recognized by Arduino software:
  • Arduino -> Tools -> Board -> Board Manager -> Search for SAM -> Choose the one that supports Arduino Due
    • https://www.arduino.cc/en/Guide/Cores
  • Got this error on simple “blink” sketch:
    • arm-none-eabi-gcc: error: core/syscalls_sam3.c.o: No such file or directory
  • Forums to the rescue > I downgraded the core to 1.6.4, and could then upload.
  • Be sure to use the ‘programming USB port’ (the closest one to the barrel jack) to upload sketches to it, I didn’t have success with the other one (‘native USB’).

Pre-Configuring the RADDS Board:

  • Set stepper driver microstepping first, on the back of the board.
  • I’m using SD6128 drivers, set to 1/32 microstepping, so it’s {on,off,on}.  By default they were {on,on,on} (1/128 microstepping), so I just flipped the middle switch.  Based my my query to the forums, the though was presented that humans can’t see much past 1/16, and the higher the microstepping the less holding torque the steppers had.  Since I’d previously had my DRV8825’s set to 1/32 on the Rumba, I kept this the same on the SD6128’s.  This had the benefit below of being able to use the exact same steps/mm for the steppers in Repetier as Marlin.
  • Insert stepper drivers, making sure DIR pin on driver lines up with DIR pin on board.
  • Squish the RADDS Shield into the Due.  Carefully.

LCD-Display:

  • Connect via the diagram in the link.
  • Can’t use a RepRapDiscount display I have on my Rumba board, gotta use the special RADDS display.

 Installing Firmware: Repetier

  • Instructions via the RADDS page I followed here.
  • For future note:  A list of all valid G & M codes for Repetier can be found on it’s GitHub page for Repetier.ino : I’ve found other spots on the web that list them (including the RepRapWiki and ironically the Repetier Firmware GitHub Wiki) which all seem out of date when it comes to Repetier’s codebase.
  • First step is to go to the Repetier firmware download page, which links to the web-based ‘Repetier Firmware Configuration Tool’ discussed below.  After you’re doing configuring, you download.
  • Note, Repetier makes it super easy to do a later update:  After the initial full download and install of Repetier via the Arduino IDE (info below), to do an update all you have to do is upload your existing configuration.h to the web-based ‘Configuration Tool’, update the settings, then re-download just the configuration.h, which you can re-update via the Arduino IDE.  Pretty slick.
  • Also note that after you do the first install, some values are only adjustable via the EEPROM (see notes below) unless you disable that feature (See ‘General Tab’ below).
  • Repetier Firmware Configuration Tool v092 initial settings:
    • General Tab:
      • Set correct Processor : Arduino Due based boards)
      • Set correct Motherboard : Arduino Due with RADDS
      • Set the printer type.  Mine is set to “z axis + H-gantry/core-XY (x_motor = x+y, y_motor = x-y)” : I have my “X-stepper” mounted to the top-left, and the “Y-stepper” mounted to the top-right.
      • Set the dimensions correctly.
      • Set the EEPROM usage.
        • By default it’s set to “Set 1”, which means after the initial install of Repetier, certain values are only editable via the EEPROM (via the RADDS LCD).  Took me a while to figure this out, couldn’t figure out why changing values (like steppers steps/mm) wouldn’t update when I’d re-upload the firmware:  This is the reason.
        • Note:  Every time you use the configuration tool, if you change this value (from 1 to 2, then back to 1, etc), it will refresh the EEPROM.   So if you want to blast your EEPROM values based on some future config, just tick this value from 1 to 2, or 2 to 1 depending on its current state.  Actually pretty slick way to do things once you figure it out…
    • Mechanics Tab:
      • If you’er using RAPS128 drivers (I am not, I’m using SD6128), be sure to check ‘Invert Enable Signal’.  See notes on the watchdog section below as to why this could be a bad thing.
      • Don’t forget to double your steps per mm (if you’re setting them here now) for the X & Y, since Repetier requires them to be doubled for core-xy machines for some reason (told they’re working on a future fix for that).  I plugged in the past ones from Marlin as a starting point, since I was using 1/32 microstepping on that as well (399.486, 401.083, 804.91) – those are the doubled x&y vals.
      • If you’re driving both Z-steppers from two different stepper drivers, you can enable that in the ‘z stepper motor’ section. To start, I’m going to try to drive both steppers off the same driver, since the RADDS board specifically has pinouts for that.
      • Set “Delay Stepper High Signal” to 1, since this is a Due board.  Also read this is needed for core-xy machines.  Note I’ve used both 0 & 1 values, and have noticed no difference in print quality.
      • Set ‘Move Cache Size’ from 16 (default) to 32 (since we have a lot more memory on the Due than a normal Arduino).
      • Set your endstop homing order.  Mine is X,Y,Z:  I want to get the gantry out of the way of the build platform just in case…
      • Set your endstop switch type:  Since I’m re-using the “makerbot style” (or RAMPS 1.4 style) mechanical endstops, I set mine to “normally-open”.  See ‘Endstops’ below.
    • Tools Tab:
      • Set the Temperature Sensor for your extruder.
        • My E3D-v6 Volcano stated it came with a “100K Semitec 104GT2 NTC thermistor” : This wasn’t listed in Repetier.
        • The E3D Troubleshooting docs said: “Repetier Firmware use thermistor definition number 8”:
          • #define EXT0_TEMPSENSOR_TYPE 8
        • There is no option for that number in the firwmare setup wizard (it’s all by name), but I later set it to that value in the configuration.h file directly via the Arduino IDE.
        • Note, getting this right is super important!  I was having all sorts of print problems (since I’d just chosen a thermistor by name that ‘sort of matched’) until I set it to ‘EXT0_TEMPSENSOR_TYPE 8’ in the firmware, and it’s amazing how much better the print quality got.  Of course you may be using a different type of thermistor, but the important thing is get the right value plugged in here.
        • ALSO NOTE, ALSO SUPER IMPORTANT: If you later go back to use the online ‘Repetier-Firmware Configuration Tool’ to adjust other settings & re-download, this temp sensor setting will get reset (mine gets reset to 14 every time) : You must manually go back into the configuration.h and set it back to 8 (or whatever value is appropriate for you).  I’ve posted this bug to their forum, so we’ll see what the community has to say about it…
      • Be sure to set the “Extruder Cooler Pin”, or the fan won’t kick on as the hotend heats up.  I set mine to “Fan pin”.
      • Be sure to set “Enabled Heated Bed Support” if you have one, and the type of thermistor used.
      • Set your extruder’s “Resolution”, or “steps per mm” : Mine is 300 from Marlin (Repetier was 370 by default).  I ended up having to set it to 325 based on testing (but via the LCD Configuration menu, and store in the EEPROM, not via the Arduino sketch.)
    • Features Tab:
      • Be sure to set your “Print cooling fan pin” if you’re using one (to cool the filament as it is deposited).  I set mine to “Fan 2 pin”.
      • Set “Fan pin for board cooling” if you’er using fans to cool your mainboard.  I set mine to “Heater 3 normally used for extruder 2”.
      • Set ‘Enable Watchdog’ if you’re doing that (see the next section below).
      • At the bottom, set “Homing after Filament Change” to “No Homing”.
        • Or in Configuration.h set:
        • #define FILAMENTCHANGE_REHOME 0
        • If you don’t do this, you may get a bug that happened to me:  If you pause the print to reload the filament via the LCD, when the print restarts it’ll go to the wrong location :(  This took me a lot of troubleshooting to figure out.
    • User Interface Tab:
      • Change “Display Controller” to “RADDS LCD Display 4×20”
      • I unchecked all the languages other than English
      • I set my Machine Name
      • Setup ABS & PLA preheat presets.
    • Manual Additions:
      • None
    • Download:
      • Note any errors or warnings that appear at the top of that page (in the different-colored callout box.  There may be none):  I didn’t realize these are actually calculated based on the latest settings, and will change\update every time you go back to the ‘Downloads’ section.
      • “Download complete Firmware incl. these settings” the first time.
      • Every time after the first, you only need to “Download configuration.h” to update the firmware.

Firmware installation on HD, integrating with Arduino, upload to Due:

  • I unzipped the download to my (mac) ~/Documents/Arduino folder, which is the home for all my sketches.
  • When I opened Arduino, a “Repetier-Firmware” section appeared in my sketches.
  • A txt file is provided at the root of the zip with more specific info to do.  One of those things is getting the ‘Hardware Watchdog‘ setup for Due (which is off by default).
    • The instructions are all for windows though:  I’m on Mac, so none of the copy paths matched up.  Finally, I found the directory where I needed to copy everything:
    • /Users/<USERNAME>/Library/Arduino15/packages/arduino/hardware/sam/1.6.4/variants   -> Copy the /arduino_due_repetier folder from the zip here
    • /Users/<USERNAME>/Library/Arduino15/packages/arduino/hardware/sam/1.6.4  -> Copy the boards.txt here.  I first renamed the old one to _boards.txt just to not loose anything.
  • Upon restarting Arduino, under ‘Tools -> Board’, there is now a ‘Arduino Due for Repetier’ option.  Which is what you want to select to enable the watchdog.
  • Time to upload to the Arduino.  Simple Repetier guide here.
    • Don’t forget to fix your ‘EXT0_TEMPSENSOR_TYPE’ to the correct value before upload, if it was changed by the web ui!
  • The compile and upload went off without a hitch!  LCD came to life immediately after the reboot.

Testing the Watchdog:

To make sure you have the watchdog working, issue a M281 to Repetier Firmware via your host software (I use Simplify3D).  If its working, you should see something like this:

SENT: M281
RECEIVED: ok 0
RECEIVED: Info:Triggering watchdog. If activated, the printer will reset.
RECEIVED: TargetExtr0:0
RECEIVED: T:21.34 /0 B:21.25 /0 B@:0 @:0
SENT: M105
SENT: M105
RECEIVED: start
RECEIVED: Info:Watchdog Reset

And the printer should reset in the process.  Thanks to Ryan Carlyle for the above tip.

What is the ‘Hardware Watchdog’ doing?

Fine question which I didn’t know the answer to.  Gotta love the internet:

Here’s a quote from Dan Newman:

“If the processor is wedged up, then for many/most definitions of wedged up, it won’t be responding to any commands as the software is, well, wedged up.  That’s the point behind the hardware watchdog: you enable it with a timeout (e.g., 4 or 8 seconds is common on an AVR).  Then your software MUST reset it every N seconds before the timeout expires.  If your software doesn’t reset it in time, then the watch dog fires and forces a reset of the processor. Wedged software won’t reset it and so it fires resetting the processor.”

“Watch dog is just a hardware timer.  It starts, for example, a 4 second countdown.  If you don’t reset the timer before the 4 seconds elapse, then the hardware in the processor causes it to reset (i.e., reboot).   So, healthy firmware makes damn sure to reset it more frequently than every 4 seconds.  If the firmware locks up or is otherwise having unexpected problems, it cannot reset it and so the countdown completes and the processor is rebooted.   To be useful, the electronics and firmware should be well designed: the electronics should be default assert a powered off state for heaters.  And the firmware on booting should also turn all heaters off.   Likewise for motors.”

And Ryan Carlyle:

“It’s a hardware deadman switch built into the processor. The watchdog has a countdown timer (adjustable but usually a few seconds long) that must be reset by the firmware over and over forever. If the timer ever reaches zero, the watchdog will hard-reset the processor. Specifically for 3d printers, we want to ONLY reset the watchdog timer when the heater powers are managed. That way, if the firmware falls into an infinite loop during a bad SD read or whatever and stops paying attention to the heaters, the watchdog will reset everything. That will then turn the heaters off, unless something else is wrong too.”

Comments on using RAPS128 stepper drivers, and the watchdog, in regards to the “…And the firmware on booting should also turn all heaters off…” comment above:

Ryan Carlyle: “This is something that bugs me about RAPS128 drivers (enable is inverted) and FD-RAMPSv1 (FET is inverted) — the standard reset sequence actually turns stuff on while the firmware loads. Not good behavior. “

Dan Newman: “And when installing/updating firmware they typically enable as well.  Yes,
it is annoying. “

People, just use SD6128 drivers…

Connecting the Hardware:

Descriptions below based on this image of the RADDS board.

RADDS_Wiring

Connecting Steppers:
  • I hooked both Z-steppers to the same driver on the board:  They conveniently provide two headers there specifically for that.  So far, I’ve had no issue raising \ lowering the bed.
  • I hooked my “left” stepper to the “X” driver, and the “right” stepper to the “Y” driver.  And.. the extruder stepper to the corresponding driver.
Tuning Stepper Drivers
  • I’m using 4 SD6128 drivers:  One driver for the dual-z steppers, plus one each for X, Y, & Extruder steppers.
  • Setting the reference voltage:
    • They have a max peak output of 2.2A.
    • Based on this doc: http://reprap.org/wiki/RAPS128, it recommends a voltage range between .8-1.6v
    • Based on the user guide, the: Current Limit = VREF*2
    • To set this, touch one probe from your voltmeter on the pot on the driver, an the other on the RADDS ground.  See the picture in section 3.4 of this pdf guide.
    • By default they all appeared to be set to around .55v : I dialed them up (clockwise) to just under 1v : Anything higher than that and the steppers would make a terrible sound and I had to reboot the machine to get them to move again.
    • Fast-forward:  .9->1v is way too much for the steppers:  After only 4 minutes of printing they were burning hot to the touch, and were starting to melt their brackets.  I dialed their voltage back to .55, and got much cooler-to-the-touch results.  As an aside, I’d set my DRV8825’s to .58 volts.  After a bit more printing my extruder stepper was doing some skipping, so I pushed it up to .75v, and it’s been doing fine since.
    • Lesson learned:  Set SD6128’s ref voltage to .75v, this sets the current (from the current limit equation, above) to 1.5A (1.5 = .75*2). Anything higher than that and things start getting pretty hot.
  • Update:  I swapped out to some RAPS128 much later (as a test only):  You should set their ref voltage to 1.1v.  Their ‘Current Limit = VREF*0.9125
Endstops:
  • I’m still using the “Makerbot style” (or RAMPS style) endstops that I had hooked up to my Rumba.
    • endstop diagram
  • Their pin order (starting with the side of the switch) is (sig, -, -, +)
  • To hook this up to the RADDS board it’s important to not hook up the +v, just the sig and -:  RADDS is a 3.3v system and the LED works off 5v logic.
  • My wire colors were Green (sig) Black (-) Red (+).  So I just cut the Red (+) line and plugged it in to the MIN XYZ headers on the board (since my machine homes negative X, negative Y, negative Z).
  • These switches are NO (Normally-Open) by default:  Tripping the switch creates (closes) the connection.

Other Components:

  • I plugged my main power, and hotbed input voltage just like the image shows.
  • Since I use a relay to actually control the bed power, I wired it into the voltage output for the bed (blue/yellow lines in the image), just like before on the Rumba.  In Repetier : ‘Heater 1 normally used for heated bed’.
  • Hotend heater cartridge connected to “Heater Hotend 1”.  In Repeter : ‘Heater 0 normally used for extruder 0’.
  • Hotend cooler fan connected to “Fan 1”.  In Repeter: ‘Fan pin’.
  • Filament cooler fan connected to “Fan 2”.  In Repetier: ‘Fan 2 pin’.
  • Mainboard cooler fan(s) connected to “Heater Hotend 3”.  In Repetier : ‘Heater 3 normally used for extruder 2’.
  • Hotend thermistor connected to “Thermistor Hotend 1”.  In Repetier : ‘Temp 0 normally used for extruder 0’.
  • Heated bed thermistor connected to… the top plugs (per the diagram), which I’m guessing is actually “Thermistor Hotend 5”?  In Repetier: ‘Temp 1 normally used for heated bed.’

3d Printed Cases

I’m sure your Googling is just as good as mine, but I found this nice RADDS & LCD case on Thingiverse:

  • RADDS Case
    • Note, after print I had to cut a long slot (with my Dremel) through the side that said “Arduino Due” to provide wire access to all the screw-terminals on that side.
  • LCD Case

Setting up with Octoprint

I try to use Octoprint most of the time (back using the Rumba/Marlin) for remote print monitoring.  I couldn’t get it to recognize the SD card however on the new hardware.  Under Octoprint’s Settings -> Feature menu, there’s a bunch of “Repetier specific” options :  I checked those all on, and the SD card was immediately recognized.

Also found a slick plugin called the “EEPROM Repetier Editor” that, quote “Makes it possible to change EEprom Values of Repetier Firmware through OctoPrint”.  Nice!

In Conclusion

I’ve had it running for a few weeks, now, and have been tuning my print profiles in Simply 3D:  All my tests have been running at 90m/sec with no issues, so high hopes for much higher values in the future.

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

2016
03/06
CATEGORY
Electronics
projects
TAGS









4 comments