• Tags
  • Documentation
  • Order
  • Register
  • Login
Duet3D Logo Duet3D
  • Tags
  • Documentation
  • Order
  • Register
  • Login

RepRapFirmware 2.03RC4 available

Scheduled Pinned Locked Moved
Firmware installation
10
25
2.9k
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.
  • undefined
    oliof
    last edited by oliof 29 May 2019, 21:13

    Applied cleanly on the CR-20 (cartesian). Starting a test print right now. Compared to 2.03RC2, filament length from gcode generated with PrusaSlicer is shown again (as was discussed elsewhere).

    <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

    1 Reply Last reply Reply Quote 0
    • undefined
      oliof
      last edited by 30 May 2019, 03:43

      Multi hour print completed without issue on a simple Cartesian printer.

      <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

      1 Reply Last reply Reply Quote 0
      • undefined
        avaradus
        last edited by 30 May 2019, 11:01

        Problem with DWC lost connection is stil there
        https://forum.duet3d.com/topic/10164/duet-wifi-lost-web-connection/10

        1 Reply Last reply Reply Quote 0
        • undefined
          boldnuts
          last edited by 30 May 2019, 11:26

          Ran several long print job's on both my Delta and Cartesian printer's with no issue's to report

          1 Reply Last reply Reply Quote 0
          • undefined
            Bravojul
            last edited by 30 May 2019, 20:20

            I have tried 2.03RC3 with new PrusaSlicer 2.0. Filament used is not recognized. PrusaSlicer now output:

            ; filament used [mm] = 3363.4
            ; filament used [cm3] = 7.9

            It works if I edit the file before sending it to the printer. I change to :

            ; filament used = 3363.4mm
            ; filament used [cm3] = 7.9

            undefined undefined 2 Replies Last reply 30 May 2019, 21:54 Reply Quote 0
            • undefined
              Phaedrux Moderator @Bravojul
              last edited by 30 May 2019, 21:54

              @bravojul said in RepRapFirmware 2.03RC4 available:

              I have tried 2.03RC3 with new PrusaSlicer 2.0.

              But have you tried 2.03RC4?

              Z-Bot CoreXY Build | Thingiverse Profile

              1 Reply Last reply Reply Quote 0
              • undefined
                oliof
                last edited by 31 May 2019, 03:06

                I can confirm that PrusaSlicer filament length is recognized by RC4

                <>RatRig V-Minion Fly Super5Pro RRF<> V-Core 3.1 IDEX k*****r <> RatRig V-Minion SKR 2 Marlin<>

                1 Reply Last reply Reply Quote 0
                • undefined
                  dc42 administrators @Bravojul
                  last edited by 31 May 2019, 08:14

                  @bravojul said in RepRapFirmware 2.03RC4 available:

                  I have tried 2.03RC3 with new PrusaSlicer 2.0. Filament used is not recognized. PrusaSlicer now output:

                  ; filament used [mm] = 3363.4
                  ; filament used [cm3] = 7.9

                  It works if I edit the file before sending it to the printer. I change to :

                  ; filament used = 3363.4mm
                  ; filament used [cm3] = 7.9

                  As @Phaedrux says, please test again using 2.03RC4.

                  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
                  • undefined
                    Bravojul
                    last edited by 31 May 2019, 11:44

                    yes it works with RC4. Thanks

                    1 Reply Last reply Reply Quote 0
                    • undefined
                      wilriker
                      last edited by 31 May 2019, 17:14

                      Print successful but there was something strange when it entered stop.g. It seems as if the motors were reduced to idle current. They sounded vastly different and the Y motor even stalled (it needs slightly more than idle current to move properly). Upping the idle current and trying again let the motors move normal.

                      Manuel
                      Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                      with probably always latest firmware/DWC (incl. betas or self-compiled)
                      My Tool Collection

                      1 Reply Last reply Reply Quote 0
                      • undefined
                        dc42 administrators
                        last edited by 31 May 2019, 19:24

                        RRF sets the motors to idle current when a print from SD card terminates. I don't remember whether it does this before or after stop.g is run. I will check tomorrow.

                        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

                        undefined 1 Reply Last reply 31 May 2019, 19:33 Reply Quote 0
                        • undefined
                          wilriker @dc42
                          last edited by 31 May 2019, 19:33

                          @dc42 Thanks.
                          Just to clarify: this behavior is new with RC4 so probably when fixing the issue with M0 H1 something got switched in the order of execution.

                          Manuel
                          Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                          with probably always latest firmware/DWC (incl. betas or self-compiled)
                          My Tool Collection

                          undefined 1 Reply Last reply 1 Jun 2019, 10:44 Reply Quote 0
                          • undefined
                            dc42 administrators @wilriker
                            last edited by dc42 6 Jan 2019, 15:45 1 Jun 2019, 10:44

                            @wilriker said in RepRapFirmware 2.03RC4 available:

                            @dc42 Thanks.
                            Just to clarify: this behavior is new with RC4 so probably when fixing the issue with M0 H1 something got switched in the order of execution.

                            I just checked the code. The motors are set to idle current after stop.g has been run. So no change there.

                            Of course, if the machine has been idle for more than the idle time when stop.g is run or within stop.g (perhaps because of a command to wait for something to cool down), then ordinary idle current reduction will kick in. But as soon as you move a motor, normal current should be restored.

                            Edit: I've realised what might be happening, and I will fix it in the 2.03 release. Meanwhile, as a workaround, try adding a M400 command at the end of stop.g.

                            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

                            undefined 2 Replies Last reply 1 Jun 2019, 17:57 Reply Quote 0
                            • undefined
                              wilriker @dc42
                              last edited by 1 Jun 2019, 17:57

                              @dc42 Thanks. I'll try that - and I think I also how have a clue what's happening. 🙂

                              Manuel
                              Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                              with probably always latest firmware/DWC (incl. betas or self-compiled)
                              My Tool Collection

                              1 Reply Last reply Reply Quote 0
                              • undefined
                                Caveman
                                last edited by 2 Jun 2019, 10:51

                                Bed mesh level still the same issue as before. Z0 is all over the place. 2.02 works perfectly???

                                undefined 1 Reply Last reply 2 Jun 2019, 12:45 Reply Quote 0
                                • undefined
                                  dc42 administrators @Caveman
                                  last edited by dc42 6 Feb 2019, 16:48 2 Jun 2019, 12:45

                                  @caveman said in RepRapFirmware 2.03RC4 available:

                                  Bed mesh level still the same issue as before. Z0 is all over the place. 2.02 works perfectly???

                                  Is this with 2.03RC4 ? Are you getting any warning messages on the console?

                                  Please provide a sequence that reproduces this issue for you, along with all the files needed to reproduce this (config,g, homing files, bed.g if used, and a very short GCode file to print if printing a file has to be part of the sequence).

                                  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
                                  • undefined
                                    Caveman
                                    last edited by 2 Jun 2019, 19:47

                                    Whenever I have a wrong Z0 I get the message that the map has a substantial Z offset.....

                                    Sometimes I have a proper Z0

                                    0_1559504666357_2.03RC4meshleveltry_1.jpg 0_1559504682780_Error message_2.03RC4 meshbedlevel.jpg 0_1559504698147_@.03RC4meshbedleveltry_2.jpg

                                    undefined 1 Reply Last reply 2 Jun 2019, 22:31 Reply Quote 0
                                    • undefined
                                      Phaedrux Moderator @Caveman
                                      last edited by 2 Jun 2019, 22:31

                                      @caveman How are you homing Z and how are you establishing Z0 before running the mesh compensation routine?

                                      Z-Bot CoreXY Build | Thingiverse Profile

                                      1 Reply Last reply Reply Quote 0
                                      • undefined
                                        Gone2Far
                                        last edited by 2 Jun 2019, 23:55

                                        Had some odd leveling behavior on my delta.

                                        Had a quite hard time getting G32 to converge on a particular height, but finally did. Then noticed several aborted probing points when running G29, followed by reports of 4.x mm max height error. After increasing the force needed by the smart effector from default to 128, got a kinda good height map. Now I have to edit the deflection setting in config.g--I had to add +0.15 mm baby step to get first layer correct. Everything was working quite well prior to upgrade.

                                        Original Prusa i3 MK2S
                                        Large Kossel Homebrew

                                        1 Reply Last reply Reply Quote 0
                                        • undefined
                                          wilriker @dc42
                                          last edited by 4 Jun 2019, 09:05

                                          @dc42 said in RepRapFirmware 2.03RC4 available:

                                          Meanwhile, as a workaround, try adding a M400 command at the end of stop.g.

                                          I can now confirm that this solves the issue.

                                          Manuel
                                          Duet 3 6HC (v0.6) with RPi 4B on a custom Cartesian
                                          with probably always latest firmware/DWC (incl. betas or self-compiled)
                                          My Tool Collection

                                          undefined 1 Reply Last reply 5 Jun 2019, 16:30 Reply Quote 0
                                          11 out of 25
                                          • First post
                                            11/25
                                            Last post
                                          Unless otherwise noted, all forum content is licensed under CC-BY-SA