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
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.gna.org/listinfo/pythonocc-users
