Oh i'm sorry, that was Jelle :( Sorry about that. On Thu, Feb 11, 2010 at 11:34 AM, Dave Cowden <dave.cow...@gmail.com> 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>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
