RADDS work now stable with RepRap Firmware

Hi dnewman,

Have you done progress on the lcd support for the reprapfirmware?

Quote
filipeCampos
Hi dnewman,

Have you done progress on the lcd support for the reprapfirmware?

Yes, there has been progress. However, I had to take a break for a bit owing to some medical/health issues with some family members. Indeed, the LCD UI may actually be working now. Unfortunately, I needed to take off and travel and did not bring the electronics with me. I hope to return to it in another week.

Hi all,
I have made most of the RADDS documentation and the content in doku.radds.org
I`m working on updating the documentation + adding new content
I hope to add documentation about how to install and configure the RepRap firmware on RADDS:
http://doku.radds.org/dokumentation/firmware/arduino/reprap/

Anyone here that use it and can make a simple step by step documentation?

I have some problems when trying to install the firmware - bossac does not find any board connected - have to test some more later.

I use RADDS w/ RRF, very happy with it
What steps exactly are you looking for? Hopefully I can provide the info you need.

My plan is to:
1. Do a test install on my DUE/RADDS.
2. Try to make a step by step guide about how to install the firmware on DUE/RADDS
3. How to configure basic settings for RADDS LCD, end stops, and RAPS128 stepper drivers.

At the moment I have some problems where bossac do not find my DUE/RADDS when using the programming port - I found in this forum that some other users have this problem -have to test more

First I have to do the Filament Tracking System (FTS) documentation (setup + Repetier firmware config). When done I`ll continue working on the RepRapFirmware documentation.

Edited 1 time(s). Last edit at 01/01/2016 09:06AM by mundsen.

Quote
mundsen
At the moment I have some problems where bossac do not find my DUE/RADDS when using the programming port - I found in this forum that some other users have this problem -have to test more.

I think bossac only works with the native USB port. The Duet (for which RepRapFirmware was originally written) doesn't have the programming port.

Edited 1 time(s). Last edit at 01/01/2016 10:11AM by dc42.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

I use the bossac which ships with the Arduino app with either port on the Due.

With the programming port, you do not need to press the ERASE button and can even avoid pressing the RESET button if you first connect to the port and assert 1200 baud then disconnect. (That's how the Arduino app does it; I do that in the scons tools in my fork of the dc42 RepRapFirmware.)

With the native port, I need to press the ERASE button and then the RESET button to get the version of bossac shipped with Arduino to download firmware to a Due. Others have told me that they do not always need to press the ERASE button.

Quote
mundsen
3. How to configure basic settings for RADDS LCD, end stops, and RAPS128 stepper drivers.

Unfortunately, I've not had the opportunity to finish the LCD support for RADDS + RepRapFirmware. Between a death, being busy over the holidays, and plenty of other code changes going on in the firmware, I've not yet had the time to finish the work. (The first cut is done, I just need to find time to actually test it all.)

So if I want to test RepRap firmware on RADDS I have to use PanelDUE?
If so I`ll consider getting a PanelDUE so I can continue the testing/documentation

Quote
mundsen
So if I want to test RepRap firmware on RADDS I have to use PanelDUE?

You should be able to use any of the desktop printer control programs. Or even Octoprint, although note that

1. Octoprint's "fan on" command just sends "M106" with no "Snnn" parameter. I edited Octoprint to add in "S255" as RepRapFirmware requires a "S" parameter to turn the fan on. Foosel agreed several months back to update Octoprint to include "S255" -- the current Octoprint may now include the "S255". You can always add a new control to Octoprint via it's config file. You can add a control to issue "M106 Snnn" with an adjustable value for "nnn". That's what many folks do when they need a different fan power level.
2. Octoprint is hard-coded to think that "M0" is a pause and it intercepts it. That's Marlin's take on M0. (Maybe Repetier's as well?) However, with RepRapFirmware, M0 is used to end a print by turning heaters and motors off. So, if you have a M0 in your ending gcode and use Octoprint to spool the print over USB, then Octoprint will intercept the M0 and not send it to the printer. The printer will be left "paused" with the heaters and motors on. When I tested with Octoprint, I changed my ending gcode to explicitly turn heaters and motors off. Foosel indicated that work on a future new communications layer in Octoprint will address this.

Edited 1 time(s). Last edit at 01/01/2016 01:31PM by dnewman.

ok,here is some of what I have found:

- when using RepRap firmware you have to use the PanelDUE, and/or control the printer using a Control Program

- The git page say you should use the programming port

- The printer is configured by editing files on the SD card

What is the benefits in using RepRap Firmware compared to Marlin, Repetier..?

I'm just on the fringes of RepRapFirmware. My opinions below do not necessarily represent those of the primary authors.

Quote
mundsen
ok,here is some of what I have found:

- when using RepRap firmware you have to use the PanelDUE, and/or control the printer using a Control Program

Note that this is true of all 3D printers. You use the supported LCD interface (in this case PanelDue) and/or you use a supported control program. Again, this is true of any 3D printing firmware. Only question then is what are the supported LCD interfaces and what are the supported control programs.

Quote
mundsen
- The printer is configured by editing files on the SD card

Actually, it is configured by gcode. The gcode can be of any source. It's useful for the printer to startup with a configuration appropriate to the hardware and so a config.g file located on the SD card can be used. However, the configuration -- or changes to the configuration -- can also be sent from a control program, supplied in a print's starting gcode, or both. This is arguably more convenient than having to install and configure a programming build environment, figure out how some C code and header files work, edit those files successfully, and then compile and install a build of the firmware with the necessary configuration (type of motion control to use, number of extruders supported, wiring of heaters to extruders, stepper motor configuration, etc.). With RepRapFirmware this is all configured at run-time; no need to compile sources. Far more end-user friendly.

Quote
mundsen
What is the benefits in using RepRap Firmware compared to Marlin, Repetier..?

In Marlin and Repetier, portability takes priority over safety. For ease of portability, software PWM is used. That means that if the firmware locks up, you can have a heater locked on at 100%. Of course, the Watch Dog Timer (WDT) is meant to catch lockups. However, the WDT has been less than reliable in Repetier on Due with some melted down extruders resulting. And despite repeated fixes to Repetier's WDT, there's still cases where it can be tripped up. E.g., the SD card code whilst doing a directory listing resets it repeatedly. A SD card corruption can turn that into an infinite loop and with the WDT being reset in that loop, it will never do its job of resetting the processor. (That's not theoretical; I have a test SD card which does just that and freezes Repetier.) In Marlin, until very recently, the WDT was disabled by default. Daid changed that recently. RepRapFirwmare, OTOH, has a reliable WDT and uses hardware PWM. With hardware PWM, even if the processor locks up, the heater is only running at the requested duty cycle. Once a print gets underway, the typical PID-commanded duty cycle is 10 - 30%. A heater left locked on at 30% is far less likely to start a fire.

Another fault with Marlin and Repetier on ARM is that they are simply ports of the Arduino software to ARM. As such, they do not leverage the advantages of ARM (e.g., hardware PWM on most pins, much faster SD card support, DMA support, etc.). RepRapFirwmare was written from the ground up to leverage advantages of the ARM. Marlin and Repetier ignore them in the name of being portable between AVR and ARM.

As I mentioned previously, RepRapFirmware is highly configurable through gcode. The things which require recompiling of Marlin or Repetier can be done with gcode with RepRapFirmware. (Likewise for Smoothie and MachineKit; this isn't unique to RepRapFirmware.)

An interesting aspect of the dc42 port of RepRapFirmware is the abandonment of the Bresenham line algorithm for motion control. Instead it runs each motor at its "natural" speed for the motion in hand. While the Bresenham line algorithm is nice, it theoretically introduces aliasing artifacts as it forces all axes to take steps in lock-step. The axis with the most steps, takes a step each timing interval. All other axes have to take their steps less frequently but at the same time as a step for the "primary" axis. If, in fact, an axis is moving with an incommesurate timing, then it's out of luck. This produces a case where that axis then has to do things like take 2 steps for every 5 of the primary BUT occasionally 3 steps. for every 5. That in turn can result in beat patterns. By doing away with Bresenham's line algorithm and running each axis at its natural speed, you do away with these potential beat patterns.

Finally, I'd argue that RepRapFirmware is the most advanced firmware for Delta printers.

I'm just on the fringes of RepRapFirmware. My opinions above do not necessarily represent those of the primary authors.

Edited 1 time(s). Last edit at 01/01/2016 07:09PM by dnewman.

For purposes of documentation, I'd say that the advantages of RepRapFirmware (RRF) over Marlin and Repetier are

1. Strong emphasis on safety. Saying much more than that invites arguments.
2. Written for AMR and leverages features of the ARM architecture (20x faster SD, DMA, widespread use of hardware PWM).
3. Run-time configuration instead of compile-time configuration.
4. Advanced Delta printer support.
5. Doesn't use Bresenham's line algorith, Bresenham's was used back in the "old" days to accommodate the slow, 8bit 16 MHz AVRs with not much memory: it's easy to implement and, by virtue of using integer arithmetic, fast. But it introduces aliasing.
6. Intriguing features such as diagnostics written to NVRAM on resets (e.g., WDT triggers). Answers the question of, "why did the printer reset?" by providing a post-mortem which can be queried after reboot.
7. Probably a lot of other things which others might mention.

Ok, I understand. Now I have to test it ☺

Edited 1 time(s). Last edit at 01/02/2016 05:06AM by mundsen.

I have an OrdBot Hadron (my test printer) and a BBOne + I may get a Delta later
My plan is to try RepRap firmware on my test printer running DUE+ RADDS + RAPS128 + maybe a PanelDUE
If it turns out ok, I`ll try to document (doku.radds.org) how to install it on RADDS and the basic configuration..

I have tested the reprapfirmare with radds and for an firmware in testing phase i was very impressed.

At the moment i using repetier firmware because the lack of radds lcd support of the reprapfirmware, but when it will have the lcd support i definitely planning to move to the reprapfirmware.
Was print quality or velocity, i do not have noticed any big difference between the two firmware (tested on an corexy printer). For me the main vantage is the configuration of the printer by gcode, this allow to updated the firmware without the need to reconfigure or recompile the firmware. Repetier was the web configuration, it help a lot on this task but the gcode configuration it an more easy and elegant solution.

The reprepfirmare have a lot of potential, but it still lacking some important features. But In the future there is good probability to be the best firmware for the radds boards.

An apart: Some days ago i was making changes on my printer and accidentally broken the usb native port of my arduino due, i was using the native port to make all my print using an windows tablet to send the gcodes instructions. without the native port i changed to the programing port, but found that i have major speed connection problems. Now i can only print using the sd card. Only telling this because it appears the native port was an better speed connection.

If using the programming port and Repetier Host

Go to Printer Settings -> Connection -> Receive Cache Size and set it to 64

Then I guess your communication is ok

Quote
filipeCampos
I have tested the reprapfirmare with radds and for an firmware in testing phase i was very impressed.

At the moment i using repetier firmware because the lack of radds lcd support of the reprapfirmware, but when it will have the lcd support i definitely planning to move to the reprapfirmware.

FYI I reduced the price of PanelDue touch screen controller boards yesterday, see [forums.reprap.org]. Once you have used a PanelDue, you will never want to go back to a dumb LCD!

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Hello everyone, I've just completed building my SparkCube XL CoreXY printer with RADDS electronics and I'm trying to figure out the software side of things. This is my first time rolling my own firmware and I'm a little overwhelmed.

I’ve had a Printrbot Simple for a few years so I’m not completely new to 3D printing builds, but the Printrboard firmware was pretty much “point and shoot” to get working.

I tried Repetier and I had about 90% of the functionality I needed but, after reading this post, RepRapFirmware seems to be the best option going forward.

With the benefit of a larger test base I was hoping this group could help me and other "user level" printer enthusiasts get started with RepRapFirmware for RADDS.

Here is my progress so far:
I have the firmware uploaded to the Due. I had a few issues, but once I read that you need to press the reset button on the Due I was able to load the firmware *.bin file using Bossac on the programming port.
(note for self/others the --port=PORT switch in Bossac is your current Arduino COM port [--port=COM*])

I added the sys/ folder to an SD card and tried to make my way through the RepRapFirmware Wiki for configuring a Cartesian printer and then the CoreXY modifications and I also used the config files included with the GitHub (sys-CoreXY-maxXY-minZ).

I fired up the printer and it was off to the races, every MOSFET was wide open, all fans and heaters were going full blast… So that wasn’t a good start.

So this is where I ask for help.

Here is my hardware configuration:
CoreXY design with (2) 0.9 deg. steppers for XY motion and 3 1.8 deg. steppers for Z motion.

The Z steppers are driven by (2) RAPS128 drivers, 2 steppers paired together on the primary Z socket and the third stepper on an additional driver in socket EXT3. (I plan on using an additional driver to implement 3 point hardware bed leveling in the future, but I would like to just get software leveling working at this point)

I have 2 mechanical endstops for X and Y max (assuming 0,0 is the front left corner of the print bed) and these are closed circuit normally, open when activated. They are connected to the RADDS XY Min endstop connectors.

The Z endstop/probe is David’s (dc42) mini IR height sensor board connected to the RADDS Z-Min endstop with the corresponding 3.3v power.

Most of the other components are connected in the standard fashion according to the RADDS documentation. My bed heater is mains powered on an SSR control. I have an always on hotend fan and a print cooling fan wired to the RADDS fan outputs 1 and 2. This is a single extruder setup. I’m running a 24V psu and corresponding 24V fans, hotend ect.

What I’m hoping for is some kind person to either walk me through the process or provide a working example so I can get this printer alive. I would love to provide feedback that I can to move this project forward.

Thank you for your time!
Weston

I trust that you're using a stable, released build such as

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09k-dc42-radds-b.bin

If you are building yourself, then things may not be working at present. There's been a lot of churn recently and I've not had time to test any of the changes on RADDS since November. I'll see if I can do a quick sanity test this afternoon, but no promises. In the meantime, stick to a known good, stable, released build.

For the stepper drivers, did you use a M569 command to invert the enable? RAPS128 drivers have an inverted enable and unless you inform the firmware of that fact, when it boots up and disables all motors it ends up enabling them. I have the following in my config.g,

M569 P0 S1 R1                                           ; Drive 0 goes forwards; inverted enable
M569 P1 S0 R1                                           ; Drive 1 goes backwards; inverted enable
M569 P2 S0 R1                                           ; Drive 2 goes backwards; inverted enable
M569 P3 S1 R1                                           ; Drive 3 goes forwards; inverted enable
M569 P4 S1 R1                                           ; Drive 4 goes forwards; inverted enable
M569 P5 S1 R1                                           ; Drive 5 goes forwards; inverted enable

Of interest to you is the "R1" parameter. My "Sn" parameters are unique to my printer. I can either flip the motor connectors to effect a hardware direction reversal OR do a firmware direction reversal with the "S" parameter. I've done the latter, a firmware reversal.

As to why your heaters turn on, I am unsure. As it happens, my config.g errors on the side of caution and turns them all off regardless,

;*** Heaters off
M104 S0 T0
M140 S0

But just now, I commented those two lines out and restarted the printer: they heaters did not turn on. No fans turned on either.

My full config.g file for my Core-XY on RADDS is

M111 S0                             ; Debug off
M550 PCoreXY                                    ; Machine name (can be anything you like)
M551 Preprap                        ; Machine password (used for FTP connections)
;M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
;M552 P0.0.0.0                                          ; IP address (0 = use DHCP)
;M552 P10.30.32.13                   ; IP address
;M553 P255.255.0.0                   ; Netmask
;M554 P10.30.218.161

M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimeters
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Machine configuration
M569 P0 S1 R1                                           ; Drive 0 goes forwards; inverted enable
M569 P1 S0 R1                                           ; Drive 1 goes backwards; inverted enable
M569 P2 S0 R1                                           ; Drive 2 goes backwards; inverted enable
M569 P3 S1 R1                                           ; Drive 3 goes forwards; inverted enable
M569 P4 S1 R1                                           ; Drive 4 goes forwards; inverted enable
M569 P5 S1 R1                                           ; Drive 5 goes forwards; inverted enable
; If you use an endstop switch for Z homing, change Z0 to Z1 in the following line, and see also M558 command later in this file
M574 X2 Y2 Z1 S0                                        ; set endstop configuration (X and Y and endstops only, at low end, active high)
M667 S1                                                         ; set CoreXY mode
;M906 X1200 Y1200 Z1200 E720         ; Set motor currents (mA)
M92 X88.88889 Y88.88889 Z400 E96.27520187 ; Set steps/mm
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600       ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20              ; Maximum jerk speeds mm/minute
M208 X100 Y100 Z2000                            ; set axis maxima (adjust to suit your machine)
M208 X-100 Y-100 Z-0.5 S1                       ; set axis minima (adjust to make X=0 and Y=0 the edges of the bed)

; Z probe
;M558 P1 X0 Y0 Z1                    ; Analog Z probe, also used for homing the Z axis
;G31 Z1.20 P500                      ; Set the probe height and threshold (put your own values here)
; The following M557 commands are not needed if you are using a bed.g file to perform bed compensation
;*** Adjust the XY coordinates in the following M557 commands to suit your build and the position of the Z probe
;M557 P0 X60 Y0                      ; Four... 
;M557 P1 X60 Y165                    ; ...probe points...
;M557 P2 X222 Y165                   ; ...for bed...
;M557 P3 X222 Y0                     ; ...levelling
;M557 P4 X141 Y82.5                  ; 5th probe point for levelling

; Tool definition
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures
;*** If you have a dual-nozzle build, remove or comment out the previous line, and un-comment the following 3 lines1
;M563 P1 D1 H2                      ; Define tool 1
;G10 P1 S0 R0                       ; Set tool 2 operating and standby temperatures
;M563 P2 D2 H3                      ; Define tool 2
;G10 P2 S0 R0                       ; Set tool 2 operating and standby temperatures
;M563 P3 D3 H4                      ; Define tool 3
;G10 P3 S0 R0                       ; Set tool 3 operating and standby temperatures
;M92 E96.27520187:96.27520187:96.27520187:96.27520187   ; Set extruder steps/mm (dual nozzle)

; Thermistors and heaters
;*** If you have a Duet board with 4.7K thermistor series resistors, change R1000 to R4700 to the following M305 commands
; You can also use S and B parameters to define the parameters of the thermistors you are using
M305 P0 T100000 R4700 B4066 H0 L0       ; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 T100000 R4700 B4066 H0 L0       ; Put your own H and/or L values here to set the first nozzle thermistor ADC correction

;*** Heaters off
M104 S0 T0
M140 S0

;*** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0                   ; Axis compensation here
M18                                 ; Disable stepper motors
T0

I've not myself tested one of dc42's IR sensors with the RADDS.

I can confirm now that if you build using the current sources for RADDS, you will have non-functioning firmware. For example, the SD card support isn't working nor is serial comms. This is likely all related to changes made to support multiple builds in the mainline dc42 fork. Mind you, not dc42's fault. Rather, that I've not had time to test any of this.

So, for the time being, stick to a known good released build for RADDS such as

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09k-dc42-radds-b.bin

Thanks for the quick reply! I'll work through the config again tonight. I can already tell you that part of my problem is I used the 1.09o build instead of the 1.09k for RADDS build so that will be the first thing I correct.

Hi, great if you document your findings

I plan to test a setup with RADDS + RAPS128 + PanelDUE + RepRap firmware, and try to document how to get started + basic settings at [doku.radds.org]
In that way it may be easier for other users to get started

I just did a checkin to the RADDS port; things should be working better now. However, I have not done much testing other than to assure that serial comms works, SD card works, homing and heating works.

The issue was the new Roland mill code. Indeed, dc42 didn't initially check it in so when I first merged in the changes from that branch, I conditionalized the Roland code out (since it was missing for the most part). I then did do a quick test and things work. Later, the Roland code became available so I merged it in and removed my conditionals. But I didn't have time to do any testing....

Turns out, the Roland code hard codes using Serial1 -- that had some impact on the RADDS use of Serial1 (for PanelDue). And the Roland code changes the pin configuration around a bit for SPI0 MOSI and SLCK.... So, the SD card would be mounted correctly, but then Roland would be initialized after which no files could be read off of the SD card (including config.g). The MAX31855 code which does a lazy init probably manages to undo the Roland changes to the SPI0 bus. I don't know, I've not looked into that yet.

But, with my latest checkin the RADDS build now excludes the Roland sources and superficially seems to function again.

Changing the firmware image to 1.09k for RADDS was the initial issue. I got some basic movement and heat/temps back from the printer but I ran into an issue that may be specific to my build. Since I'm using a second stepper driver I can't get my Z axis to work, the first 2 motors work fine on the paired Z axis, but I can't define another driver set to mirror the Z. This seems to be a RepRapFirmware limitation.

From the wiki: M569: Assigns driver 0 to control the X0 motor. In place of X0 you can use Y0 Z0 E0 E1 E2 etc. to assign the driver to the corresponding motor. Currently, only one driver can be allocated to each axis or extruder.

Is there a way around this?

; SparkCube config file for dc42 Due RADDS firmware

M111 S0                             ; Debug off
M550 SparkCube				        ; Machine name (can be anything you like)
M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves

; Machine configuration
M569 P0 S0 R1 Y0 							; Drive 0 goes forward (change to S0 to reverse it)
M569 P1 S0 R1 X0							; Drive 1 
M569 P2 S1 R1 Z0							; Drive 2 
M569 P3 S1 R1 E0							; Drive 3 
M569 P5 S1 R1 Z0							; Drive 5 
M92 X640 Y640 Z800 E953.1

; If you use an endstop switch for Z homing, change Z0 to Z1 in the following line, and see also M558 command later in this file
M574 X2 Y2 Z1 S1					; set endstop configuration (X max, Y max, Z min, active HIGH)
M667 S1								; set CoreXY mode
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600       ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20              ; Maximum jerk speeds mm/minute
M208 X300 Y300 Z205					; set axis maxima (adjust to suit your machine)
M208 X10 Y0 Z-0.5 S1				; set axis minima (adjust to make X=0 and Y=0 the edges of the bed)

; Z probe
M558 P1 X0 Y0 Z1 H5 F200 T5000 ; smart IR Z probe, used for homing Z axis only, dive height 3mm, probe speed 200mm/min, travel speed 5000mm/min
G31 P500 X-28.3 Y22 Z1.65  ; set threshold and offsets

; Tool definition
M563 P0 D0 H1                       ; Define tool 0
G10 P0 S0 R0                        ; Set tool 0 operating and standby temperatures
M92 E953.1                        	; Set extruder steps per mm (single nozzle)

; Thermistors and heaters
;*** If you have a Duet board with 4.7K thermistor series resistors, change R1000 to R4700 to the following M305 commands
; You can also use S and B parameters to define the parameters of the thermistors you are using
M305 P0 R4700 H0 L0					; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 R4700 H0 L0					; Put your own H and/or L values here to set the first nozzle thermistor ADC correction

;
T0									; select first hot end

RRF does not currently support paired drivers. With 3 Z motors, I suggest you connect them in series and drive them all from one driver. Depending on the motors, you might need to use 24V power to run the Z axis at a reasonable speed.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Any recommendation regarding SD cards in terms of speed and capacity

Quote
dc42
RRF does not currently support paired drivers. With 3 Z motors, I suggest you connect them in series and drive them all from one driver. Depending on the motors, you might need to use 24V power to run the Z axis at a reasonable speed.

I was thinking about doing this but couldn't find a good example of this done with more than 2 motors. I didn't want to overload my stepper driver without knowing what I was doing. I am running a 24v power supply so that is easy, other than slow axis response are there any other risks I should look out for?

Also, can you define endstop switches Hi/Lo independent of each other or do they all need to be the same?

Quote
WestonWW

Quote
dc42
RRF does not currently support paired drivers. With 3 Z motors, I suggest you connect them in series and drive them all from one driver. Depending on the motors, you might need to use 24V power to run the Z axis at a reasonable speed.

I was thinking about doing this but couldn't find a good example of this done with more than 2 motors. I didn't want to overload my stepper driver without knowing what I was doing. I am running a 24v power supply so that is easy, other than slow axis response are there any other risks I should look out for?

Also, can you define endstop switches Hi/Lo independent of each other or do they all need to be the same?

I can't think of anything else you should look out for with 3 motors wired in series, other than the mechanical issue of the motors getting out of sync when you turn the printer off and on again. Unless your motors have unusually low current/high voltage requirements, with a 24V supply it should work well. Yes, you can have high endstops on some axes and low endstops on others.

---

Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].

Quote

Yes, you can have high endstops on some axes and low endstops on others.

How do you do this? I have M574 X2 Y2 Z1 S1 defined for the end stops but I don't know how to change the "S1" without changing all of the end stops. I can rewire, but I would rather have the X,Y wired closed for an additional safety check. My IR probe is normally open and closed when triggered.

I'm trying to get my hotend fan to turn on when the hotend reaches 40C so I defined M106 P1 T40 H1 but it doesn't seem to work. M106 P1 S255 works fine, although any S value other than 0 turns the fan on, there isn't a gradient to the speed. I may be missing something about this function.

The Z steppers wired in series seem to work well so far, I haven't started to print yet though.