Overlay acrs on cut-location points

[GoogleCodeExporter]

I have made a start at adding a Waterline Machining Operation option in 
HeeksCNC that simply captures the various geometry and parameters before asking 
the OpenCamLib to generate the toolpath for the waterline machining.  The 
toolpath is expressed in terms of a series of cut location points and so the 
result is a tool 'feed' along the short lines joining these points.

Although the code does work, I believe a significant amount of time is taken in 
the translation of the point data from the C++ to the Python layers.  The other 
side-effect of this is that the amount of GCode produced is quite significant.

I was wondering how difficult it would be to implement a class that converts a 
vector<Point> into a Path (which, itself, contains a list of lines/arcs).  If 
we could overlay arcs onto groups of points, it could significantly reduce the 
amount of data that is sent to the Python layer for GCode generation.

As an extension to this, we may be able to overlay single (longer) lines over a 
series of points to reduce the overhead.

I was thinking that a vector<Point> and a tolerance could be provided.  If we 
joined pairs of adjacent points to form pairs of lines, we could intersect the 
normal (perpendicular line) of each base-line.  If the normal (perpendicular) 
lines were parallel to each other then the common point used to form the two 
base lines could be removed and the remaining two joined as a single line.

If the normals of the two lines intersected then we could add the intersection 
location to a std::set<Point> intersections.  We could keep doing this while 
adjacent lines also intersected at the same intersection point as their 
neighbour.  (I don't think I've described this very clearly).  The result would 
be that, if all these lines had common intersection points then they could all 
be replaced with a single arc element.

I'm happy to do this work but it may take me a while.  I just wanted to suggest 
it in a manner that could include feedback.

Original issue reported on code.google.com by David.Ni...@gmail.com on 11 Aug 2010 at 4:45

[GoogleCodeExporter]

I should also have mentioned that I'm thinking along the lines of adding a 
constructor to the Path class such as;

Path(const std::vector<Point>, const double tolerance)

This constructor would do the line/arc overlay process.  We could then just add 
a method to the Waterline class such as;

boost::python::list pyGetPaths().  This would need to construct a vector<Path> 
objects locally using its own vector< vector<Point> > data.  It would then 
iterate through the Path objects asking each for their getTypeSpanPairs().

Original comment by David.Ni...@gmail.com on 11 Aug 2010 at 4:53

[GoogleCodeExporter]

For zigzag operation we are refining the points using this code
         plist = dcf.getCLPoints()
         f = ocl.LineCLFilter()
         f.setTolerance(0.01)
         for p in plist:
             f.addCLPoint(p)
         f.run()
         plist = f.getCLPoints()

http://code.google.com/p/heekscnc/source/browse/trunk/ocl_funcs.py#80

It doesn't do arcs though.

Could you copy my code from libarea?
CCurve::FitArcs() tries to do exactly what you describe.

http://code.google.com/p/libarea/source/browse/trunk/Area.cpp#116

Original comment by danhe...@gmail.com on 11 Aug 2010 at 6:44

[GoogleCodeExporter]

Waterline is still quite unoptimized. If you send me a minimal interesting 
test-case that runs "too slow" I can take a look.

Extending the CLFilter idea so that it can detect arcs and output path-objects 
is a good idea. The filter should be generic enough so that it can be run on 
output from a Waterline calculation or DropCutter calculation (or something 
else we come up with in the future). I should have a paper or two on this, I 
can post a link if I find them.

The path objects (line and arc) should model quite closely G-code I think, so 
that it is easy for a post-processor to translate into G-code. It would make 
sense to look at what the heekscnc post-processors take as input, so that we 
don't need yet another translation of ocl.Path objects into heekscnc.path 
objects (since I don't think post-processors belong to ocl, at this stage in 
the project anyway)

Original comment by anders.e...@gmail.com on 11 Aug 2010 at 9:02

[GoogleCodeExporter]

the paper I was thinking about is
"identifying salient circular arcs on curves", Eric Saund, 1992. Googling for 
this yields a pdf download.

Original comment by anders.e...@gmail.com on 11 Aug 2010 at 9:08

[GoogleCodeExporter]

Thanks Dan and Anders,

  I will read the article but, if Dan doesn't mind my duplicating some of the libArea code, I may use some of that.  I will decide which of these two options I understand better.

  I won't give an example of slow processing as I don't believe the time spent within the OpenCamLib code is the problem.  As much as anything, the time taken to re-parse the generated GCode (with its many small lines) is taking much of the overall time.  If I can reduce the number of individual paths, and hence the number of lines of GCode, the whole process will run much better.

  I will look into this but I don't expect to have anything quickly.

  Thanks
  David Nicholls

Original comment by David.Ni...@gmail.com on 11 Aug 2010 at 9:24

[GoogleCodeExporter]

David,

Yes, use any of the files with "written by Dan Heeks" at the top from libarea 
for anything you want. Consider them as BSD license or public domain.

HeeksCNC is quite slow at backplotting huge numbers of small line moves from 
the NC code. I found with the zigzag operation that refining the points made a 
huge difference.

Dan.

Original comment by danhe...@gmail.com on 11 Aug 2010 at 9:39