Opinions and questions about my first moves of my corexy

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