Duet3D Logo

    Duet3D

    • Register
    • Login
    • Search
    • Categories
    • Tags
    • Documentation
    • Order

    Status of DUE&RADDS support

    General Discussion
    4
    29
    3881
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • mb0
      mb0 last edited by

      hi,

      before starting to dig around github a lot i just wanted to know if someone can clarify the status of due&radds support. dcnewman's github states that he stopped his fork. in the source of dc42 i can see some #ifdef RADDS so far. the status of the port is however a bit unclear.

      maybe someone has some insight or is even using RRF on this combo?

      1 Reply Last reply Reply Quote 0
      • dc42
        dc42 administrators last edited by

        dcnewman has two sets of RRF repositories. The older ones are RepRapFirmware-RADDS and CoreNG-RADDS and the readme files say that development of these was stopped on 21 April. The more recent ones are RepRapFirmware and CoreNG and they were last updated on 16 July. I don't know whether he has any plans to continue development of that fork.

        My policy is that although I do not have time to maintain RRF for RADDS, I will gladly incorporate changes for RADDS into my fork on request provided they comply with the coding guidelines. That is what I have done for dcnewman. Also, when I make changes that I know will need additional work for RADDS, I flag the code with "#ifdef RADDS … #error ... #endif" blocks to draw attention to them.

        What would be ideal is if either the manufacturer of RADDS or a committed RADDS user took over maintenance of the RADDS build.

        Duet WiFi hardware designer and firmware engineer
        Please do not ask me for Duet support via PM or email, use the forum
        http://www.escher3d.com, https://miscsolutions.wordpress.com

        1 Reply Last reply Reply Quote 0
        • mb0
          mb0 last edited by

          i tried to contact a RADDS supplier but did not get a response so far. i've seen him posting about RRF on another forum so i thought he might be the right person to ask.

          for now i can try to get it working on one of my spare boards. since i never used eclipse for anything serious i'm wondering how i can change the build configuration to set the RADDS preproc define. setting "SAM3x_CoreNG" as active build config doesn't seem to define RADDS. i could set it manually but that can't be the right way to do it β„’.

          another thing i'm facing. eclipse (mars) manages to build the firmware but the ui part is not able to resolve the headers and everything is underlined red πŸ˜• this are the times i miss good'ol'makefiles and vi.

          1 Reply Last reply Reply Quote 0
          • dc42
            dc42 administrators last edited by

            @mb0:

            for now i can try to get it working on one of my spare boards. since i never used eclipse for anything serious i'm wondering how i can change the build configuration to set the RADDS preproc define. setting "SAM3x_CoreNG" as active build config doesn't seem to define RADDS. i could set it manually but that can't be the right way to do it β„’.

            I suggest you create new configurations of the CoreNG and RepRapFirmware projects (which is what I expect dcnewman did), copied from the SAM3X configurations bur with RADDS added to the preprocessor defines in the C and C++ tool settings. I will do this in my next release too.

            @mb0:

            another thing i'm facing. eclipse (mars) manages to build the firmware but the ui part is not able to resolve the headers and everything is underlined red πŸ˜• this are the times i miss good'ol'makefiles and vi.

            Right click on the project, then select Index->Rebuild from the menu. That should fix it.

            I am aware of two changes that will need to be made to build a RADDS version from the latest source code:

            1. The SD card interface has changed. In fact the Duet builds of RRF now support SD cards connected via SPI as well as via HSMCI, and that should make it much easier to support RADDS.

            2. The logical pin numbering and inverted/not inverted status for M42 and M280 commands needs to be defined for RADDS.

            Duet WiFi hardware designer and firmware engineer
            Please do not ask me for Duet support via PM or email, use the forum
            http://www.escher3d.com, https://miscsolutions.wordpress.com

            1 Reply Last reply Reply Quote 0
            • mb0
              mb0 last edited by

              thanks! re-indexing fixed the red.

              i grepped through dcnewmans coreng and rrf forks. he provides pin configurations in the /RADDS subdirectory.
              there are some changes to coreng as well. one is related to spi dual use or something. rest is more or less just jitter.
              there is one #ifdef which defines DUET if SAM3X is defined. this logic needs to be revised as well, but this is of
              course trivial.

              actually he introduced SCons as build system so i guess he didn't bother using eclipse as build platform. this is
              unnecessary.

              best is i make a fork on github and send a pull request. i think i can start working on it as soon as my dyzend stuff
              is working on the duetwifi (it is heating but auto-tune does not work so the pid is very slowly approaching temp,
              but then rock solid). i hope i manage to finish the printer by the end of next week.

              how is the esp connected to the duetwifi? would be awesome to bolt that onto radds as well.

              1 Reply Last reply Reply Quote 0
              • dc42
                dc42 administrators last edited by

                @mb0:

                how is the esp connected to the duetwifi? would be awesome to bolt that onto radds as well.

                On the Duet WiFi the high speed SPI interface on the SAM4E mcu is dedicated to communicating with the ESP so that we can achieve high data transfer speeds.

                Duet WiFi hardware designer and firmware engineer
                Please do not ask me for Duet support via PM or email, use the forum
                http://www.escher3d.com, https://miscsolutions.wordpress.com

                1 Reply Last reply Reply Quote 0
                • mb0
                  mb0 last edited by

                  i tried to make sense of eclipse project management and now i am wondering what the canonical way is to maintain the .cproject files. if noticed you added the RADDS build configuration to the firmware part. of course it is also needed in coreng. but unfortunately eclipse maintains paths to arduino gcc stuff in the same .cproject as it maintains build targets. unbelievable i now. thus i can't make clean git patches.

                  how can we colaborate without these stupid config conflicts? isn't there some kind of user profile overlay for cross toolchains?

                  1 Reply Last reply Reply Quote 0
                  • dc42
                    dc42 administrators last edited by

                    It's possible to declare build variables in Eclipse, so it might be possible to declare the path to gcc in a build variable and refer to that build variable in the .cproject file. I suspect that this may just move the problem to the .project file, but the .project file is rarely changed anyway.

                    I'm sorry I forgot to check in the changes to CoreNG. I'll check them in shortly.

                    Duet WiFi hardware designer and firmware engineer
                    Please do not ask me for Duet support via PM or email, use the forum
                    http://www.escher3d.com, https://miscsolutions.wordpress.com

                    1 Reply Last reply Reply Quote 0
                    • mb0
                      mb0 last edited by

                      nice thanks! when you're at it dcnewman defines the following in SConstruct build file:

                      [[python]]
                      if platform == 'radds':
                         env.Append( CCFLAGS = [
                               '-D__RADDS__=1',
                               '-DSD_MMC_SPI_MODE',
                               '-DSPI_PIN=77',
                               '-DSPI_CHAN=0',
                               '-DSD_SS=4',
                               '-DSD_DETECT_PIN=14',
                               '-DSD_DETECT_VAL=0',
                               '-DSD_DETECT_PIO_ID=ID_PIOD',
                               '-DUSE_SAM3X_DMAC=1',
                               '-DDMA_TIMEOUT_COMPUTE' ] )
                         if use_usb_combo:
                            env.Append( CCFLAGS = [
                               '-DUSE_USB_COMBO',
                      	 '-DUSB_DEVICE_VENDOR_ID=0x2341',
                      	 '-DUSB_DEVICE_PRODUCT_ID=0x003e',
                      	 '-DUSB_DEVICE_PRODUCT_NAME=\\"Arduino Due\\"',
                      	 '-DUSB_DEVICE_MANUFACTURE_NAME=\\"Arduino LLC\\"' ] )
                      
                      

                      you might want to add these flags as well to the RADDS build configuration. then i can keep a local copy of the .cproject and ignore it (hoping so).

                      1 Reply Last reply Reply Quote 0
                      • dc42
                        dc42 administrators last edited by

                        When Dan did the RADDS port, my fork didn't have code for accessing SD cards over SPI, but it does now. So it makes more sense to define those parameters (except for RADDS) in the Pins_RADDS file, just as they for the Duet and Duet WiFi. I already put most of them in Pins_RADDS,h except for the ones I didn't know the values for.

                        I think you should be able to use the CoreNG SAM3X build from my githib repo as-is for RADDS, except that you will need to change variant.cpp and variant.h to set up the pins appropriately.

                        Duet WiFi hardware designer and firmware engineer
                        Please do not ask me for Duet support via PM or email, use the forum
                        http://www.escher3d.com, https://miscsolutions.wordpress.com

                        1 Reply Last reply Reply Quote 0
                        • dc42
                          dc42 administrators last edited by

                          PS - I've updated my copy of CoreNG with Dan's copy of variant.cpp and variant.h, ma de a few other changes, and now I can actually build a RADDS version of CoreNG. I'll commit it to GitHub tomorrow when I have tested that I haven't broken anything in the Duet builds.

                          Duet WiFi hardware designer and firmware engineer
                          Please do not ask me for Duet support via PM or email, use the forum
                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                          1 Reply Last reply Reply Quote 0
                          • mb0
                            mb0 last edited by

                            thanks! i'll have a look at it when i'm back from very short vacation!

                            you are right after writing my post i realized that these defines should go into a header instead.

                            there are only a few other mentions of RADDS in coreng. One is in AnalogIn.cpp line 94:

                            [[c]]
                            #if SAM3XA
                            #ifdef __RADDS__
                            			if (ADC_TEMPERATURE_SENSOR != GetAdcChannel(channel))
                            #endif
                            				adc_enable_channel(ADC, GetAdcChannel(channel));
                            			if (GetAdcChannel(channel) == ADC_TEMPERATURE_SENSOR)
                            			{
                            				adc_enable_ts(ADC);
                            			}
                            #endif
                            
                            

                            1st i disklike nested #ifdef whatever, this makes everything unreadable. 2nd yoda style (ADC_TEMPERATURE_SENSOR != GetAdcChannel(channel) is a no no.
                            however i'm asking myself if this is actually needed because in any case it would call adc_enable_ts if needed. in the RADDS case not calling adc_enable_channel
                            before then. so either there is a bug when doing this when using the radds board or it is not neccessary and can be forgotten.

                            if your time permits you might want to look into SharedSpi.cpp as well. in dcnewmans fork are a 2 more #ifdef's for the RADDS case in lines 186 and 386

                            [[c]]
                            #if defined(USE_SAM3X_DMAC) && !defined(__RADDS__)
                            
                            

                            you know better than me if these are necessary or not facing the current implementation. Afaics, these were the only changes to the actual source which depend
                            on anything radds related. if so coreng would be radds safe after your changes.

                            i looked at the radds schematics and think that using a small adapter pcb the esp could also be connected to spi and the sdcard rewired to the hsmci port. thus
                            enabling high speed uploads there as well (preventing however the use of an lcd but not serial panel or whatever).

                            1 Reply Last reply Reply Quote 0
                            • dc42
                              dc42 administrators last edited by

                              I've checked everything in. The RADDS version builds but I haven't tested it.

                              The change to AnalogIn shouldn't be needed, because the RADDS version of RRF shouldn't ask to use the temperature sensor channel.

                              The changes to SharedSpi are because he got it working under DMA, but my build doesn't use DMA for the shared SPI. I think I left the sspi_start_transmit and sspi_start_receive functions there so that he could use them, but he seems to be calling spi_start_transmit and spi_start_receive instead, and I don't know where he defines those. You may find that it works OK without using DMA anyway, although using DMA would be preferable because on the RADDS all SD card access goes over SPI.

                              Duet WiFi hardware designer and firmware engineer
                              Please do not ask me for Duet support via PM or email, use the forum
                              http://www.escher3d.com, https://miscsolutions.wordpress.com

                              1 Reply Last reply Reply Quote 0
                              • mb0
                                mb0 last edited by

                                managed to build the RADDS flavour as well. There were some minor quirks (arm-*-objcopy was unable to locate the .elf because the path to it is wrong objcopy -binary /RepRapFirmware.elf /RepRapFirmware.bin) i checked the eclipse settings but they seamed correct. Anyway, did it by hand. Ahh and i switched from external make
                                to internal build tool in eclipse. Maybe you can change this setting as well in the project file to reduce one more error one can have. I copied the gcc from my arduino install
                                to the directory you have in the eclipse config, so in the future i don't have to touch this settings (at least under windows).

                                to use bossa (under Tools/Windows) you need to set the corresponding COM port to 1200 baud. This is done using the command
                                [c]mode comN:1200[/c] where N is the port number of the due. under linux you do [c]stty -F /dev/ttyACM0 1200[/c].

                                The target binary of RRF for RADDS should be renamed to RepRapFirmware-RADDS.bin for clarity.

                                After uploading the firmware to the due i could connect to it using pronterface and issue some commands. It seems that only the external SDCard
                                is working, maybe some configuration issue. I couldn't test the full deal because i ran out of time. Will do tomorrow. Just wanted to drop a quick note…

                                1 Reply Last reply Reply Quote 0
                                • dc42
                                  dc42 administrators last edited by

                                  @mb0:

                                  …. It seems that only the external SDCard is working, maybe some configuration issue....

                                  Does RADDS support 2 SD card sockets then? I only allowed for one in the Pins.h file.

                                  Duet WiFi hardware designer and firmware engineer
                                  Please do not ask me for Duet support via PM or email, use the forum
                                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                                  1 Reply Last reply Reply Quote 0
                                  • StephenRC
                                    StephenRC last edited by

                                    The RADDS has a microsd card slot and a SD extern connector that's used by the lcd sold for it.

                                    1 Reply Last reply Reply Quote 0
                                    • dc42
                                      dc42 administrators last edited by

                                      Ok so you need to change the SD cards section of thea RADDS pins.h file to define both cards. If the external card is working, then I suspect that the CS pin in the existing definition is for the external card however the CD pin may be for the internal card. You can use the M122 command to see the state of the CD pin, from that you can work out which one it is.

                                      Duet WiFi hardware designer and firmware engineer
                                      Please do not ask me for Duet support via PM or email, use the forum
                                      http://www.escher3d.com, https://miscsolutions.wordpress.com

                                      1 Reply Last reply Reply Quote 0
                                      • mb0
                                        mb0 last edited by

                                        thanks, there are two chip selects (CS0 and CS1), the CD (card detect) is shared between both.

                                        http://www.dr-henschke.de/LCD_Enc_SD_12.pdf

                                        i think the default config for RADDS should use the onboard SDCARD slot because one can not expect the lcd (which is not supported) to be connected.

                                        1 Reply Last reply Reply Quote 0
                                        • dc42
                                          dc42 administrators last edited by

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

                                          Duet WiFi hardware designer and firmware engineer
                                          Please do not ask me for Duet support via PM or email, use the forum
                                          http://www.escher3d.com, https://miscsolutions.wordpress.com

                                          1 Reply Last reply Reply Quote 0
                                          • bruce356
                                            bruce356 last edited by

                                            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

                                            1 Reply Last reply Reply Quote 0
                                            • mb0
                                              mb0 last edited by

                                              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.

                                              1 Reply Last reply Reply Quote 0
                                              • dc42
                                                dc42 administrators last edited by

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

                                                Duet WiFi hardware designer and firmware engineer
                                                Please do not ask me for Duet support via PM or email, use the forum
                                                http://www.escher3d.com, https://miscsolutions.wordpress.com

                                                1 Reply Last reply Reply Quote 0
                                                • dc42
                                                  dc42 administrators last edited by

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

                                                  Duet WiFi hardware designer and firmware engineer
                                                  Please do not ask me for Duet support via PM or email, use the forum
                                                  http://www.escher3d.com, https://miscsolutions.wordpress.com

                                                  1 Reply Last reply Reply Quote 0
                                                  • mb0
                                                    mb0 last edited by

                                                    my steps/mm @ 128x where

                                                    [[language]]
                                                    M92 X905.414787 Y905.414787 Z1280   ; set axis steps/mm
                                                    M92 E152                            ; set extruder 0 steps/mm
                                                    
                                                    
                                                    1 Reply Last reply Reply Quote 0
                                                    • mb0
                                                      mb0 last edited by

                                                      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.

                                                      1 Reply Last reply Reply Quote 0
                                                      • First post
                                                        Last post
                                                      Unless otherwise noted, all forum content is licensed under CC-BY-SA