Hi Dave,
I don't know what it would take to integrate it with pythonOCC, but it
already has python bindings that are pretty straightforward. Somehow, I
don't think you would want to convert the whole thing to python, since
it would slow things down. I have used it from HeeksCNC (it's intended
application) and as a stand alone module on my Mac. I have done some CNC
programming in which I just used the modules that Heeks came up with
from the terminal and created some useful machining code. I think Dan
Heeks did a good thing in making all the separate machining modules into
individual projects. He has kurve -which is for simple profiling,
libactp- adaptive roughing, libarea- pocketing, and then he adapted
Pycam for surfacing. Pycam, being written in pure python is pretty slow
at generating gcode.
I think there is a test script included with the project that should be
pretty helpful in showing what input format it needs. You could
probably just do something like 'import libarea' and use it from your
application.
Dan
On 2/12/10 8:04 AM, Dave Cowden wrote:
Hi Dan,
Yes that logo looks like a fairly good test case. It has some very
sharp small portions.
What do you think the possibility would be to "pyOCC-size" that
algorithm so that we can use it convieniently in conjunction with the
OCC objects?
IE, how difficult would it be to make a python version of the library
that would operation on a wire object? That'd save me some work.
Last night i spent some time on a routine to convert an edge, wire,
and gp_Pnt into code-- these were fairly easy, because I copped out
and handled only edges that have lines as the curve. But with another
few hours i should be able to handle curves of type circle and ellipse
and convert them to G2/G3 ( which, by the way, is something very very
few cam packages out there do today).
After that, my next step would be the last one i need for my slicer--
to add 'convert a face to gcode'. Doing this part would need the
offset algorithm available...
On Fri, Feb 12, 2010 at 10:10 AM, Dan Falck <dfa...@verizon.net
<mailto:dfa...@verizon.net>> wrote:
Hi Dave,
I will try and attach a screenshot. I think that this lib does
pretty well. I used it for pocketing this logo and was pretty
pleased with the results. I haven't used it extensively, but so
far so good.
Thanks,
Dan
On 2/12/10 4:14 AM, Dave Cowden wrote:
Hey, Dan:
How well does this routine handle geometries for which offset
curves self or boundary intersect? pyOCC actually has a very
easy to use tool to do the offsets, but it runs into trouble when
the curves self-intersect-- essentially it just punts and throws
an error.
So, with pyOCC i think i'd have to manually offset each curve and
then find the intersections, so that I can deal with what happens
when the geometry is odd....
On Thu, Feb 11, 2010 at 10:48 PM, Dan Falck <dfa...@verizon.net
<mailto:dfa...@verizon.net>> wrote:
Hi guys. Would a 'pocketing' routine like this help?:
http://code.google.com/p/libarea/
I use routines like this to mill away material, but you could
also use it for filling.
Dan
On 2/11/10 8:34 AM, Dave Cowden wrote:
Hi, Thomas, thanks!
The target machine is a rapid prototyping (RP) machine--
RepRap. Thus, the infill for a slice is not necessarily a
'machine all material away' path. Ultimately it still uses
Gcode, but it is additive rather than subtractive. I use EMC
for machine control.
The ideal is actually to offset all of the wires on the face
inwards to create a user-configured number of 'shells'
around the exterior boundaries, but then inside fill with a
hatch pattern. For the offset I can use BRepOffsetAPI of course.
The unusual variation that an RP machine has is that the
interior hatching is ideally not uniform or 100% coverage.
Sometimes a honeycomb is desired, and other times, a
'sparse' hatch is desired to save material.
I thought about looping over the surface parameters, but
then again realized it would not create points along a
uniform grid.
Is there a function that will test whether a point is on the
surface? Maybe it would be easiest to make my own discrete
x-y- grid, and then simply test each point for membership on
the surface.
I'm quite excited about this project. The main reason is
that nearly the entire RP community ( including commercial )
still relies on STL files for production. This is a pain
because it results in all toolpaths being little line
segments. So for curves there end up being a billion little
G01 moves.
Using OCC represents the only way i know of to use STEP
representations of solids, which when sliced still preserve
the ability to generate Gcode arcs ( G02/G03 ), which result
in much smaller Gcode and much smoother motion than having
all arcs represented by tiny line segments. This would be
the first tool that can prevent a triangulated approximation
during the fabrication process.
Thanks for the help!
On Thu, Feb 11, 2010 at 11:16 AM, Jelle Feringa
<jelleferi...@gmail.com <mailto:jelleferi...@gmail.com>> wrote:
> I'm getting back to using pyOCC after a while.
Welcome back Dave, we've missed you!
> I am hoping someone can point me the right direction.
After reading documentation and samples for a few hours,
I'm still not sure where to start.
>
> Previously, I have written a slicing application (
samples--> slicer ), and I would like to continue that work.
>
> The next step is to create toolpaths that fill in the
faces created from the slicing operation.
Wow, so a g-code export?
Have you seen pycam?
> There are a number of general approaches that could
be used: One is to use BRepOffset to offset the wires
inwards.
>
> However, the approach I would rather take is to use a
'grid' approach, in which I first compute a grid of
points on the face, and the fill them all in afterwards.
I feel like this approach will be more tolerant to
degenerate geometry.
Yes, dekskproto of delft spline systems has that
algorithm for instance.
> So, to my question: I think looking at the SMESH
sample, I could use smesh to generate a set of points on
my surface that are spaced evenly.
Or just loop through the U,V domain of a face?
And than offset via the normal of the face?
> Looking at the sample I can see how to create the
mesh, but I cannot see how to extract the points from
the mesh.
You could do something similar ( if you decide polysoup
is the way to go ) to just look up the triangles that
represent a surface ( we always look at triangles in
OpenGL, you don't get to see the actual nurbs but just
an approximation )
> I am also unsure how to instruct the mesher to
generate a grid that has a fixed space between the
points in a particular plane.
No way a mesher will generate equidistant points uh uh...
> In my case the face will always be a planar face in
the x-y plane: what I want is an array of points at a
fixed spacing that cover the surface.
Right, abscissa points…
So, what about dividing up the contours of your slicer
by n-points or a distance?
For what machine are you writing the slicer exactly?
Do you need an offset ( like we need when milling ) to
the surface?
Happy to see you back on this list ;')
-jelle
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
