Anyway, happy to see you back Dave! I loved you 'slicer' sample, I'm much looking forward to running your next production.
Cheers, Thomas 2010/2/11 Dave Cowden <dave.cow...@gmail.com> > 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 > >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
