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

Actual movements during failed simulation

Scheduled Pinned Locked Moved
Firmware developers
3
20
761
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
    last edited by dc42 24 Feb 2021, 14:44

    @Ö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

    undefined 1 Reply Last reply 24 Feb 2021, 14:59 Reply Quote 0
    • undefined
      ÖrjanE @dc42
      last edited by 24 Feb 2021, 14:59

      @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
      • undefined
        dc42 administrators
        last edited by 24 Feb 2021, 16:26

        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

        undefined 1 Reply Last reply 24 Feb 2021, 16:31 Reply Quote 0
        • undefined
          dc42 administrators @dc42
          last edited by dc42 24 Feb 2021, 16:31

          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

          undefined 2 Replies Last reply 24 Feb 2021, 17:06 Reply Quote 0
          • undefined
            ÖrjanE @dc42
            last edited by 24 Feb 2021, 17:06

            @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
            • undefined
              dc42 administrators
              last edited by 24 Feb 2021, 17:37

              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
              • undefined
                ÖrjanE @dc42
                last edited by 24 Feb 2021, 17:37

                @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.

                undefined 1 Reply Last reply 24 Feb 2021, 17:38 Reply Quote 0
                • undefined
                  dc42 administrators @ÖrjanE
                  last edited by 24 Feb 2021, 17:38

                  @Ö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

                  undefined 2 Replies Last reply 24 Feb 2021, 17:43 Reply Quote 0
                  • undefined
                    ÖrjanE @dc42
                    last edited by 24 Feb 2021, 17:43

                    @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
                    • undefined
                      ÖrjanE @dc42
                      last edited by 24 Feb 2021, 17:57

                      @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
                      • undefined
                        dc42 administrators
                        last edited by dc42 24 Feb 2021, 18:00

                        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

                        undefined 1 Reply Last reply 24 Feb 2021, 18:05 Reply Quote 0
                        • undefined
                          ÖrjanE @dc42
                          last edited by 24 Feb 2021, 18:05

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

                          undefined 1 Reply Last reply 24 Feb 2021, 18:52 Reply Quote 1
                          • undefined
                            dc42 administrators @ÖrjanE
                            last edited by 24 Feb 2021, 18:52

                            @Ö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
                            17 out of 20
                            • First post
                              17/20
                              Last post
                            Unless otherwise noted, all forum content is licensed under CC-BY-SA