OpenVoronoi and HeeksCNC's Inlay and Pocket operations
kgn
(I'm not familiar with Google groups, so please forgive my stumbles.)
Below is a discussion with Anders Wallin about pulling OpenVoronoi
into HeeksCNC to complete implementation of the Inlay operation. To
show why, I've thrown together a page at https://sites.google.com/site/kgncam/home/heekscad-cnc
-- please have a quick look.
Briefly, at https://github.com/kaben/ I'm working on the Inlay
operation in forks of HeeksCAD et al. I'd like to coordinate my
efforts with yours in order to benefit HeeksCAD, HeeksCNC, LibAREA,
and OpenVoronoi.
I recently found cases where the medial axis must be followed by a
raised chamfer bit through pocketing regions too narrow to pass the
bit at normal depth. OpenVoronoi is now able to provide a solution.
The drawbacks: more build dependencies, more ways to represent and
offset curves, and more ways to skin cats.
My next step is plug-in OpenVoronoi. Please let me know if you have
any dazzling advice, or warn me if I'm about to destroy your own plans
for something.
Thanks -- Kaben Nanlohy
On Wed, Jan 18, 2012 at 1:27 PM, Anders Wallin
<anders.e...@gmail.com> wrote:
> Yes, moving the discussion to the list is fine.
>
>> OpenVoronoi's python-lists output works quite nicely. For the
>> medial-axis output you use a list of chains, which in turn are lists
>> of point-distance pairs, and for the offset output you use a list of
>> loops, which in turn are lists of line- or arc-segments, but to use
>> the output from C++, refactorings like the following are needed:
>> https://github.com/kaben/openvoronoi/commit/c76957fcd8203b0fc22bbf5f20820d51e3f71cec
>> https://github.com/kaben/openvoronoi/commit/81d8e2813bcfd006e23da9754c97af4ccbd798a3
>> I've tried to write these patches in the same style you use to
>> decouple the VoronoiDiagram class from Python. But I'm introducing new
>> datatypes willy-nilly, which leads to redundancy and general havoc.
>> This is fine for my purposes, but perhaps not for yours. To make this
>> code benefit other people, I'd like some input before I clean it up.
>
> Yes, my idea has been that the pure C++ library can be built without
> linking with boost::python.
> Your commits look similar to my earlier simple way of separating C++ and python.
>
> In OpenVoronoi the Point class is intentionally 2D, because normally
> there is no Z-axis information present. For medial axis we obviously
> need to carry along the clearance-disk radius somehow. Note that the
> z-depth is the same as the clearance-disk radius only with a 90-degree
> cutter. For other cutter angles the z-coordinate needs to be
> multiplied by some factor.
>
> As for the output-format, I think it would be best to find an already
> existing standard and try to model that. There is something (OLD)
> called APT. Or perhaps STEP. In any case something that makes writing
> post-processors easy. Basically modeling G0 (rapid), G1 (feed), G2/3
> (arc), and perhaps conic/cubic (LinuxCNC, formerly known as EMC2 has
> these). One format for 3-axis or even 5-axis milling would be best
> (not separate for 2D and 3D).
>
>> Libarea's pocketing works just about perfectly in HeeksCNC. If the
>> universe were feeling charitable there would be no need to replace
>> libarea. However, HeeksCNC's Inlay routine doesn't yet handle islands:
>
> I guess I'm not very clear on the difference between pocketing and
> inlay. Could you find an image that displays the difference?
>
>> But V-carving in narrow regions of inlays requires medial axis data,
>> which you provide in openvoronoi. To make a long story short, we can
>> now use openvoronoi to complete the inlay routine. This would provide
>> yet another dependency in the HeeksCNC build, which, if one wishes to
>> alienate the uninitiated potential developer of HeeksCNC, should do
>> the trick. If one wishes to simplify the build process, one might
>> think about replacing libarea with openvoronoi, which can demonstrably
>> do pocketing quite well. For my purposes this is not necessary. But if
>> anybody else wants to use my code, it might be a good idea.
>
> One advantage of Python, since it is weakly-typed, is that if one uses
> for example nested lists as the universal way to pass geometry in and
> toolpaths out then one introduces very little dependency between
> modules.
> From the above I understand you would like to write HeeksCNC/GUI-code
> in C++? Then we indeed would want a universal format for input/output
> to various routines.
>
> I'm trying to set up a PPA which would host openvoronoi and opencamlib
> packages, but I'm not having much luck. Any experience with that?
>
> Anders
Anders Wallin
> into HeeksCNC to complete implementation of the Inlay operation. To
> show why, I've thrown together a page at https://sites.google.com/site/kgncam/home/heekscad-cnc
> -- please have a quick look.
OK, I may now understand inlay a bit better. If you still want to
improve on the description then some 3D images of male/female
inlay-parts would probably help a lot.
You could maybe threshold the medial-axis clearance-disk to find out
areas that are too "deep" for the V-cutter and have to be cleared with
a flat-cutter. I haven't looked at that or thought about it much yet.
>>> OpenVoronoi's python-lists output works quite nicely. For the
>>> medial-axis output you use a list of chains, which in turn are lists
>>> of point-distance pairs, and for the offset output you use a list of
>>> loops, which in turn are lists of line- or arc-segments, but to use
>>> the output from C++, refactorings like the following are needed:
>>> https://github.com/kaben/openvoronoi/commit/c76957fcd8203b0fc22bbf5f20820d51e3f71cec
>>> https://github.com/kaben/openvoronoi/commit/81d8e2813bcfd006e23da9754c97af4ccbd798a3
Did you get this to build on Ubuntu 10.04LTS ? LinuxCNC (the program
formerly known as EMC2) will use 10.04 (with outdated gcc/boost) until
maybe june/july this year.
It would be nice to support 10.04LTS, but if it's too much work then
time will take care of this 'problem'.
>> As for the output-format, I think it would be best to find an already
>> existing standard and try to model that. There is something (OLD)
>> called APT. Or perhaps STEP. In any case something that makes writing
>> post-processors easy. Basically modeling G0 (rapid), G1 (feed), G2/3
>> (arc), and perhaps conic/cubic (LinuxCNC, formerly known as EMC2 has
>> these). One format for 3-axis or even 5-axis milling would be best
>> (not separate for 2D and 3D).
Googling has turned up this:
www.mfgaa.com/ISO-4343%201978.pdf
I'm not sure if people use the terms CLDATA and APT interchangeably?
I'm not saying we must output an APT text file, just that it should be
reasonably easy to output APT or G-code from whatever internal format
we use for toolpaths.
>>> Libarea's pocketing works just about perfectly in HeeksCNC. If the
>>> universe were feeling charitable there would be no need to replace
>>> libarea.
I guess there are two ways to build libarea, either with kbool or with
Clipper. I would be interested in comparing OpenVoronoi against these,
both for correctness of the toolpaths, and speed of calculation. If
anyone can provide a minimal python-example of how to calculate an
offset with libarea that would be great.
Anders
kgn
Medial axis walk demo:
https://sites.google.com/site/kgncam/home/heekscad-cnc/inlay-medialaxis-walk
On Jan 19, 4:26 am, Anders Wallin <anders.e.e.wal...@gmail.com> wrote:
> OK, I may now understand inlay a bit better. If you still want to
> improve on the description then some 3D images of male/female
> inlay-parts would probably help a lot.
> You could maybe threshold the medial-axis clearance-disk to find out
> areas that are too "deep" for the V-cutter and have to be cleared with
> a flat-cutter. I haven't looked at that or thought about it much yet.
> >>> OpenVoronoi's python-lists output works quite nicely. For the
> >>> medial-axis output you use a list of chains, which in turn are lists
> >>> of point-distance pairs, and for the offset output you use a list of
> >>> loops, which in turn are lists of line- or arc-segments, but to use
> >>> the output from C++, refactorings like the following are needed:
> >>>https://github.com/kaben/openvoronoi/commit/81d8e2813bcfd006e23da9754...
> Did you get this to build on Ubuntu 10.04LTS ? LinuxCNC (the program
> formerly known as EMC2) will use 10.04 (with outdated gcc/boost) until
> maybe june/july this year.
> It would be nice to support 10.04LTS, but if it's too much work then
> time will take care of this 'problem'.
The kernel is not happy with me.
> Googling has turned up this:www.mfgaa.com/ISO-4343%201978.pdf
> I'm not sure if people use the terms CLDATA and APT interchangeably?
> I'm not saying we must output an APT text file, just that it should be
> reasonably easy to output APT or G-code from whatever internal format
> we use for toolpaths.
brain over there.
> I guess there are two ways to build libarea, either with kbool or with
> Clipper. I would be interested in comparing OpenVoronoi against these,
> both for correctness of the toolpaths, and speed of calculation. If
> anyone can provide a minimal python-example of how to calculate an
> offset with libarea that would be great.
use to benchmark both within HeeksCAD. The only comparable operation I
can think of would be offsets. Again, I hope to be able to get it done
this weekend.
Kaben