Status of DUE&RADDS support

dc42

Do you know what the pin assignments are for CS0 and CS1?

bruce356

Hi, I am not a technical person, wondering if I could use the firmware that you are working on here for my dual x carriage Cartesian (Mendel) printer with Due/RADDS. I would probably require a bin file as I know nothing about compiling this type of firmware.
Thanks and regards - bruce

mb0

CS0 -> Arduino Pin 10 -> SAM3X PA28/PC29 -> Physical 102
CS1 -> Arduino Pin 4 -> PA29/PC26 -> Physical 137

btw. the printer is running now for >4h without any issues (related to the firmware).
the current setup is RADDS&RAPS128@1/128 0.9 stepper for x/y. z@1/32, extruder@1/16.
24V. It can't go full speed at this microstepping rate. i noticed some "pauses" when printing
large rounded corners. it seems that braking after travel movement is quite aggressive, i get
strange sounds as if the hotend would have bumped into the print.

edit: after setting the raps to 1/32 for all steppers the bumping is gone. is suspect planner
errors because out-of-time situations.

dc42

@bruce356:

Hi, I am not a technical person, wondering if I could use the firmware that you are working on here for my dual x carriage Cartesian (Mendel) printer with Due/RADDS. I would probably require a bin file as I know nothing about compiling this type of firmware.
Thanks and regards - bruce

RRF 1.16 and later support multiple X carriages in the standard binaries. See https://duet3d.com/wiki/Configuring_multiple_independent_X-carriages_on_a_Cartesian_printer. So if someone produces a stable RADDS build of 1.16 or 1.17, you should be able to use the binary.

dc42

@mb0:

CS0 -> Arduino Pin 10 -> SAM3X PA28/PC29 -> Physical 102
CS1 -> Arduino Pin 4 -> PA29/PC26 -> Physical 137

btw. the printer is running now for >4h without any issues (related to the firmware).
the current setup is RADDS&RAPS128@1/128 0.9 stepper for x/y. z@1/32, extruder@1/16.
24V. It can't go full speed at this microstepping rate. i noticed some "pauses" when printing
large rounded corners. it seems that braking after travel movement is quite aggressive, i get
strange sounds as if the hotend would have bumped into the print.

edit: after setting the raps to 1/32 for all steppers the bumping is gone. is suspect planner
errors because out-of-time situations.

What were your steps/mm @ 128x ?

I have provisionally changed the SD card section in Pins_radds.h to this:

// SD cards
const size_t NumSdCards = 2;
const Pin SdCardDetectPins[NumSdCards] = { 14, 14 };
const Pin SdWriteProtectPins[NumSdCards] = { NoPin, NoPin };
const Pin SdSpiCSPins[2] = { 87, 77 };

You will also need to change line 73 of asf/conf_sd_mmc ni CoreNG to:

#define SD_MMC_SPI_MEM_CNT			2			// Number of SPI card slots supported

i.e. change 1 to 2.

I think this should address the internal SD card as card 0 and the external one as card 1. Please can you test this. I have assumed that the CD pin of both sockets are wires in parallel, but if the external card has no CD pin then change the second 14 to No Pin, otherwise the external SD card won's work unless the internal SD card is present.

mb0

my steps/mm @ 128x where

[[language]]
M92 X905.414787 Y905.414787 Z1280   ; set axis steps/mm
M92 E152                            ; set extruder 0 steps/mm

mb0

internal sd card working after adding your suggested changes.

for updating i had to use bossac again. i'm afraid but the duetiap from dcnewman did not work. i think
to make the port complete it should be updated to radds as well.

big thanks for integrating radds into mainline! you should post about the progress at reprap forums
maybe more people get interested in the radds port then. (it seems that there are quite a few germans using
radds boards). unfortunately the guy i tried to contact (angelo/max3dprintshop) did not respond.

dc42

The duetiap will probably need rebuilding against the new CoreNG. Is there any difference between the dcnewman source to duetiap and the one in my GitHub repo?

Ideally the SharedSpi interface should be converted to use DMA again, to reduce the CPU load when reading the file being printed from the SD card.

mb0

seem to be no source code changes. only SCons and .gitignore related changes.

mb0

if i interpret the following right then DMA was explicitly disabled on RADDS in dcnewman's repo:

[[c]]
# if defined(USE_SAM3X_DMAC) && !defined(__RADDS__)
	pmc_enable_periph_clk(ID_DMAC);
	dmac_disable(DMAC);
	dmac_set_priority_mode(DMAC, DMAC_GCFG_ARB_CFG_FIXED);
	dmac_enable(DMAC);
# endif

dc42

I think the DMS nice that Dan was using was somewhere else,