RADDS work now stable with RepRap Firmware

Does any of the earlier 1.19 beta series work for you? It sounds as though a recent change may have broken the RADDS build.

---

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 just tried beta6, it does not work.

Thanks for trying that. I'll revert a change that I made to the RADDS configuration at the suggestion of a user, so we can see if that fixes the problem.

---

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
Micktol
I just tried beta6, it does not work.

Hi Micktol (and anyone else who wants to help),

Can you try some earlier versions? It would be really helpful to know exactly which set of changes broke the RADDS build. If you go to [github.com] you can see that releases beta2 and beta3 are also available. To download one of them, click on the <> button next to it, then follow the link to the correct binary and download as usual.

David

---

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].

David,

I tried beta 2 + 3 both of them run, as I said 6 does not, I can test any version you require. Thank you for your work on the radds.

Mike

Thanks, I'll look at what changed between beta3 and beta6. If there are a lot of changes then I can build RADDS versions of betas 4 and 5 for you to test.

Edited 1 time(s). Last edit at 07/17/2017 02:17AM 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 believe I found the problem. Please try beta 10 when I release it later today.

---

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 have tried 1.19 beta 10, on my radds and it connects via usb and panel due. Thanks you.

Thanks for the feedback!

---

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 got my inductive probe hooked up for bed leveling a while back, been working great.
I'm looking to now hook up a simple switch-based out-of-filament sensor. All the reading I've done says I need to hook that switch up to either The E0 or E1 endstop: The E0 endstop is what my inductive probe is hooked to (D39 / E0_AXIS), but I've been unable to find the pin for the E1_AXIS / endstop.

Is this even a thing on the RADDS board?
I'm thinking I may finally upgrade to a DuetEthernet next year, but in the meantime, I'd like to get this switch working if I can. Are any other pins acceptable? Since the RADDS board has min & max endstop headers (and I only use the min), I though maybe I could re-purpose the maxZ, but RRF isn't detecting it or, I'm just doing it wrong.

The Pins_RADDS.h file in the source code indicates that there are only 4 active endstop inputs in the RADDS build. If you can tell me the pin numbers of all 6 endstop inputs, I can add the missing ones if those pins are not already used for something else e.g. the Z probe.

If you connect your inductive probe to the Z probe input instead, you could free up the E0 input.

---

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].

If you want to rewrite the pin mapping section of the code and compile it yourself, you can use many other pins.
Maybe contact the guys who built a CoreXYU with RRF, they heavily hacked the RADDS code...

Quote
dc42
The Pins_RADDS.h file in the source code indicates that there are only 4 active endstop inputs in the RADDS build. If you can tell me the pin numbers of all 6 endstop inputs, I can add the missing ones if those pins are not already used for something else e.g. the Z probe.

(going to presume you know this already, but for due diligence) :
From this page
[doku.radds.org]
is this pic:
[doku.radds.org]
But it has no pin numbers for the endstops, only which endstops they're for.

Poking around more, found this guy:
[www.dr-henschke.de]
Which lists these Due pins for the endstops, if that helps:
P28 X-Min
P30 Y-Min
P32 Z-Min
P34 X-Max
P36 Y-Max
P38 Z-Max

Quote
dc42
If you connect your inductive probe to the Z probe input instead, you could free up the E0 input.

I thought that's what I had done: Are you saying there's a different pin on RADDS other than D39 / E0_AXIS for the z-probe?

FYI: I connected the z-probe to "servoPWM3". Don't know if that's the D39 pin?

Quote
o_lampe
FYI: I connected the z-probe to "servoPWM3". Don't know if that's the D39 pin?

Yep, it is.

Are you aware of the fact, that the 5V line of the servoPWM connectors is not alive? You'd have to feed 5V to the servo5V_in pin if needed.

o_lampe, not sure who that comment is directed too? I already have my z-probe hooked up via that pin top, but it is good info for others. I use the machine ground for it.

This is mainly aimed at dc42, but I think others might be interested in this too. I am planning on getting the TMC2130 stepper drivers and would like to setup stall detection and sensorless homing on my RADDS hardware. I know that the Duet hardware now supports these features in RRF 1.20 beta 5 and later. I also know they use the TMC2660 which is slightly different. I am wondering how hard it would be to set this up with the RADDS and RRF. I realize that some of the pins on the stepper drivers will need to be connected to the SPI bus as well as a few other place. I was thinking of making a small addon board to make this easier. I have not researched it too much but I think the extension board slot of the RADDS has most if not all the necessary pin connections. What are your thoughts on this?

It sounds possible to me if you have a spare USART on the Due to use for the SPI interface to the TMC2130 drivers. But also quite a lot of firmware work to do, enabling the smart drivers support in the RADDS build and then adapting it for TMC2130 drivers. You would also need to change the driver polling code to use a spare DMA channel instead of the PDC, or else provide a way for the Due to read the stall outputs directly.

Edited 1 time(s). Last edit at 12/13/2017 03:42AM 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].

So Thomas Sanladerer made a tutorial on setting this up with RAMPS and Marlin on YouTube (https://www.youtube.com/watch?v=sPvTB3irCxQ). In it he has you wire the DIAG1 pin of the TMC2130 driver boards to the endstop pins of the RAMPS board. I am guessing that Marlin is setting this pin so that when the motor stalls this pin goes active which triggers the end stop.

As for wiring the RADDS extension board header does not have any SPI pins which is sad, but the RADDS has an external SD card header that does. It could be used to get the SPI bus. The extension board does have plenty of GPIO pins which can be used for slave select though.

I have made a RADDS build of RepRapFirmware 1.20RC2 available via [github.com]. As with all RADDS builds, I have not tested it. I plan to release 1.20 next week, so there are only a few days left to try it and report any bugs.

There are numerous new features in 1.20 series firmware. See [github.com] for the changes since the last stable release, which was version 1.19.2.

Version 1.20 is the last release I intend to do for SAM3X processors, although there may be 1.20.x releases if bugs need to be fixed. RepRapFirmware will be migrated to use a Real Time Operating System in the near future, and sadly the SAM3X processors have insufficient RAM to support RTOS.

---

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].

How much RAM is required?

That depends on how much stack the process uses. Probably around 1K per process on average.

---

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].

So, what kind of beefcake hardware is RRF going to be designed for? Are there 64-bit, or super high-end 32-bit boards with 3d printer shields? Honestly the RADDS and Duet series of boards are the best I've found anywhere so far. Am I just out of the loop?

Edited 2 time(s). Last edit at 12/24/2017 03:27PM by Lobotomy.

The current generation Duets use ARM Cortex M4F processors with 128kb RAM. The ARM Cortex M3 processor used in the older Duets and the Arduino Due costs more, even though it has less RAM and no floating point unit. So ARM Cortex M4 is currently the sweet spot, at least in the Atmel/Microchip range. I switched PanelDue from ARM M3 to ARM M4 too a few months so that I could reduce the price.

So, with ARM M4 being the sweet spot right now and the first generation Duets being tight on RAM, the RTOS-based version of RRF will be targeted at ARM M4 processors and higher with 128kb or more RAM. But technology doesn't stand still and we're already looking beyond ARM M4 to address the higher end of the market.

Edited 1 time(s). Last edit at 12/24/2017 06:48PM 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].

Hi David!

I managed to melt down my bed connector on my RADDS board and probably damaged the FET too. The anoying thing is that the fuse remained unharmed and I used a thick, properly fastened cable. I managed to heat up the bed as a hotend tool on H2, through an external FET.
Is there a way to configure the firmware to use the second heater pin as bed output to control the external FET?

Gergely

Yes, use M140 H2 in config.g.

---

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].

Thank you David, it woks perfectly. I just had to raise the M570 P parameter over 45, to avoid the heating faliure.

I understand completly why you drop the RADDS support, but I'm a bit disappointed becouse RADDS+DUE was a budget option to bring RepRap FW to low-end printers. Cheap deltas benefit the most from it.
Do you plan to release cheaper (mini?) board?
Like Azteeg X5 mini Wifi. I really like that board but I choosed RADDS, becouse I prefer RepRap over Smoothie for a delta. For most printers you just need 4 drivers, and you rarely go over 1-1,2 Amps, the frame of those printers not rigid enough to bear the higher acceleration. Replaceable stepper drivers can withstand such a current. Most printers uses just one extruder and a smal, low power bed or a big AC one with SSR.
Duet is a robust, exeptionally well designed board, but it is overkill for the majority printers.

Edited 2 time(s). Last edit at 01/14/2018 08:35AM by FTheta.

Quote
FTheta
Thank you David, it woks perfectly. I just had to raise the M570 P parameter over 45, to avoid the heating faliure.

I understand completly why you drop the RADDS support, but I'm a bit disappointed becouse RADDS+DUE was a budget option to bring RepRap FW to low-end printers. Cheap deltas benefit the most from it.

Thanks; but perhaps further explanation wouldn't go amiss.

I have never received any form of remuneration for supporting RRF on the ATSAM3X8E boards (Duet 06, Duet 085, RADDS/Due and recently Alligator), except indirectly when users of those boards buy a PanelDue. Up to now, the additional effort needed to support those boards has been small, so I have been happy to continue to maintain the source code for them and build binaries for them, although the Duet 06/085 build was the only one of those that I tested before each release. But that has changed for two reasons. First, with all the additional features that have been added to RRF recently, RAM is getting tight on the SAM3X8E. I had to spend a lot of time reducing the RAM requirement of the recent 1.20 release to make it fit in the RAM of the SAM3X8E. Second, the switch to RTOS for the generation 2 Duets can't be done for the SAM3X8E builds because of the extra RAM needed, and it's not practical to do RTOS/non-RTOS builds from the same source code. So the source code trees for the SAM3X8E builds and the builds for SAM4 and later processors have to be split. If we don't make the switch to RTOS, RRF will get stuck in a rut - much like Marlin has been stuck in a rut for years because it has continued to be focussed on supporting atmega2560-based boards instead of migrating to 32-bit processors.

Support and development of RRF for the Duet 2 series (currently the Duet Ethernet and Duet WiFi) and its successors has become almost a full-time occupation for me. So I won't have time to maintain a separate SAM3X8E fork. Of course, there is nothing to prevent anyone else forking RepRapFirmware and continuing to develop it for SAM3X8E boards. Or someone could develop a new Arduino based on a SAM4 processor - ideally with an integrated high speed SD card socket and Ethernet or WiFi (I never understood why thr Arduino Due didn't have integrated Ethernet, it seemed such a dumb decision to use an Ethernet-enabled processor and not to provide it).

Quote
FTheta
Do you plan to release cheaper (mini?) board?

Watch this space.

PS - the switch to RTOS has been delayed for one more release, so I intend to produce a RADDS build of release 1.21.

Edited 2 time(s). Last edit at 01/14/2018 05:18PM 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].

Hi dc42, been interested in getting a RADDS to have a backup to my two duet wifis (I really like interchangeable stepper driver boards). I just have a question about BLtouch using Reprapfirmware on RADDS, I see in here people talk about putting it on PWM 3 or PWM 1 (the lower left corner on the board where one needs to solder in the header pins). Which one is it or does it not matter, it's just a coding change? Btw how's Radds build 1.21 coming along (that's talking about the RRF or the board itself?)