Pocket arc could be straight line

[GoogleCodeExporter]

The attached bad.heeks file contains a single sketch used for a single pocket 
operation.  There is one section of the cutting toolpath that is defined as an 
arc whose length is in the order of 1mm but whose centre point (I and J terms) 
are exceedingly large.

The line of GCode is ;
N1300  G03 X268.113 Y360.627 I234855825324.517 J-607862136134.409 F75.000

I understand that this is a valid arc definition.  In fact the backplotting 
presents it correctly as a short arc.  When it's read into EMC2 the AXIS user 
interface renders it correctly as a short arc.

Unfortunately, when EMC2 processed the line of GCode, it machined a great long 
line through the middle of my workpiece.  i.e. the machine's movement did not 
match the rendered GCode.

I also understand that this is really an error in EMC2.  I was just wondering 
if we should add an extra check to the pocket generation code such that, if an 
arc's deflection is smaller than the geometry tolerance, perhaps we could 
replace it with a straight line.  This would be a workaround to what is really 
an EMC2 problem.

I was thinking along the lines of;
 - find a point half way along the arc.
 - measure the distance between this point and a line drawn between the arc's endpoints. gp_Lin.SquareDistance()
 - if this distance is less than geometry tolerance then replace the arc with a straight line between its endpoints.

eg: gp_Pnt midpoint;
    gp_Pnt start_point;
    gp_Pnt end_point;
    gp_Lin straight( start_point, end_point );
    if (straight.SquareDistance(midpoint) < tolerance)
    {
      generate G01 (straight line) path
    }
    else
    {
      generate G02/G03 (arc) path
    }

I'm happy to be disagreed with on this.  I'm just after the easiest solution to 
my problem.

Original issue reported on code.google.com by David.Ni...@gmail.com on 13 Jun 2010 at 12:06

[GoogleCodeExporter]

Original comment by David.Ni...@gmail.com on 13 Jun 2010 at 12:07

Attachments:

• bad.heeks
• bad.tap

[GoogleCodeExporter]

Actually I can workaround my problem by adding a less robust (read 'hack') 
test.  The cut_area() method in the area_funcs.py file knows the 'I' and 'J' 
terms by measuring 'cx - px' and 'cy = py'.  If these distances are greater 
than '1.0 / tolerance' then the size of the circle is 'huge'.

I have hacked the area_funcs.py file and it serves my purposes but I can't 
decide if this is a valid test in all circumstances.

The fact that I'm not passing the tolerance in from the Heeks data model is 
also a flaw but, as I said, it's a hack at the moment.

Any opinions as to the validity of this hack?

Original comment by David.Ni...@gmail.com on 13 Jun 2010 at 12:43

Attachments:

• area_funcs.py

[GoogleCodeExporter]

David,
You are right, any are with a very large radius should be done as an arc.
This should be done in libarea, though. I will look at it.

Original comment by danhe...@gmail.com on 13 Jun 2010 at 7:27

[GoogleCodeExporter]

I obviously wrote my last comment in a hurry; I meant:
You are right, any arc with a very large radius should be output as a line.

Original comment by danhe...@gmail.com on 13 Jun 2010 at 7:37

[GoogleCodeExporter]

Dan,
  I have added an extra check for particularly large arcs in the CCurve::CheckForArc() method.  Look for the 'max_arc_radius' variable in the Area.cpp file attached to see the check.  It seems to work alright but I can't commit to the libarea project.  If you agree with the change, can you please commit it?
  Ta
  David Nicholls

Original comment by David.Ni...@gmail.com on 2 Sep 2010 at 9:44

Attachments:

• Area.cpp

[GoogleCodeExporter]

David,
I have added you as a committer to the libarea project.
But I am worried that we might want an arc with a large radius, if it is a 
large arc.
I think the code below your change should be doing the same thing.
                if(!c.LineIsOn(current_vt->m_p, vt->m_p, accuracy))
                        return false;
Dan.

Original comment by danhe...@gmail.com on 3 Sep 2010 at 7:07

[GoogleCodeExporter]

This has changed quite a bit recently and is probably fixed now.

Original comment by danhe...@gmail.com on 23 May 2011 at 8:29

• Changed state: Fixed