I understand and agree about porting to pure python. I think we'd probably want to avoid another library dependency, though. Thomas/Jelle what do you guys think? My assumption is that we want to avoid external dependencies, especially when OCC already has something similar.
I guess my hope/thought was that the algorithm itself could be ported, but that most of the heavy lifting it does is already available in OCC functions. For example offsetting curves, finding intersections, etc etc are already available, we might just have to make the algo more intelligent. I'm also needing a bit more flexibilty because the toolpaths i need to create are not for a tool, they are for a rapid prototyping (additive ) machine. So for example, I dont actually want to do the entire pocket, i need to offset a few cuves and then create a sparse cross-hatching kind of thing.... My experience is in line with yours about pure python. There is already a tool called skeinforge that is pure python and converts STL files to gcode. It runs on the order of 1/2 hour on my laptop, and using pyOCC I can perform the same operation in under 1 minute. But i love python for the glue code. That's probably why i'm here. OCC is a great library that's fast and expansive, but the python binding is perfect for custom tools and addins. On Fri, Feb 12, 2010 at 11:31 AM, Dan Falck <dfa...@verizon.net> wrote: > Hi Dave, > > I don't know what it would take to integrate it with pythonOCC, but it > already has python bindings that are pretty straightforward. Somehow, I > don't think you would want to convert the whole thing to python, since it > would slow things down. I have used it from HeeksCNC (it's intended > application) and as a stand alone module on my Mac. I have done some CNC > programming in which I just used the modules that Heeks came up with from > the terminal and created some useful machining code. I think Dan Heeks did a > good thing in making all the separate machining modules into individual > projects. He has kurve -which is for simple profiling, libactp- adaptive > roughing, libarea- pocketing, and then he adapted Pycam for surfacing. > Pycam, being written in pure python is pretty slow at generating gcode. > > I think there is a test script included with the project that should be > pretty helpful in showing what input format it needs. You could probably > just do something like 'import libarea' and use it from your application. > > Dan > > > > On 2/12/10 8:04 AM, Dave Cowden wrote: > > Hi Dan, > > Yes that logo looks like a fairly good test case. It has some very sharp > small portions. > > What do you think the possibility would be to "pyOCC-size" that algorithm > so that we can use it convieniently in conjunction with the OCC objects? > > IE, how difficult would it be to make a python version of the library > that would operation on a wire object? That'd save me some work. > > Last night i spent some time on a routine to convert an edge, wire, and > gp_Pnt into code-- these were fairly easy, because I copped out and handled > only edges that have lines as the curve. But with another few hours i > should be able to handle curves of type circle and ellipse and convert them > to G2/G3 ( which, by the way, is something very very few cam packages out > there do today). > > After that, my next step would be the last one i need for my slicer-- to > add 'convert a face to gcode'. Doing this part would need the offset > algorithm available... > > > > On Fri, Feb 12, 2010 at 10:10 AM, Dan Falck <dfa...@verizon.net> wrote: > >> Hi Dave, >> >> I will try and attach a screenshot. I think that this lib does pretty >> well. I used it for pocketing this logo and was pretty pleased with the >> results. I haven't used it extensively, but so far so good. >> >> Thanks, >> Dan >> >> >> >> On 2/12/10 4:14 AM, Dave Cowden wrote: >> >> Hey, Dan: >> >> How well does this routine handle geometries for which offset curves >> self or boundary intersect? pyOCC actually has a very easy to use tool to >> do the offsets, but it runs into trouble when the curves self-intersect-- >> essentially it just punts and throws an error. >> >> So, with pyOCC i think i'd have to manually offset each curve and then >> find the intersections, so that I can deal with what happens when the >> geometry is odd.... >> >> On Thu, Feb 11, 2010 at 10:48 PM, 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>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 >>> listpythonocc-us...@gna.orghttps://mail.gna.org/listinfo/pythonocc-users >>> >>> >>> _______________________________________________ >>> Pythonocc-users mailing list >>> Pythonocc-users@gna.org >>> https://mail.gna.org/listinfo/pythonocc-users >>> >>> >> >> _______________________________________________ >> Pythonocc-users mailing >> listpythonocc-us...@gna.orghttps://mail.gna.org/listinfo/pythonocc-users >> >> >> _______________________________________________ >> Pythonocc-users mailing list >> Pythonocc-users@gna.org >> https://mail.gna.org/listinfo/pythonocc-users >> >> > > _______________________________________________ > Pythonocc-users mailing > listpythonocc-us...@gna.orghttps://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
