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