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

G30 stop values increasing each time

Scheduled Pinned Locked Moved
General Discussion
7
29
1.6k
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
    dc42 administrators @CarlosR
    last edited by 27 Oct 2021, 14:21

    @carlosr said in G30 stop values increasing each time:

    If we run a G30 to stablish the Z datum, and then multiple G30 S-1, each time the reported stop height value increases (0.010 -> 0.030 -> 0.040 -> 0.050-> 0.080 -> ... -> 0.120 ...). Sometimes the value decreases a bit (0.040 -> 0.030), but the tendency is to increase. If we run again G30, the values seem to be reset and they start again increasing from 0.010 when multiple G30 S-1 sent.

    There are two know reason why this can happen:

    1. If your Z axis motor is driven by a CAN-connected expansion board. See https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations?revisionid=HEAD#Section_Temporary_limitations.

    2. If you use a high probing speed and have a high Z steps/mm.

    In the first case, the additional latency of the CAN bus can delay stopping the Z motor by a few milliseconds after the probe triggers, so that it overshoots. The increase in reported stop height in this case would be a multiple of 1 microstep. In the second case, when the probe triggers and the Z motor is commanded to stop, it could skip steps because of inertia. In this case the increase in reported stop height would be a multiple of 4 full steps.

    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 27 Oct 2021, 15:53 Reply Quote 2
    • undefined
      Marcossf @dc42
      last edited by Marcossf 27 Oct 2021, 15:53

      @dc42 said in G30 stop values increasing each time:

      There are two know reason why this can happen:

      1. If your Z axis motor is driven by a CAN-connected expansion board. See https://duet3d.dozuki.com/Wiki/Duet_3_firmware_configuration_limitations?revisionid=HEAD#Section_Temporary_limitations.

      2. If you use a high probing speed and have a high Z steps/mm.

      In the first case, the additional latency of the CAN bus can delay stopping the Z motor by a few milliseconds after the probe triggers, so that it overshoots. The increase in reported stop height in this case would be a multiple of 1 microstep. In the second case, when the probe triggers and the Z motor is commanded to stop, it could skip steps because of inertia. In this case the increase in reported stop height would be a multiple of 4 full steps.

      We use 1XD boards to drive an absolute encoder closed loop stepper motor (Oriental Motor AZM48AK with a pulse driver AZD-K connected to step/dir in the 1XD board). They are ultra precise.

      There isn't any inertia in Z motor motion as it is controlled in the encoder.
      We can calibrate the external driver to get exact movement for each step (up to 10000 step/rev resolution available) and we did same steps on the motor driver than RRF configuration.

      So I think is the limitation you said:

      Due to CAN latency the motors connected to expansion boards may slightly overshoot the position at which the endstop or Z probe was triggered. This would not usually matter for an endstop switch, but it does mean that if the Z motor(s) is/are connected to an expansion board then repeated probing with a Z probe (e.g. for mesh bed compensation) is not advisable. This will be fixed in a future release
      

      Did you know if that problem which it could be fixed quite soon?

      We will do some tests modifying the step/microstep logic into the external driver software and look for any hint to minimize the problem.

      With normal axis movements we obtain a ±0.001mm repetability and positioning, so we thought the Z probe could achieve same precision given from the axis movement, limited by the optoendstop resolution ±0.0025mm, enough to get a very precise mesh.

      We did not take into account the possible delay of the CANbus<

      EDIT: In fact, the opto endstop is connected to the 6HC board, and the Z motor is in a 1XD board, so the endstop isn't connected to the same board it drives the steps for that axis.

      undefined 1 Reply Last reply 27 Oct 2021, 16:33 Reply Quote 0
      • undefined
        Marcossf @gloomyandy
        last edited by 27 Oct 2021, 15:59

        @gloomyandy said in G30 stop values increasing each time:

        I'm not sure that any comparison with Marlin is valid unless it is made using the same printer hardware (your colleague stated above that this was not the case). Given what has been described so far I'd be checking to make sure there is not either some loss of steps in the Z axis or other mechanical issue.

        Same autolevel hardware used in a printer driven by Marlin (SKR Pro + TMC5160) to check if there's any HW deviation.
        It's not driven by the same Z stepper motor/driver obviously.

        1 Reply Last reply Reply Quote 0
        • undefined
          Marcossf @T3P3Tony
          last edited by 27 Oct 2021, 16:06

          @t3p3tony said in G30 stop values increasing each time:

          when you are running these tests are you deploying and retracting the probe in between each test or leaving it deployed?

          Retracting and deploying it, except when G29 S0 who it does all the mesh probing deployed. We tried several speeds and distances but the patterns was, as @CarlosR said, incremental values.

          We do some other test after David's prompt about CAN delays in the encoder driver side. We are seriously concerned if this problem couldn't be addresable.

          1 Reply Last reply Reply Quote 0
          • undefined
            dc42 administrators @Marcossf
            last edited by 27 Oct 2021, 16:33

            @marcossf we had scheduled to fix this limitation in release 3.5, but I'll se if it can be brought forward to 3.4.

            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 27 Oct 2021, 17:43 Reply Quote 2
            • undefined
              Marcossf @dc42
              last edited by 27 Oct 2021, 17:43

              @dc42 It would be awesome.

              This prototype printer is our biggest project so far, in we invest tons of money and time. We would like have an stable version soon comprised all the features needed, since we are near to end right now.

              1 Reply Last reply Reply Quote 0
              • undefined
                Marcossf @dc42
                last edited by 16 Dec 2021, 08:48

                @dc42 Hi David.

                Any news about correct the CAN delays limitation?
                We can't use the mesh bed leveling in our printer because this issue.

                We drive all our axis with 1XD boards connected by CANbus, and driven by absolute encoder closed loop motors (Oriental Motor AZD-K drivers and motors). So we think all the problems regarding probing (located in Z axis) are caused by this timing problem.

                undefined 1 Reply Last reply 30 Dec 2021, 18:15 Reply Quote 0
                • undefined
                  dc42 administrators @Marcossf
                  last edited by dc42 30 Dec 2021, 18:15

                  Hi @marcossf, I have put preliminary firmware that resolves this issue at https://www.dropbox.com/sh/cx760ysonlzzkjd/AACfsVfX4olHipuqmbWut5EKa?dl=0. Please test this firmware with care because I have only tested it using Duet 3 MB6HC + EXP3HC (the Z motor was connected to the EXP3HC).

                  If you are running your Duet with an attached Raspberry Pi then you must upgrade to RRF 3.4.0beta7 from the package server before you use these files.

                  You may also be interested in our forthcoming 6XD board, which is similar in many ways to the 6HC board but has ports for connecting external drivers instead of having internal drivers.

                  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 undefined 2 Replies Last reply 31 Dec 2021, 12:14 Reply Quote 1
                  • undefined
                    Marcossf @dc42
                    last edited by 31 Dec 2021, 12:14

                    @dc42 OK, we will test it very soon. Thanks!

                    The 6XD looks like it will be ideal, for us at least, as the internal motor drivers have never been used in the 6HC. Hopefully I'll be able to buy and test one soon!

                    undefined 1 Reply Last reply 5 Jan 2022, 14:09 Reply Quote 0
                    • undefined
                      dc42 administrators @Marcossf
                      last edited by 5 Jan 2022, 14:09

                      @marcossf have you had a chance to test this yet?

                      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 7 Jan 2022, 09:20 Reply Quote 0
                      • undefined
                        Marcossf @dc42
                        last edited by 7 Jan 2022, 09:20

                        @dc42 Still not, i'm sorry.
                        We are waiting for some complementary HW to arrive.

                        1 Reply Last reply Reply Quote 0
                        • undefined
                          MikeDC @dc42
                          last edited by 7 Jan 2022, 10:37

                          @dc42 said in G30 stop values increasing each time:

                          Hi @marcossf, I have put preliminary firmware that resolves this issue at https://www.dropbox.com/sh/cx760ysonlzzkjd/AACfsVfX4olHipuqmbWut5EKa?dl=0. Please test this firmware with care because I have only tested it using Duet 3 MB6HC + EXP3HC (the Z motor was connected to the EXP3HC).

                          If you are running your Duet with an attached Raspberry Pi then you must upgrade to RRF 3.4.0beta7 from the package server before you use these files.

                          You may also be interested in our forthcoming 6XD board, which is similar in many ways to the 6HC board but has ports for connecting external drivers instead of having internal drivers.

                          @dc42
                          I think I have the same issue with my 3 Z motors on the 3HC
                          I just moved them back to the mainboard.
                          please see my thread called levelling and mesh.
                          I can test these files if you think it may help resolve my issue too and will report back.
                          If so, do i need to copy all the files to my firmware folder or just the mainboards bin file and the 3hc bin file ?

                          undefined 1 Reply Last reply 7 Jan 2022, 17:27 Reply Quote 0
                          • undefined
                            dc42 administrators @MikeDC
                            last edited by 7 Jan 2022, 17:27

                            @mikedc yes they should resolve your issue. You need just the main board file and the files for the 3HC board and any other expansion boards (e.g. tool boards) that you are using.

                            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 7 Jan 2022, 17:38 Reply Quote 0
                            • undefined
                              MikeDC @dc42
                              last edited by 7 Jan 2022, 17:38

                              @dc42 are the map files required and do i just upload them via dwc to the firmware folder ?

                              undefined 1 Reply Last reply 7 Jan 2022, 17:50 Reply Quote 0
                              • undefined
                                dc42 administrators @MikeDC
                                last edited by 7 Jan 2022, 17:50

                                @mikedc you do not need the map 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

                                undefined 2 Replies Last reply 7 Jan 2022, 17:58 Reply Quote 0
                                • undefined
                                  MikeDC @dc42
                                  last edited by 7 Jan 2022, 17:58

                                  @dc42 Thankyou 😉

                                  I will upload as soon as my current print is finished and put Z back on the 3hc.
                                  Ill let you know here how i get on 🙂

                                  1 Reply Last reply Reply Quote 1
                                  • undefined
                                    MikeDC @dc42
                                    last edited by 8 Jan 2022, 03:48

                                    @dc42

                                    Thankyou sooo much 🙂
                                    I can confirm it is fixed on the 3HC
                                    Multiprobing each point
                                    06f93f7d-0b4b-4b21-a50c-31b4b9fd7764-image.png
                                    and
                                    0d7d45a5-ea7e-4a7f-bc1d-e95d95e8ee2b-image.png

                                    finally getting consistent results with no gradual increase in height from front to back 🙂

                                    This is much more like what I had before adding 2 more motors on X/Y and Z was on the mainboard

                                    undefined undefined 2 Replies Last reply 8 Jan 2022, 20:45 Reply Quote 2
                                    • undefined MikeDC referenced this topic 8 Jan 2022, 03:52
                                    • undefined
                                      dc42 administrators @MikeDC
                                      last edited by 8 Jan 2022, 20:45

                                      @mikedc thanks for confirming that this is fixed.

                                      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 8 Jan 2022, 21:50 Reply Quote 0
                                      • undefined
                                        MikeDC @dc42
                                        last edited by 8 Jan 2022, 21:50

                                        @dc42 your welcome,

                                        just to let you know, this beta7+2 release also has the same issue as this post with not heating up after a period of idle time

                                        https://forum.duet3d.com/topic/26698/printer-don-t-heat-after-longer-in-idle-state-3-4b7-1/4

                                        1 Reply Last reply Reply Quote 0
                                        • undefined
                                          Marcossf @MikeDC
                                          last edited by 10 Jan 2022, 09:59

                                          @mikedc Glad to hear that! Still haven't tested in our HW, but looks promising. The 1XD boards would be the same than 3HC in CAN delays related so I hope this solution also works with them.

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