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

    Actual movements during failed simulation

    Scheduled Pinned Locked Moved
    Firmware developers
    3
    20
    764
    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

      @ÖrjanE, quite so! The test should be on hSquared instead. Something like this I think:

      		const float hSquared = fsquare(rParam) - dSquared/4;				// square of the length of the perpendicular from the mid point to the arc centre
      
      		// When the arc is exactly 180deg, rounding error may make hSquared slightly negative instead of zero
      		float hDivD;
      		if (hSquared >= 0.0)
      		{
      			hDivD = sqrtf(hSquared/dSquared);
      		}
      		else
      		{
      			if (hSquared < -0.01 * fsquare(rParam))
      			{
      				err = badArcParametersMessage;
      				return true;
      			}
      			hDivD = 0.0;													// this has the effect of increasing the radius slightly so that the maths works
      		}
      

      Do you agree?

      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

      ÖrjanEundefined 1 Reply Last reply Reply Quote 0
      • ÖrjanEundefined
        ÖrjanE @dc42
        last edited by

        @dc42 Looks correct. The interpretation of the constant -0.01 is not transparent. I guess it implies that the radius can be 10% (sqrt(0.01)) too short without throwing an error.

        The current (3.2.2) code does not throw an error at all, but does not print the arc correctly if the radius is slightly too short. The resulting arc is basically a straight line, probably because the hDivD value actually used is rediculously high.

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

          I've changed it to:

          			if (hSquared < -0.001 * fsquare(rParam))						// allow the radius to be up to sqrt(0.001) ~= 3.2% too short
          

          In the 3.2.2 code, hDivD will be a NaN if the radius is too short, so it's not surprising that it misbehaves.

          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

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

            Actually that's still wrong. (r + xr)^2 ~= r^2(1 + 2x) if x is small, so I will use this instead:

            			if (hSquared < -0.02 * fsquare(rParam))						// allow the radius to be up to 1% too short
            

            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

            ÖrjanEundefined 2 Replies Last reply Reply Quote 0
            • ÖrjanEundefined
              ÖrjanE @dc42
              last edited by

              @dc42 Looks good!

              Now, back to the other problem; that an error during simulation may cause physical movement. In 3.2.2 I can't cause the "too small radius"-error any more, but looking at the source code, I realized that I can provoke an error by setting identical start end end points for G2 or G3 with an R parameter.

              This code:

              G28 ; Home all axes
              G21 ; set units to millimeters
              G90 ; use absolute coordinates
              M83 ; use relative distances for extrusion
              
              G1 Z20.000 F7800.000
              G1 F1800.000
              G1 X115 Y115
              G1 F200.000
              G3 X115 Y115 R5
              M0 ; Stop print
              

              will cause the message "Error: SetPositions called when DDA ring not empty" as well as "Error: G2/G3: radius is too small to reach endpoint" when run in simulation mode. It also causes a physical movement (some 10mm in the negative X direction).

              Hope you can replicate this behaviour.

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

                Thanks, it sounds to me that when the error occurs, the simulation is exiting before the DDA ring has been emptied, which ties in the message.

                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
                • ÖrjanEundefined
                  ÖrjanE @dc42
                  last edited by

                  @dc42 I have also noted another symptom, probably due to the same problem.

                  When printing (not simulating) the code above, the same unexpected movement as in simulation takes place when the error occurs and printing is aborted. The axes remain in homed-status but the coordinates have not been updated with that last movement.

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

                    @ÖrjanE said in Actual movements during failed simulation:

                    @dc42 I have also noted another symptom, probably due to the same problem.

                    When printing (not simulating) the code above, the same unexpected movement as in simulation takes place when the error occurs and printing is aborted. The axes remain in homed-status but the coordinates have not been updated with that last movement.

                    Do you get the "SetPositions called when DDA ring not empty" message again?

                    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

                    ÖrjanEundefined 2 Replies Last reply Reply Quote 0
                    • ÖrjanEundefined
                      ÖrjanE @dc42
                      last edited by

                      @dc42 said in Actual movements during failed simulation:

                      Do you get the "SetPositions called when DDA ring not empty" message again?

                      No.
                      And now I can't replicate that second behaviour (extra movement when not simulation). Perhaps it is state-dependent and du to some leftover state from the failed simulation.

                      1 Reply Last reply Reply Quote 0
                      • ÖrjanEundefined
                        ÖrjanE @dc42
                        last edited by

                        @dc42 Forget about the "second symptom" (problem during actual print). I have restarted the duet and fail to repeat the problem. It may be that I misinterpreted what happened when I tested this.

                        Regarding the move when simulating; it makes sense that it is the last move/moves that remain queued when simulation mode is turned off prematurely. The move does not seem to be random, but consistent with the last move that should have been done (in simulation) before the error occurred.

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

                          Thanks for your example. I have reproduced the issue, and fixed it in the 3.3 branch source code. Moves already prepared and put into the movement queue are now completed when a job is aborted.

                          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

                          ÖrjanEundefined 1 Reply Last reply Reply Quote 0
                          • ÖrjanEundefined
                            ÖrjanE @dc42
                            last edited by

                            @dc42 Great!
                            Thanks for your work in maintaining this software.

                            dc42undefined 1 Reply Last reply Reply Quote 1
                            • dc42undefined
                              dc42 administrators @ÖrjanE
                              last edited by

                              @ÖrjanE said in Actual movements during failed simulation:

                              @dc42 Great!
                              Thanks for your work in maintaining this software.

                              Thanks for your clear description of the issue and GCode file to reproduce it.

                              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
                              • First post
                                Last post
                              Unless otherwise noted, all forum content is licensed under CC-BY-SA