Opinions and questions about my first moves of my corexy



  • Hello,

    because I still have no experience with the parameters acceleration, jerk, max speed, etc., I ask you to watch my first moves on the basis of a video and your comments on my preliminary values (in the credits of the video).
    I know that you can judge this final correctly only after test printing, but I ask for your first estimate.

    Furthermore, I have a question: is it normal that a circular motion can only be driven with a maximum of about 125 mm / s?

    PS: Of course that's enough, it just interests.

    PPS: the funny noise (rattling) mainly in the circular motion is the protective glass of the dial indicator and the loud background noise the (cheap) 750W power supply 🙂

    PPPS: A detailed project presentation will follow - first I would like to get it started

    And here is the video:
    https://youtu.be/96FVq7DEboo

    Thanks for watching and comments 👍


  • administrators

    YouTube reports "This video is unavailable".

    Circles in GCode sliced from STL files are made up of short line segments. The print head has to slow down at the boundaries of those segments sufficiently to avoid exceeding the X and Y jerk limits. So increasing those limits in the M566 command may allow you to pronit circles at higher speeds.



  • @dc42
    Now the video should be available -> https://youtu.be/96FVq7DEboo

    The circel was made with GCode G2 … and not with a slicer, that's why I was a little bit surprised



  • It looks like it's working well. I don't know why the G2 circle would be speed limited, but none of the slicers use that gcode, so it isn't a realistic test compared to printing. Is there some lower speed command (maybe a travel move from the corner of the square to the starting point of the circle) before the G2 command ? The speed is modal so many movement commands will simply use whatever the last speed setting was.

    The bottom of this page will show you speed vs acceleration vs path length.

    Try slicing a circular object and see how it behaves.



  • That's the Code i use:

    **** Start 5
    G1 X50 Y50 F6000 ; 100 mm/s
    G1 Z150 F2400
    G1 Z170
    G1 X250 F30000 ; 500 mm/s
    G1 Y250
    G1 X50
    G1 Y50
    G1 Y150
    G2 X250 Y150 I100
    G2 X50 Y150 I-100
    G1 Y250
    G1 X250
    G1 X50 Y50
    *** Ende*

    A sliced circular object i will try


  • administrators

    Thanks. Currently, G1 G2 and G3 use a fixed segment size of 0.2mm. Each segment requires, amongst other things, the computation of one sine and one cosine of a floating point number. At 125mm/sec, that's 625 sines and 625 cosines per second. So 1250 sines and cosines per second. My guess is that this, together with everything else that the processor has to do, is maxing out the processor.

    Which Duet or other controller are you using? The Duet WiFi and Ethernet have single-precision floating point hardware. The Duet Maestro, older Duets and other controllers supported by RRF don't.

    I can see a few ways to speed this up:

    1. Don't use a fixed segment size. I could make it configurable, or make it depend on the size of the arc being printed. Arcs with large radius could use a larger segment size.
    2. Instead of computing sine and cosine separately, it might be faster to compute just one and use square and square root to compute the other.
    3. I'm not certain that the sine and cosine are being computed using the floating point hardware. The maths library is rather opaque, so it's possible that it is computing in double precision maths and then rounding to float.
    4. Instead of computing sine and cosine for every segment, only compute them every N segments and use a cheaper computation most of the time.

    I checked what Marlin does. It uses a default segment length of 1mm (five times larger than RRF) and technique #4 from the above list.



  • @dc42 said in Opinions and questions about my first moves of my corexy:

    Thanks. Currently, G1 and G3 use a fixed segment size of 0.2mm.

    David,

    Did you mean G2 and G3 rather than G1 and G3?


  • administrators

    @deckingman said in Opinions and questions about my first moves of my corexy:

    @dc42 said in Opinions and questions about my first moves of my corexy:

    Thanks. Currently, G1 and G3 use a fixed segment size of 0.2mm.

    David,

    Did you mean G2 and G3 rather than G1 and G3?

    Yes, I have corrected it.

    I've done the calculations, and for large arcs we can use a much larger arc segment length than 0.2mm. So in 2.02RC5 I'll make the segment length vary depending on the arc radius, with limits of 0.2mm and 1.0mm. This will make it possible to draw arcs at five times the speed, for all but the smallest radius arcs.



  • @dc42 :

    Which Duet or other controller are you using?

    -> Duet WiFi 1.04

    I think that optimizing the circle speed would not be bad. A dependency on the circle diameter sounds good, so the accuracy of small circles does not suffer.

    Otherwise, are the values for the beginning ok?


  • administrators

    Yes, the GCode commands look OK to me.

    I've made the change to vary the segment size depending on radius. Also I've timed the sine + cosine calculation:

    • On the Duet Maestro (120MHz, no hardware FP, no cache) sin+cos takes about 28us in float and 47us in double arithmetic.
    • On the Duet WiFi/Ethernet (120MHz, single precision FP, cache), sin+cos takes around 2us in float and 42us in double.




  • @dc42 That only applies to G2 arcs though, correct? Are these moves only used in CNC tooling path planners? No slicers make use of them?


  • administrators

    @phaedrux said in Opinions and questions about my first moves of my corexy:

    @dc42 That only applies to G2 arcs though, correct? Are these moves only used in CNC tooling path planners? No slicers make use of them?

    Correct. Slicers work from STL models, in which curves surfaces are already approximated by straight lines.


 

Looks like your connection to Duet3D was lost, please wait while we try to reconnect.