> You're right., I don't know wether or not the gcode generation has to be a
> feature of pythonOCC.
There is no place for g-code generation in "core" pythonOCC.
But as a project I do think it is an _awesome_ idea.
Look, the debate on whether to include these things into pythonOCC is a
non-issu
In general its interesting to look at how the Django projects is organized.
There is the core django project, than lots of other projects, additional
components that allow you to build up apps quickly.
That's a simple and practical way of organizing efforts.
-jelle
On Feb 12, 2010, at 6:09 PM, D
> 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 s
2010/2/12 Dave Cowden
> 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
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,
2010/2/12 Dave Cowden
> 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
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
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/thoug
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
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 versi
Hi Jelle,
I haven't used pythonOCC for much other than experimenting yet. I hope
to remedy that very soon. I have been using python more and more at work
as an additional tool in my arsenal of CADCAM tricks. Whenever I see a
method that looks interesting, I make a note of it and file it for
fut
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
> 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!
Cool! Keep us posted!
-jelle
___
Pythonocc-users mailing list
Pythonocc-users@gna.org
https://mail.g
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 wrote:
> Hi guys. Would a 'pocketing' routine like this help?:
>
> http://code.google.com/p/libarea/
>
> I use routines like
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) machi
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
> Oh i'm sorry, that was Jelle :( Sorry about that.
>
>
> On Thu, Feb 11, 2010 at 11:34 AM, Dave Cowden wrote:
>
>> Hi, Thomas, thank
> Distance is ideally user-variable. When you build an object, sometimes you
> want very dense spacing because you want a very strong object, and sometime
> you dont care so you space it very widely.
I absolutely love this idea of a space filling algorithm, that would be a
massive advantage…
I
Hi, Jelle:
thank you for the input.
>Why the hatch? What is the distance between your scanlines?
Distance is ideally user-variable. When you build an object, sometimes you
want very dense spacing because you want a very strong object, and sometime
you dont care so you space it very widely.
Anot
> Hi, Thomas, thanks!
Thanks for the compliment ;')
> 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 E
Oh i'm sorry, that was Jelle :( Sorry about that.
On Thu, Feb 11, 2010 at 11: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
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 actual
> 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 ( sa
22 matches
Mail list logo
