2010/2/12 Dave Cowden <dave.cow...@gmail.com> > That makes sense, Thomas. > > I'll continue down the path of using OCC stuff, or re-implementing in > python to suit the needs of my application. If it becomes too cumbersome, > i'll know its time to consider wrapping another library that does it. > > Were i writing a cam package for conventional machining, i'd agree we need > to wrap something else-- though further i think in reality i'd argue a CAM > package is large enough to be its own project, dependent on pyOCC anyway. > > If the codebase i'm using becomes large that may end up being the case too. > Its debatable whether gcode generating stuff even belongs in pythonOCC. >
You're right., I don't know wether or not the gcode generation has to be a feature of pythonOCC. Right now its there because that way its compiled and packaged with > pythonOCC without a need for the overhead of a separate project, so its > purely a matter of convienience. > > I wonder-- how do we decide which things 'belong' in pythonOCC/samples or > Tools, and which ones should just be separate projects? And, are my efforts > in that category? > The samples directories aims at being a kind of 'howto/tutorial' to quickly have info about the way to do something. The Tools samples is for the rest : examples of advances uses of pythonOCC. The 'Slicer' example is in this category. Here is my suggestion : if you plan to write a pythonOCC based CAM library, you'll surely want/need a separated project. While developing this library, you will certainly learn many things about pythonOCC. You can then contribute these hints as samples that will help other users. Maybe you'll have to write general classes. If you think they can be useful for other people/projects (not necessary related to CAM), then it can be added as a pythonOCC subpackage (at the same level as PAF, KBE, Topology etc.), or inside the subpackages, if you improve parts of existing code. In the meantime, untill you decide to open an account on GoogleCode to host your project, you can use the /Tools directory. In brief, we're completely open to your efforts/contributions and ready to help you as far as we can. All the best, Thomas > > > On Fri, Feb 12, 2010 at 11:57 AM, Thomas Paviot <tpav...@gmail.com> wrote: > >> 2010/2/12 Dave Cowden <dave.cow...@gmail.com> >> >> 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 don't want pythonOCC to depend upon too many dependencies. Adding >> dependencies means increasing complexity. However, it's sometimes required >> to extend the functional scope quickly (by just using something already >> working). So here is my opinion: >> - there's no limit about dependencies that are python modules or packages. >> For instance Traits, wxPython, PyQt, simpy etc. are dependencies but they're >> pretty well packaged and easy to install, and it's pythonic to use other >> python packages. >> - some C++ libraries may be linked to pythonOCC. I used the following >> 'rule' : if the C++ library has to be completely integrated to pythonOCC, so >> let's develop a wrapper. For instance, the GEOM and SMEH libraries are >> developed with C++ and all the classes/methods are required. It would have >> been too long to port the code to python, so I wrapped the libraries. >> - if the library aims at being partially used from pythonOCC, i.e. a small >> or very small part of code is really useful, so it's better to port the >> C/C++ code to python. It's feasible if the number of lines of code to port >> is not too important. >> >> Thomas >> >> >>> 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 >>> >>> >> >> _______________________________________________ >> 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
