Opinions and questions about my first moves of my corexy

thwe

@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

mrehorstdmd

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.

thwe

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

dc42

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:

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

deckingman

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

dc42

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

thwe

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

dc42

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.

thwe

@dc42

Phaedrux

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

dc42

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

thwe

@dc42 :
today the firmware update on RC6 made -> the circle with a diameter of 200m now runs with max. about 380 mm / s >> great!

dc42

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

@dc42 :
today the firmware update on RC6 made -> the circle with a diameter of 200m now runs with max. about 380 mm / s >> great!

Do you have a use for moving that fast in circles?

thwe

Do you have a use for moving that fast in circles?

@dc42 : currently no, maybe later I would like to laser engrave