RADDS + RepRapFirmware [mini review]

Hello everyone!

For the last couple of weeks, I have switched my CoreXY printer's electronics to a DUE + RADDS 32-bit controller combo.
For comparison, I also have a Duet 0.6 on a delta I 'm re-building and I may reference it if needed as that's what RepRapFirmware (RRF) is originally made to run on.

First things first, the exact hardware I used:

1. An original Arduino DUE (tried with a clone first but that had problems with its ADC...)
2. A RADDS shield and
3. 4x RAPS128 drivers (128x microstepping!)

For the software, I used RRF from dnewman's repo. It's a fork of RRF for RADDS forked from dc42's repo which, as far as I know, is the most widely used fork of RRF in use (lots of forking taking place in this sentence!)
The repository includes pre-built binary files which you can load easily using bossac.

Alternatively, if you want to compile the firmware yourself, dnewman's fork also incorporates scons build scripts so building it is as painless as can be (no fighting with eclipse). Clear instructions are included so you 'll have no problem.

It's important to note that some RRF features do not work with RADDS:

• don't expect to find a web interface because, simply, RADDS has no ethernet built-in.
• also, don't expect to set motor currents through software; standard drivers are used so you 'll have to use the little trimpot on the driver to adjust Vref.

Software loaded, now what?

I started with the sample files provided for coreXY setups and adjusted to my setup/liking.
The things I had to change were the motor directions, the steps-per-mm for the motors and the thermistor settings (the thermistor series resistors on the RADDS are 4.7K so keep that in mind when setting them up in config.g). Most other stuff needed no change for me.

Does it move?

After double-checking my wiring, I turned the machine on and connected through pronterface (like I said, no web interface for RADDS).
Initial moves were short to avoid crashing the head before making sure everything moved in the correct direction and the correct steps-per-mm were used.
I then checked the endstops and verified they were working as expected, before trying to home the machine.
Finally I tested the heaters.

After the above were done, the machine was alive and I could go print something to celebrate!

Is it any different from 8-bit?

The 32-bit controller makes a lot of difference, I can tell you that!
First, it's not struggling at higher speed anymore. I didn't notice any kind of stuttering and all the head moves were very fluid.
The second thing I noticed is how quietly the motors turn. You won't believe how silent they are! Granted, this is due to the RAPS128 drivers and not the 32-bit board. You could also say that by using these drivers with an 8-bit controller it would yield the same results as far as motor sounds are concerned. And I would agree, if only you could find a 8-bit board that could drive 4 motor drivers at 128x microstepping! So, yeah, as far as I can tell, you do need a 32-bit controller to use these 128x drivers.

Are there any cons?

Here's what I miss from my previous setup (8-bit):

• No simple LCD interface. RADDS do provide an LCD connector but RRF does not support simple LCDs like Marlin/Repetier do. It only supports PanelDue which is too expensive for my taste. I think I read that dnewman has started porting the LCD interface from Repetier but there's no ETA for that. So, for now, you need a computer connected to the printer in order to use it...
• Loading your gcode on the sdcard is possible but because the sdcard is used for storing the configuration files, you need to restart the board after loading the sdcard in order for it to see it. So you have to make sure the reset button remains accessible after commissioning...
• For the time being, I 'm using a Raspberry Pi (version B ) to control RRF through octoprint. I get the impression that this Pi is not able to keep RRF buffers full and it's slowing my prints down. I can only suppose that a Raspberry Pi 2 would be more suitable/powerful for this job.
• I can't seem to make Cura work with RRF. I mean print straight from Cura. The print interface comes up, you press 'Print' and then the progress bar starts filling up without the printer doing anything! I have abandoned using Cura for now. On the other hand this made me re-discover slic3r
• RepetierHost works fine with RRF. One little gotcha is that when it connects to the printer, printer debug messages are enabled and you have to manually disable them (M111 S0). I have this M-code in config.g but with RepetierHost it looks like it's overriden! It may be some option in RepetierHost that I have wrongly set but I thought I 'd mention it here nevertheless...

Wrap up

DUE+RADDS+RAPS128 look like a solid combination with very few drawbacks, some of which are RRF drawbacks actually and apply to Duet boards too.
The most prominent drawback of RADDS when compared to the Duet, is the lack of a network interface and therefore the lack of web control. Although some work is happening to bridge this gap by using a cheap ESP8266! I haven't tried this yet though so I can't comment if it works or not.
On the other hand, it has features not found on the Duet like support for 3 extruders out of the box.
It is important to note that RADDS is also supported by Repetier so there's an additional firmware option if you don't like RRF, for whatever reason.

All in all, I 'm very happy with this setup!

If you have any questions that you think I can answer, please post them!
Also, as I 'm always trying to find ways to improve things, if you have any tips please share them

Cheers!

Hi,

nice review overall.
I have an very similar setup, the only difference i using an windows 10 tablet with pronterface to control the printer.

some comments:
-I using clone arduino due and is work fine, what is the problem you have?
-About the problem you have with the raspberry, are you using the usb native port? I have made some testing using an raspberry 512mb ram and not found any speed problem.
-About cura: the problem is with the slider or starting the print with cura? I used both sliders cura and slic3r and no problems, but always start and controlled the print using pronterface.

I have too installed the 128 steppers and i have the same result you have, the motor make almost no noise or vibration.
Something i have noticed too is the temperature of the motors is always very low. Before i have 1/32 steppers and the motors was hot after some hours of printing, but now the are always cold and using the same voltage i have before (+/- 0.9v).
These 1/128 are very impressive...

Quote
filipeCampos
-I using clone arduino due and is work fine, what is the problem you have?

It had trouble reading the thermistors. I traced it down to a faulty part on the DUE. Here's the solution to the problem.
In the meantime I had already bought an original DUE though so I stuck with it

Quote
filipeCampos
-About the problem you have with the raspberry, are you using the usb native port? I have made some testing using an raspberry 512mb ram and not found any speed problem.

Yes, native USB. I 'm not sure it really slows down the prints, it just looks like it does.
And it certainly did when I connected to octoprint both from my laptop and my smartphone. Two connections were definitely too much for it to stream data and video capture

Quote
filipeCampos
-About cura: the problem is with the slider or starting the print with cura? I used both sliders cura and slic3r and no problems, but always start and controlled the print using pronterface.

That's the point. Using other programs, e.g. pronterface, to "run" the print works ok. Using cura to do this doesn't work (for me at least)... (slicing is fine; sending gcode to the printer is not working from cura)

Quote
filipeCampos
I have too installed the 128 steppers and i have the same result you have, the motor make almost no noise or vibration.
Something i have noticed too is the temperature of the motors is always very low. Before i have 1/32 steppers and the motors was hot after some hours of printing, but now the are always cold and using the same voltage i have before (+/- 0.9v).
These 1/128 are very impressive...

So true

If you are driving a modern printer controller board through its native USB port (which is not the same as serial-over-USB e.g. as on Arduino/RAMPS), then you can get better throughput by turning off the "wait for OK after sending each command" in the host program settings. You can do this in most host programs, but I am not sure that you can in Octoprint.

---

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
dc42
If you are driving a modern printer controller board through its native USB port (which is not the same as serial-over-USB e.g. as on Arduino/RAMPS), then you can get better throughput by turning off the "wait for OK after sending each command" in the host program settings. You can do this in most host programs, but I am not sure that you can in Octoprint.

Yes, I 'm not aware of such a setting in octoprint either...

A little bit offtopic, but how do you set RAPS128 inverted enable signal?.. When my RADDS powers up my motors become instantly engaged and do a loud THUMP without movement. This can't be right.

Quote
toxuin
A little bit offtopic, but how do you set RAPS128 inverted enable signal?.. When my RADDS powers up my motors become instantly engaged and do a loud THUMP without movement. This can't be right.

Use 'R1' in M569 commands. This is from my config.g:

M569 P0 S0 R1							; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S1 R1							; Drive 1 goes forwards
M569 P2 S1 R1							; Drive 2 goes forwards
M569 P3 S1 R1							; Drive 3 goes forwards
M569 P4 S1 R1							; Drive 4 goes forwards

Hey,
You may be able to connect an external Ethernet interface with a connector and PHY chip - such as this. Though it may not be plug-and-play, since the RepRapFirmware code currently only supports a specific PHY chip.
I have to ask, have you heard of / tried my own Aprinter firmware? I provide full support for Due and Duet, including Ethernet (currently G-code console only usable by Pronterface but web interface coming soon). With Aprinter an external Ethernet interface should be easier to work, because my Ethernet support code does not depend on a specific PHY chip but only on the standard IEEE802.3 stuff. I've actually ordered that Ethernet interface and will be able to confirm that it works.

Although I 've read about your firmware, I haven't tried it yet.
Maybe when you implement something basic with the ethernet interface? That would be enticing