Hi: Yes, last night I was looking around for pocket millling routines. I'll take a llok at thr one you have linked and see how it would work, thanks!
On 2/11/10, Dan Falck <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 >> https://mail.gna.org/listinfo/pythonocc-users >> > > _______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
