Need help to understanding C code, with labs and >>

[ryannining]

I have modify by copy paste ARC implementation from repetier. and found problem when calculating the arc radius.

i also have problem with square root32, then i take code from brach-arc-support and still have problem in this line

uint32_t r = approx_distance(labs((int32_t)next_target.target.I)>>6+abs((int32_t)next_target.target.J)>>6)<<6;

uint32_t r = approx_distance(labs((int32_t)next_target.target.I)/64+labs((int32_t)next_target.target.J)/64)*64;

but this code is work uint32_t r = approx_distance(abs((int32_t)next_target.target.I)/64+abs((int32_t)next_target.target.J)/64)*64;

My previous code was using SquareRoot32 also not work, but if i use float type and sqrt its work...

[ryannining]

uint32_t r = approx_distance(labs(next_target.target.I)/16,labs(next_target.target.J)/16)*16; sersendf_P(PSTR("Arc I, J,R:%lq,%lq,%lq\n"),next_target.target.I,next_target.target.J,r); That line when process G2 I3 J3 will show: Arc I, J,R:3.000,3.000,0.000

Its not overflow i think, since if i change /16 to /100, still result 0 in R Weird.... make frustate a lot.

This is work, but only on I value

uint32_t r = approx_distance(abs(next_target.target.I)/100,abs(next_target.target.J)/100)*100; sersendf_P(PSTR("Arc I, J,R:%lq,%lq,%lq\n"),next_target.target.I,next_target.target.J,r);

result Arc I, J,R:0.000,3.000,0.000 so if i send G2 I0 J3 it still result 0 in R,..... ultra weird, or i just dont understand C fixed point ?? if i send both I3 J3 it show R is 2 Arc I, J,R:3.000,3.000,2.000

Maybe the aprox_distance ? but i dont change anything....

[ryannining]

adding #include "dda_maths.h"

fixed it.....

[Traumflug]

A change in a personal copy of the repo is no solution :-)

[ryannining]

Yea, sorry i havent upload my modification, since i not familiar with github.

I was make a custom 3d+cnc board and using atmega328p, and i dont know if some branch already implement arc, so i try make arc implementation, because inkscape gcode export have so many g2 and g3.

Thank you for this great firmware.

[Traumflug]

There is arc support (by segmenting) in branch arc-support. This was once picked up as a patch to a pretty old Teacup version, then rebased. It might work when rebasing it to recent branch experimentalagain. Even if not, it should be a good starting point.

There's also a chance for 'true' arc support, without segmenting. Movement direction would be updated continuously in dda_clock(), then. Tricky, because it has to compensate rounding errors and detect movement end, but doable.

[ryannining]

There's also a chance for 'true' arc support, without segmenting. Movement direction would be updated continuously in dda_clock(), then. Tricky, because it has to compensate rounding errors and detect movement end, but doable.

Interesting....