Maybe the libarea code could be a good inspiration for a pythonOCC
version. It might also be good to just show folks how it could be set up
as is, until that version is ready.
One thing that I found with using the pure python Pycam code was that it
became almost unusable from the standpoint of time. 20 to 30 minutes
waiting for it to generate code was not a good thing. I usually run back
and forth from my computer and the milling machine doing revisions.
Thanks,
Dan
On 2/12/10 8:40 AM, Dave Cowden wrote:
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
<mailto: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
<mailto: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 <mailto: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 <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
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 <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
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 <mailto:Pythonocc-users@gna.org>
https://mail.gna.org/listinfo/pythonocc-users
_______________________________________________
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
