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

    New RepRapFirmware 3.0 early beta

    Scheduled Pinned Locked Moved
    Firmware wishlist
    14
    79
    8.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.
    • wilrikerundefined
      wilriker
      last edited by wilriker

      (I think) I found a bug with PID tuning. When I try to run M303 Hn Snn it will always give me

      Error: Heater is not ready to perform PID auto-tuning
      

      I tracked it down to Heater.cpp:CheckGood() where it says

      return GetMode() == HeaterMode::fault && CheckProtection();
      

      and I think the first comparison should be != or the heater is only good it if actually is in fault state. 😁

      P.S.: Recompiled with != and at least it started the PID tuning - not sure if it will stop heating before the thermal cut-off will activate though, yet. 😂

      EDIT 2:
      I more or less successfully ran a PID tune for my heated bed. But: in the end it gave me

      Warning: Auto tune of heater 0 failed due to bad curve fit (A=238.4, C=854.2, D=0.5)
      

      This was the misleading result of Heater.cpp::SetModel() returning GCodeResult::warning due to the "heater appears to be overpowered" fact but LocalHeater::CalculateModel() only checks for GCodeResult::ok or anything else and in the latter case (including the GCodeResult::warning) it will issue the above warning message to DWC.

      And one more EDIT: it did not output the

      Warning: heater 0 appears to be over-powered. If left on at full power, its temperature is predicted to reach 263C.
      

      as part of the Auto-Tuning procedure.

      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

      dc42undefined 1 Reply Last reply Reply Quote 0
      • smoki3undefined
        smoki3 @dc42
        last edited by smoki3

        @dc42 said in New RepRapFirmware 3.0 early beta:

        If you read the firmware update motes for 2.03 you will see that tool offsets are now applied during tfree and tpost (but still not in tpre). Does that explain the issue? You can use G53 to prevent tool offsets being applied.

        That change I now, as you can see in my script they already include G53 commands in the tfree.g

        But the problem is:

        Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
        Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)

        What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
        But it is also moving in the Y axis.

        For me it sound like more that it is a bug of this change:

        What new:

        Restore points (created by G60 and created automatically at the start of a pause or a tool change) now have their coordinates stored independently of any workplace offsets. So if you create a restore point and then change the workplace offsets, when you go back to the restore point it will go back to the same machine position regardless of the change in workplace offsets.
        

        It seem like it is restore the old positions from the tool coordinate system during a tool change. Because also tries to restore the Z position during the tool change.

        Means if you positioned the tool with G53 Y165 in the machine coordinate system then the tool stays at Y210 (depending on the tool offset) in the workplace coordinate system. Then you drop the tool! With the next movement of the tpre.g it tries to move with the machine cordnatesystem to Y210. Which is wrong at this point because for the tpre.g no tool offset is applied and it should just move in the axis you are calling.

        There is a workaround for this issue:
        If you put in the tpre.g the same command (G53 G1 Y165 F25000) on the first place then the printer is just restoring the Z position and the you can start with the tool change

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

          @wilriker said in New RepRapFirmware 3.0 early beta:

          I tracked it down to Heater.cpp:CheckGood() where it says

          return GetMode() == HeaterMode::fault && CheckProtection();
          

          and I think the first comparison should be != or the heater is only good it if actually is in fault state. 😁

          Thanks, I've corrected the source.

          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

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

            @smoki3 said in New RepRapFirmware 3.0 early beta:

            That change I now, as you can see in my script they already include G53 commands in the tfree.g
            But the problem is:
            Look at the last movement of my tfree.g: It move to G53 Y165 (no tool offset)
            Then the script is finished. Then it starts with the G1 X76 in the tpre (still no tool offset)
            What I then expect is that the printer is just moving form G53 X0 (from the tfree.g) to the G1 X76.
            But it is also moving in the Y axis.
            For me it sound like more that it is a bug of this change:

            Please clarify. Are you saying that the G1 X76 command in tpre causes a move in the Y direction too? If so then this is certainly a bug. The coordinates stored in the tool change restore point should only be relevant at the end of the entire tool change 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

            smoki3undefined 1 Reply Last reply Reply Quote 0
            • smoki3undefined
              smoki3 @dc42
              last edited by smoki3

              @dc42 Yes the G1 X76 also do a move in the Y direction. Also the Z axis is moving.

              It restores the coordinates where the nozzle was before. The reference point of the printer tries to reach the point where the nozzle was before.

              The only way actually can avoid this behavior is to put also a G53 G1 Y165 into the tpre.g script. Then only a Z move is done (but also this movement shouldn't be done).

              1 Reply Last reply Reply Quote 0
              • wilrikerundefined
                wilriker @dc42
                last edited by

                @dc42 said in New RepRapFirmware 3.0 early beta:

                Thanks, I've corrected the source.

                Have you also seen my edit if the post regarding misleading message output?

                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
                • smoki3undefined
                  smoki3
                  last edited by smoki3

                  @dc42 I switched now back to 2.02.

                  Here is everything fine. Also 2.04 and 2.03 has this issue. I tried also the old v3 build from the dropbox. Here also everthing is fine.

                  I assume that it has something to do with the commits from May 25th.
                  I will later do a build an try it out

                  1 Reply Last reply Reply Quote 1
                  • smoki3undefined
                    smoki3
                    last edited by

                    I was trying to build a older build but it seems that it's necessary to build wifisocketserver. But I don't geht it to build in my mac

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

                      This is now on my list to investigate, and fix in 2.04 if I can confirm the problem.

                      @smoki3 said in New RepRapFirmware 3.0 early beta:

                      I was trying to build a older build but it seems that it's necessary to build wifisocketserver. But I don't get it to build in my mac

                      You don't need to build wifisocketserver, you just need the include directory in it to be present in the Eclipse workspace.

                      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

                      smoki3undefined 1 Reply Last reply Reply Quote 0
                      • gtj0undefined
                        gtj0
                        last edited by

                        @dc42 using the tip of the current RRF v3-dev...

                        Sent: M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 C0 R4700
                        Sent: M308 S0
                        Sensor 0 type Thermistor using pin bedtemp, last error: sensor not ready, T:100000.0 B:4138.0 C:0.00e+0 R:4700.0 L:0 H:0
                        
                        Sent: M308 S2 Y"thermistor" P"e1temp" A"HotEnd" T100000 B4725 C7.06e-8
                        Sent: M308 S2
                        Sensor 2 (HotEnd) type Thermistor using pin e1temp, last error: sensor not ready, T:100000.0 B:4725.0 C:7.06e-8 R:4700.0 L:0 H:0
                        

                        Is there something wrong with this M308 syntax? All temps are 2000.0

                        dc42undefined 1 Reply Last reply Reply Quote 0
                        • smoki3undefined
                          smoki3 @dc42
                          last edited by

                          @dc42 said in New RepRapFirmware 3.0 early beta:

                          This is now on my list to investigate, and fix in 2.04 if I can confirm the problem.

                          @smoki3 said in New RepRapFirmware 3.0 early beta:

                          I was trying to build a older build but it seems that it's necessary to build wifisocketserver. But I don't get it to build in my mac

                          You don't need to build wifisocketserver, you just need the include directory in it to be present in the Eclipse workspace.

                          I always get this when I trying to compile from a older source. If I try the actual branch everything is fine

                          ../src/Networking/ESP8266WiFi/WiFiInterface.cpp:1857:10: error: 'APIN_SPI_MISO' was not declared in this scope
                          
                          make: *** [src/Networking/ESP8266WiFi/WiFiInterface.o] Error 1
                          
                          wilrikerundefined 1 Reply Last reply Reply Quote 0
                          • wilrikerundefined
                            wilriker @smoki3
                            last edited by

                            @smoki3 You have to make sure that all of the repositories are at about the same point in time to compile. Most of the times having all repos except RepRapFirmware at the latest commit works but every once in a while there are bigger changes across repos (as in the case you show where some constants had been renamed) that require you to revert the according repo (I think it is CoreNG in this case) to a commit prior to the breaking change.

                            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

                            dc42undefined 1 Reply Last reply Reply Quote 1
                            • smoki3undefined
                              smoki3
                              last edited by

                              @dc42
                              I have done some further testing:

                              If I put not only "G1 X76" at the beginning of the tpre rather a "G1 X76 Y165" (Y165 same Y position as tfree) then just the X axis and Z axis is moving and Y axis stays as it should. Anyway the Z axis shouldnt move at this point.

                              So if you don't but every single axis into the first command of tfree it will restore the old position of the tool head

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

                                @wilriker said in New RepRapFirmware 3.0 early beta:

                                @smoki3 You have to make sure that all of the repositories are at about the same point in time to compile. Most of the times having all repos except RepRapFirmware at the latest commit works but every once in a while there are bigger changes across repos (as in the case you show where some constants had been renamed) that require you to revert the according repo (I think it is CoreNG in this case) to a commit prior to the breaking change.

                                That's right, the APIN_SPI_MISO message means that the RepRapFirmware project is not in sync with CoreNG.

                                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
                                • dc42undefined
                                  dc42 administrators @gtj0
                                  last edited by

                                  @gtj0 said in New RepRapFirmware 3.0 early beta:

                                  @dc42 using the tip of the current RRF v3-dev...

                                  Sent: M308 S0 P"bedtemp" Y"thermistor" T100000 B4138 C0 R4700
                                  Sent: M308 S0
                                  Sensor 0 type Thermistor using pin bedtemp, last error: sensor not ready, T:100000.0 B:4138.0 C:0.00e+0 R:4700.0 L:0 H:0
                                  
                                  Sent: M308 S2 Y"thermistor" P"e1temp" A"HotEnd" T100000 B4725 C7.06e-8
                                  Sent: M308 S2
                                  Sensor 2 (HotEnd) type Thermistor using pin e1temp, last error: sensor not ready, T:100000.0 B:4725.0 C:7.06e-8 R:4700.0 L:0 H:0
                                  

                                  Is there something wrong with this M308 syntax? All temps are 2000.0

                                  There are some reported bugs in the current v3-dev. In particular, you need a quarter second delay between creating a sensor using M308 and creating a heater that uses it. I also have a report that configuring thermistors using M308 doesn't work (at least on Duet 3), which I am about to investigate.

                                  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

                                  gtj0undefined 1 Reply Last reply Reply Quote 0
                                  • gtj0undefined
                                    gtj0 @dc42
                                    last edited by

                                    @dc42 said in New RepRapFirmware 3.0 early beta:

                                    There are some reported bugs in the current v3-dev. In particular, you need a quarter second delay between creating a sensor using M308 and creating a heater that uses it. I also have a report that configuring thermistors using M308 doesn't work (at least on Duet 3), which I am about to investigate.

                                    No problem. Thanks!
                                    If there's anything I can do to help, let me know. Specific bugs needing to be squashed, testing, etc.

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

                                      I've just committed new source code to fix a number of RRF3 bugs, including issues with temperature readings.

                                      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

                                      gtj0undefined 1 Reply Last reply Reply Quote 0
                                      • gtj0undefined
                                        gtj0 @dc42
                                        last edited by

                                        @dc42 said in New RepRapFirmware 3.0 early beta:

                                        I've just committed new source code to fix a number of RRF3 bugs, including issues with temperature readings.

                                        Yep, temps now read correctly. Thanks!

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

                                          @smoki3 said in New RepRapFirmware 3.0 early beta:

                                          @dc42
                                          It was definitely not like this on 2.02 and the older 3.0.

                                          And its a really wired behaviour. Because I use:

                                          ; tfree0.g
                                          ; called when tool 0 is freed
                                          ;
                                          ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
                                          G91
                                          G1 Z10 F7200
                                          G90
                                          G53 G1 X0 F25000 ;XPOS
                                          G53 G1 Y190
                                          G53 G1 Y195 F5000
                                          M400
                                          M98 P"/macros/Toolhead/1. Toolhead unlock"
                                          G4 P320
                                          G53 G1 Y207 F5000
                                          M400
                                          G53 G1 Y165 F25000
                                          M400
                                          
                                          ; tpre1.g
                                          ; called before tool 0 is selected
                                          ;
                                          ; generated by RepRapFirmware Configuration Tool on Wed Sep 19 2018 21:12:53 GMT+0200 (Mitteleuropäische Sommerzeit)
                                          G1 X76 F25000
                                          M400
                                          G1 Y192
                                          M400
                                          M98 P"/macros/Toolhead/1. Toolhead unlock"
                                          G4 P400
                                          G1 Y207 F5000
                                          M116 P3
                                          M400
                                          M98 P"/macros/Toolhead/2. Toolhead lock"
                                          G4 P260
                                          G1 Y150 F15000
                                          

                                          The I only expect that only a X movement is done while the start of the tpre1.g but it first moves in X and Y.

                                          @smoki3, I am looking into this but I need your config.g file, also the toolhead unlock files that you call from the tool change files.

                                          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

                                          smoki3undefined 1 Reply Last reply Reply Quote 0
                                          • smoki3undefined
                                            smoki3
                                            last edited by

                                            @dc42 I will provide it until next week. I am on vacation

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