Are arcs tested?

[hurzl]

Just wanted to ask whether arcs are really tested. I get Marlin running strange circles on small arcs with repsnapper which displays as correct. I tried with your angle calculation (atan2 of motion-control.cpp) for display in repsnapper, but get the same result. So the angle seems to be correct, but the resulting path seems to run the other direction. I get the arc in repsnapper by rotating the position vector (done by vmmlib). In repsnapper the arc display is consistent with the calculation, so I wonder if Marlin arcs are known to be correct. As the souce talks about rounding errors there may be a problem with small arcs.

Printrun draws the same strange arcs that Marlin walks http://www.abload.de/img/hex-printrunqhbcf.png Here's an image how repsnapper displays the same gcode: http://www.abload.de/img/hex-repsnapperf0lhv.png (repsnapper code, but loaded as gcode file)

[ErikZalm]

They are not tested a lot because there is/was no good g-code generator for it. I will see if i can verify it. Can you send the g-code?

[hurzl]

of course... http://pastebin.com/YqnBswfX

probably it has to do with MM_PER_ARC_SEGMENT set to 1, too...

[hurzl]

probably the MM_PER_ARC_SEGMENT should be set depending on arc radius, OR if the arc is too small, draw a line instead?

[hurzl]

I wonder if this is just wrong, the arc length should be angle * radius

  float millimeters_of_travel = hypot(angular_travel*radius, fabs(linear_travel));
  if (millimeters_of_travel < 0.001) { return; }
  uint16_t segments = floor(millimeters_of_travel/MM_PER_ARC_SEGMENT);

and if millimeters... < MM_PER_ARC_SEGMENT segments will be 0

[hurzl]

Well no, everything ok, I had to understand that linear_... usually means the Z axis. Except for segments becoming zero, so I added

  if (segments == 0)  segments = 1;

It seems I get good results with

#define MM_PER_ARC_SEGMENT 0.3
#define N_ARC_CORRECTION 50

in Configuration_adv.h

[braddo99]

are arc commands still untested? I'm having trouble getting Marlin to react properly to any arc commands. BTW I am testing out the use of CamBam for this, which program came highly recommended.

This gcode snippet for instance, makes my delta bot twirl around for a few seconds then dash straight down to crash into the bed:

G28 G21 G90 G64 G40 G0 F800.0 Z10.0 G17 M3 S1000 G0 X11.3804 Y-25.9541 G0 Z7.45 G1 F300.0 Z6.35 G3 F800.0 X10.3451 Y-25.5545 I6.867 J-36.106 G3 X12.2348 Y-21.7952 I-0.0005 J-17.9997 G1 X12.3138 Y-21.904 G3 X13.1383 Y-22.9093 I21.3019 J-15.3736

CamBam has several options for arc syntax, and I'm not sure which one is best to use yet, but none of the outputs look like they should result in driving effector down past 0 into the bed.

[braddo99]

@hurzl, could you be more specific about the change you made?

[hurzl]

I thought this was fixed long ago and I used it with arcs? I can hardly remember

[qharley]

Is the code for arcs not optimised for cartesian bots?

On Fri, Jan 3, 2014 at 10:56 AM, hurzl notifications@github.com wrote:

I thought this was fixed long ago and I used it with arcs? I can hardly remember

— Reply to this email directly or view it on GitHubhttps://github.com/ErikZalm/Marlin/issues/127#issuecomment-31511462 .

[hurzl]

Yes probably it was only fixed for cartesian

[tmilker]

@braddo99 Please open a new issue if this is still a problem, closing this one.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.