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

    New beta firmware 2.02beta1

    Scheduled Pinned Locked Moved
    Firmware installation
    16
    75
    10.5k
    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.
    • dc42undefined
      dc42 administrators
      last edited by dc42

      I have just released this at https://github.com/dc42/RepRapFirmware/releases/tag/2.02beta1. This release introduces some major new features:

      • Dynamic Acceleration Adjustment (DAA). This is an experimental feature that adjusts the acceleration and deceleration of moves independently, to minimise excitation of mechanical resonance at a specified frequency, thereby reducing ringing. By default this feature is disabled. Use the M593 command to enable and configure it.
      • Control of laser power using the G1 S parameter when the machine is configured for use as a laser cutter or an engraver using M452.
      • Re-assignment of fans to different fan pins and to heater pins. Use the M106 A parameter to configure this. For example, if you want to use an air pump having a brushed DC motor instead of a normal print cooling fan, but the starting current surge of the pump is too high for the fan mosfets, you can use a spare heater output to drive the pump.
      • Direct configuration of TMC2660 and TMC2224 stepper driver off-time

      There are several other smaller feature additions and a number of bug fixes. See https://github.com/dc42/RepRapFirmware/blob/dev/WHATS_NEW.md for the full change list.

      Also included with this release is chrishamm's Duet Web Control 1.22.1.

      IMPORTANT! If you use this firmware to control a laser cutter or engraver, be sure to read the upgrade notes, and test it very carefully in case the laser turns on unexpectedly!

      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

      brunofportoundefined 1 Reply Last reply Reply Quote 1
      • burtoogleundefined
        burtoogle
        last edited by

        Just trying this out now and the file progress estimate is wildly different from the others. More often it's the layer time estimate that is different from the other two.

        0_1534150529905_Screenshot_2018-08-13_09-54-18.png

        1 Reply Last reply Reply Quote 0
        • burtoogleundefined
          burtoogle
          last edited by

          And now, a couple of minutes later...
          0_1534150650263_Screenshot_2018-08-13_09-57-05.png

          I know! you're using the same algorithm as was used in the Windows copy file utility, the estimated completion time in that used to go up and down like a yoyo!

          1 Reply Last reply Reply Quote 1
          • burtoogleundefined
            burtoogle
            last edited by

            The first test of the ringing reduction feature has completed. I used M593 F40 and printed exactly the same gcode as I did previously with no other changes to printer settings. I don't think I can get a photo good enough to show the differences so I will describe them:

            1 - the ringing downstream of the model's sharp corners is reduced quite well. It's still just about visible in some places.

            2 - the sharp edges could possibly be marginally fatter than before (like you see when using low acceleration) but that could be simply because the ringing is less visible the eye is drawn to the nearest artifact!

            3 - I get an overall impression that the result is slightly rougher than before. This is most noticeable on the corner of the model that is downstream of the numbers. Whereas that downstream corner was fairly straight before, it now has more kinks and bumps in it. The're tiny but visible. Also the surface area between the numbers and that corner does look rougher than before. It's almost as if the effector is suffering from some stiction and not travelling to the right position immediately after finishing the digits?

            So, a very promising first test. I need to experiment with the F value to see how critical that is.

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

              The print time estimation algorithm hasn't changed between 2.0 and 2.02beta1. The layer time estimate has always been the least accurate one, unless you are printing something like a cylinder or square tower that is basically the same all the way up. The one I find odd is the estimate based on file progress, which has gone from lower than the other two to much higher.

              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
              • wilrikerundefined
                wilriker
                last edited by

                First print running with the new firmware. I had a layer shift but that definitely is a mechanical problem I was hesitating to fix but I will have to disassemble my Y axis - again.

                Anyway everything looking good so far. I very much like the new M703 so thanks @chrishamm for this. I was replicating something similar manually but this builtin approach is very handy! 👍

                Also adjusted my config for M569 Fnnn and G0/1 Hnnn already. I like change! 👍

                @dc42 Not sure if you have overlooked it or if you are just too busy with upcoming TCT: I fixed my other PR according to your comment - I just did mess (up) with the regular PR update process. 😉

                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
                • burtoogleundefined
                  burtoogle
                  last edited by

                  Another test of the anti-ringing feature - interesting results.

                  0_1534162441585_IMG_20180813_131221263_HDR.jpg

                  The part on the right was printed recently using an earlier firmware. The part on the left is using M593 F40. The part is basically rectangular with a couple of holes as you can see. Noteworthy points are:

                  1 - the ringing downstream of the corner at the top of the picture is pretty much the same for both parts. The side upstream of the corner is long enough to let the nozzle reach the requested print speed.

                  2 - The ringing downstream of the holes is much reduced using M593. Presumably the nozzle velocity was still quite low as the hole isn't deep compared to the depth of the whole part.

                  3 - The leading edge of the holes is "fattened" using M593.

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

                    Thanks for sharing your results. It's interesting that the ringing downstream of the corners wasn't changed much, but the ringing around the hole was reduced.

                    Are you using pressure advance? It should help control the fattening around the hole.

                    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

                    burtoogleundefined 1 Reply Last reply Reply Quote 1
                    • burtoogleundefined
                      burtoogle @dc42
                      last edited by

                      @dc42 said in New beta firmware 2.02beta1:

                      Thanks for sharing your results. It's interesting that the ringing downstream of the corners wasn't changed much, but the ringing around the hole was reduced.

                      Are you using pressure advance? It should help control the fattening around the hole.

                      No, I have never managed to use pressure advance satisfactorily. I shall have another go sometime.

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

                        I have been thinking about how come the ringing wasn't reduced at the corners. Perhaps your acceleration limits were set too low to allow the optimum acceleration to be used there. What perimeter printing speed did you use, and what were your M201 X and Y acceleration limits? Did you have any M204 limit set? I assume you are using Cura, but I don't know whether Cura adds a M204 command to the G-code prologue the way some versions of Slic3r do.

                        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

                        burtoogleundefined 1 Reply Last reply Reply Quote 0
                        • burtoogleundefined
                          burtoogle @dc42
                          last edited by

                          @dc42 said in New beta firmware 2.02beta1:

                          I have been thinking about how come the ringing wasn't reduced at the corners. Perhaps your acceleration limits were set too low to allow the optimum acceleration to be used there. What perimeter printing speed did you use, and what were your M201 X and Y acceleration limits? Did you have any M204 limit set? I assume you are using Cura, but I don't know whether Cura adds a M204 command to the G-code prologue the way some versions of Slic3r do.

                          Hi David, all of the walls are being printed at 40 mm/S. No M204 in the gcode. Other params as shown here:

                          M201 X3000 Y3000 Z3000 E400		; Accelerations (mm/s^2)
                          M203 X18000 Y18000 Z18000 E1200		; Maximum speeds (mm/min)
                          M566 X300 Y300 Z300 E10			; Maximum instant speed changes
                          

                          This Kossel XL is fitted with a flex3drive extruder, hence the low extruder accel and jerk.

                          In the older print, the ringing downstream of the hole is visible for almost as far as the ringing that's downstream of the corner which implies that the ringing amplitudes are similar?

                          1 Reply Last reply Reply Quote 0
                          • burtoogleundefined
                            burtoogle
                            last edited by

                            I should add that the wall (not shown in image above) that precedes the corner at the top of the image is approx 50mm long so there's plenty of time for the nozzle to reach the commanded velocity (in the direction normal to the surface we are looking at). By contrast the holes are only about 4mm deep so I would expect the velocity to be quite low still by the time it reaches the edge.

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

                              At 40mm/sec and trying to cancel 40Hz ringing, the optimum acceleration at the corners should be 1600mm/sec^2 or less, depending on how much jerk you have configured. So if there is definitely no M104 command either in config.g or in the code generated by the slicer, that doesn't explain it. You can run M104 without parameters to check.

                              The interior perimeters of the holes may be being printed at a lower top speed if the holes do not go right through the cube, in which case the optimum acceleration when printing them will be lower.

                              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
                              • burtoogleundefined
                                burtoogle
                                last edited by

                                M204 query gives:

                                Maximum printing acceleration 10000.0, maximum travel acceleration 10000.0

                                1 Reply Last reply Reply Quote 0
                                • T3P3Tonyundefined
                                  T3P3Tony administrators
                                  last edited by

                                  @dc42 a question from a github conversation "Do you also adjust the laser pwm depending on x/y acceleration and deceleretion (like Grbl in M4 mode)?"

                                  https://github.com/LaserWeb/LaserWeb4/issues/500#issuecomment-412592499

                                  keyz182 created this issue in LaserWeb/LaserWeb4

                                  closed Duet Support #500

                                  www.duet3d.com

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

                                    @t3p3tony said in New beta firmware 2.02beta1:

                                    @dc42 a question from a github conversation "Do you also adjust the laser pwm depending on x/y acceleration and deceleretion (like Grbl in M4 mode)?"

                                    https://github.com/LaserWeb/LaserWeb4/issues/500#issuecomment-412592499

                                    Not yet, but I plan to do so before the 2.02 release. It does adjust the laser power if for any reason the actual top speed of the move is slower than the requested speed.

                                    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
                                    • mdfveronaundefined
                                      mdfverona
                                      last edited by

                                      Tried a few prints on the beta and was working well, but I just had a print stop half way through but claim to be compelted. The web interface makes it look like it was completed, but there is about 1/2 a file of gcode left. Only message in the console was:

                                      "Finished printing file 0:/gcodes/corners.gcode, print time was 2h 48m"

                                      I downloaded the gcode file from the web interface to check and it seems okay and a simulator has the full print.

                                      Here is the gcode downloaded from the web interface: https://drive.google.com/open?id=1_dRimJ3CkYL3QDAyAvLwodNUpNk8j5s7

                                      Anything else I should look at?

                                      M122 right after it happened is:

                                      M122
                                      === Diagnostics ===
                                      RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02beta1(RTOS) running on Duet WiFi 1.02 or later + DueX2
                                      Board ID: 08DGM-9568A-F23SD-6J9DL-3SJ6R-K9RRH
                                      Used output buffers: 3 of 20 (14 max)
                                      === RTOS ===
                                      Static ram: 28476
                                      Dynamic ram: 98404 of which 12 recycled
                                      Exception stack ram used: 532
                                      Never used ram: 3648
                                      Tasks: NETWORK(ready,328) HEAT(blocked,1192) MAIN(running,1660)
                                      Owned mutexes:
                                      === Platform ===
                                      Last reset 07:21:25 ago, cause: software
                                      Last software reset at 2018-08-11 18:28, reason: User, spinning module GCodes, available RAM 5740 bytes (slot 2)
                                      Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0041f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
                                      Error status: 0
                                      Free file entries: 10
                                      SD card 0 detected, interface speed: 20.0MBytes/sec
                                      SD card longest block write time: 94.0ms, max retries 0
                                      MCU temperature: min 43.0, current 43.2, max 56.1
                                      Supply voltage: min 23.8, current 24.0, max 24.3, under voltage events: 0, over voltage events: 0
                                      Driver 0: standstill, SG min/max 0/236
                                      Driver 1: standstill, SG min/max 0/257
                                      Driver 2: standstill, SG min/max 0/1023
                                      Driver 3: standstill, SG min/max 0/255
                                      Driver 4: standstill, SG min/max 0/271
                                      Driver 5: standstill, SG min/max 0/1023
                                      Driver 6: standstill, SG min/max 0/1023
                                      Expansion motor(s) stall indication: yes
                                      Date/time: 2018-08-13 17:02:34
                                      Slowest loop: 132.81ms; fastest: 0.07ms
                                      === Move ===
                                      Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 145, MaxWait: 2403580ms, Underruns: 0, 0
                                      Scheduled moves: 0, completed moves: 0
                                      Bed compensation in use: mesh
                                      Bed probe heights: -0.003 -0.003 -0.006 0.003 0.000
                                      === Heat ===
                                      Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
                                      Heater 0 is on, I-accum = 0.3
                                      Heater 1 is on, I-accum = 0.2
                                      === GCodes ===
                                      Segments left: 0
                                      Stack records: 4 allocated, 0 in use
                                      Movement lock held by null
                                      http is idle in state(s) 0
                                      telnet is idle in state(s) 0
                                      file is idle in state(s) 0
                                      serial is idle in state(s) 0
                                      aux is idle in state(s) 0
                                      daemon is idle in state(s) 0
                                      queue is idle in state(s) 0
                                      autopause is idle in state(s) 0
                                      Code queue is empty.
                                      === Network ===
                                      Slowest loop: 125.06ms; fastest: 0.01ms
                                      Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
                                      HTTP sessions: 1 of 8

                                      • WiFi -
                                        Network state is running
                                        WiFi module is connected to access point
                                        Failed messages: pending 0, notready 0, noresp 0
                                        WiFi firmware version 1.21
                                        WiFi MAC address 2c:3a:e8:0b:17:81
                                        WiFi Vcc 3.45, reset reason Turned on by main processor
                                        WiFi flash size 4194304, free heap 16600
                                        WiFi IP address 192.168.86.38
                                        WiFi signal strength -45dBm, reconnections 0, sleep mode modem
                                        Socket states: 0 0 0 0 0 0 0 0
                                        === Expansion ===
                                        DueX I2C errors 0
                                      1 Reply Last reply Reply Quote 0
                                      • dc42undefined
                                        dc42 administrators
                                        last edited by

                                        Your M122 report is clean and I didn't spot anything wrong with the GCode 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
                                        • brunofportoundefined
                                          brunofporto @dc42
                                          last edited by

                                          @dc42 said in New beta firmware 2.02beta1:

                                          Dynamic Acceleration Adjustment (DAA). This is an experimental feature that adjusts the acceleration and deceleration of moves independently, to minimise excitation of mechanical resonance at a specified frequency, thereby reducing ringing. By default this feature is disabled. Use the M593 command to enable and configure it.

                                          That is just wonderful....

                                          Please, does anyone have a good methodology to tune base jerk and acceleration settings?

                                          Phaedruxundefined 1 Reply Last reply Reply Quote 0
                                          • Phaedruxundefined
                                            Phaedrux Moderator
                                            last edited by

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