PE
Pascal Eberhard
Thu, Oct 15, 2015 10:18 PM
Hi everybody,
I discovered OpenSCAD and CNC milling machine a year ago. Following a
process of trial and errors (lot of them...), I started to carve wood,
Plexiglas and aluminum to make parts for robots (that's my spare time
hobby currently :p). During this time, I have been working on a carving
'plugin' for OpenSCAD. The need was to have an reliable work-flow to
make parts using a CNC milling machine using OpenSCAD.
The goal is to try to simplify the creation of parts with CNC milling
machine and to render them as accurately as possible during design
steps. As well, CNC milling machines have some specificities which would
benefit to be integrated:
- The notion of workpiece of a specific material, size and the
positioning of parts in it.
- Specific G-Code move operations to carve the workpiece or tool
management like spindle speed, move speed or tool change.
- Multiple pass depending on material, cutting tool and CNC machine.
- Multiple tools (drill-bits for holes, end-mills with different
diameter for carving, end-mills with head angle to mark folding lines,
...).
The work-flow could be decomposed in the following steps:
-
When creating and debugging parts, the View -> Carving -> "Render
Milling Path" mode displays the volume traveled by the CNC milling tools
following the programmed moves.
-
Once the parts are close to be finished, the View -> Carving ->
"Render Carving Result" mode displays accurately the volume removed from
the workpiece to carve the parts. Positions of the parts on the
workpiece can be optimized too.
-
Finally parts can be extracted from the workpiece using View ->
Carving -> "Extract Parts for Assembly" mode. Once identified, parts are
extracted from the workpiece and assembled together to render the final
result. It is then possible to check how well the parts fit together.
-
Export the parts into G-Code via File -> Export -> "Export as NGC..."
for manufacturing using LinuxCNC and CNC milling machine!
-
And... enjoy end result.
Development is in progress and there is still room for improvement, but
at last, the code is finally stable enough to start sharing it with the
community, so here it is:
Source code is available here:
https://github.com/peberhard/openscad/tree/carving-plugin
Build information, documentation and examples are available there:
https://github.com/peberhard/openscad-carving-plugin-doc-examples
Thanks for your feedback,
Pascal
Hi everybody,
I discovered OpenSCAD and CNC milling machine a year ago. Following a
process of trial and errors (lot of them...), I started to carve wood,
Plexiglas and aluminum to make parts for robots (that's my spare time
hobby currently :p). During this time, I have been working on a carving
'plugin' for OpenSCAD. The need was to have an reliable work-flow to
make parts using a CNC milling machine using OpenSCAD.
The goal is to try to simplify the creation of parts with CNC milling
machine and to render them as accurately as possible during design
steps. As well, CNC milling machines have some specificities which would
benefit to be integrated:
* The notion of workpiece of a specific material, size and the
positioning of parts in it.
* Specific G-Code move operations to carve the workpiece or tool
management like spindle speed, move speed or tool change.
* Multiple pass depending on material, cutting tool and CNC machine.
* Multiple tools (drill-bits for holes, end-mills with different
diameter for carving, end-mills with head angle to mark folding lines,
...).
The work-flow could be decomposed in the following steps:
1. When creating and debugging parts, the View -> Carving -> "Render
Milling Path" mode displays the volume traveled by the CNC milling tools
following the programmed moves.
2. Once the parts are close to be finished, the View -> Carving ->
"Render Carving Result" mode displays accurately the volume removed from
the workpiece to carve the parts. Positions of the parts on the
workpiece can be optimized too.
3. Finally parts can be extracted from the workpiece using View ->
Carving -> "Extract Parts for Assembly" mode. Once identified, parts are
extracted from the workpiece and assembled together to render the final
result. It is then possible to check how well the parts fit together.
4. Export the parts into G-Code via File -> Export -> "Export as NGC..."
for manufacturing using LinuxCNC and CNC milling machine!
5. And... enjoy end result.
Development is in progress and there is still room for improvement, but
at last, the code is finally stable enough to start sharing it with the
community, so here it is:
Source code is available here:
https://github.com/peberhard/openscad/tree/carving-plugin
Build information, documentation and examples are available there:
https://github.com/peberhard/openscad-carving-plugin-doc-examples
Thanks for your feedback,
Pascal
B
bmsleight
Thu, Oct 15, 2015 10:31 PM
Wow - very cool, Great to keep the workflow within OpenSCAD.
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14139.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
Wow - very cool, Great to keep the workflow within OpenSCAD.
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14139.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
JL
Jean-Paul Louis
Thu, Oct 15, 2015 11:23 PM
Hi Pascal,
I beg to differ. The translation of the 3D model into a CNC program DOES NOT belong
into OpenSCAD.
Let me explain:
-
OpenSCAD is a modeling tool that create the object you need. So it doesn’t know what
will be the tool used for manufacturing your object.
-
The translation into a tool programming belongs to the CAM (Computer Aided Manufacturing)
software which could be a plug-in into OpenSCAD, but never part of the core program.
-
You want CNC conversion, someone else will want 3D printing software, and someone else
will want molding software, and so on.
It is better to have a clean interface like now with STL export.
My $0.02,
Jean-Paul
AC9GH
Hi Pascal,
I beg to differ. The translation of the 3D model into a CNC program DOES NOT belong
into OpenSCAD.
Let me explain:
- OpenSCAD is a modeling tool that create the object you need. So it doesn’t know what
will be the tool used for manufacturing your object.
- The translation into a tool programming belongs to the CAM (Computer Aided Manufacturing)
software which could be a plug-in into OpenSCAD, but never part of the core program.
- You want CNC conversion, someone else will want 3D printing software, and someone else
will want molding software, and so on.
It is better to have a clean interface like now with STL export.
My $0.02,
Jean-Paul
AC9GH
> On Oct 15, 2015, at 6:18 PM, Pascal Eberhard <pascal.eberhard@38plumes.fr> wrote:
>
>
R
runsun
Fri, Oct 16, 2015 12:04 AM
@Pascal, really cool thing you did there. Although I tend to agree with
Jean-Paul that this would probably be a plug-in (user-space lib) instead of
being the core, exploring more directions of application is, IMHO, always a
good thing.
If I have time in the future, I'd like to develop a 3D CNC and use Openscad
to carve some 3D wood objects for me ... far, far dream ...
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14143.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@Pascal, really cool thing you did there. Although I tend to agree with
Jean-Paul that this would probably be a plug-in (user-space lib) instead of
being the core, exploring more directions of application is, IMHO, always a
good thing.
If I have time in the future, I'd like to develop a 3D CNC and use Openscad
to carve some 3D wood objects for me ... far, far dream ...
-----
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14143.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
PE
Pascal Eberhard
Fri, Oct 16, 2015 12:06 AM
Hi Jean-Paul,
I understand your point of view as it is possible to do 3D printing from
STL export for example. Unfortunately it is quite hard to do proper
generation of G-Code from STL for CNC milling machine, hence the need of
a more CNC friendly modeling tool. This carving 'plugin' proposes a way
of modeling object with no restriction of the usage, but this way of
modeling offers the possibility to do clean export of G-Code for CNC.
The notion of 'plugin' is a bit blurred today, but I agree that this
carving plugin is not a core functionality of OpenSCAD. A way to enable
this functionality at runtime (via the notion of feature maybe?) would
make sense.
Pascal
On 2015-10-16 01:23, Jean-Paul Louis wrote:
Hi Pascal,
I beg to differ. The translation of the 3D model into a CNC program
DOES NOT belong
into OpenSCAD.
Let me explain:
-
OpenSCAD is a modeling tool that create the object you need. So it
doesn’t know what
will be the tool used for manufacturing your object.
-
The translation into a tool programming belongs to the CAM
(Computer Aided Manufacturing)
software which could be a plug-in into OpenSCAD, but never part of
the core program.
-
You want CNC conversion, someone else will want 3D printing
software, and someone else
will want molding software, and so on.
It is better to have a clean interface like now with STL export.
My $0.02,
Jean-Paul
AC9GH
Hi Jean-Paul,
I understand your point of view as it is possible to do 3D printing from
STL export for example. Unfortunately it is quite hard to do proper
generation of G-Code from STL for CNC milling machine, hence the need of
a more CNC friendly modeling tool. This carving 'plugin' proposes a way
of modeling object with no restriction of the usage, but this way of
modeling offers the possibility to do clean export of G-Code for CNC.
The notion of 'plugin' is a bit blurred today, but I agree that this
carving plugin is not a core functionality of OpenSCAD. A way to enable
this functionality at runtime (via the notion of feature maybe?) would
make sense.
Pascal
On 2015-10-16 01:23, Jean-Paul Louis wrote:
> Hi Pascal,
>
> I beg to differ. The translation of the 3D model into a CNC program
> DOES NOT belong
> into OpenSCAD.
>
> Let me explain:
> - OpenSCAD is a modeling tool that create the object you need. So it
> doesn’t know what
> will be the tool used for manufacturing your object.
>
> - The translation into a tool programming belongs to the CAM
> (Computer Aided Manufacturing)
> software which could be a plug-in into OpenSCAD, but never part of
> the core program.
>
> - You want CNC conversion, someone else will want 3D printing
> software, and someone else
> will want molding software, and so on.
>
> It is better to have a clean interface like now with STL export.
>
> My $0.02,
> Jean-Paul
> AC9GH
>
>
>> On Oct 15, 2015, at 6:18 PM, Pascal Eberhard
>> <pascal.eberhard@38plumes.fr> wrote:
>>
>>
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
PE
Pascal Eberhard
Fri, Oct 16, 2015 12:21 AM
Hi Runsun,
Actually I started with a user-space library :-). Unfortunately I
quickly reached a wall due to the complexity of the algorithms, hence
the creation of this c++ plugin. However the fact that it is a c++
plugin (still a blurry definition :p) does not make it 'core' as it
could simply not disabled by default, with a preference activating it
for example.
Pascal
On 2015-10-16 02:04, runsun wrote:
@Pascal, really cool thing you did there. Although I tend to agree with
Jean-Paul that this would probably be a plug-in (user-space lib)
instead of
being the core, exploring more directions of application is, IMHO,
always a
good thing.
If I have time in the future, I'd like to develop a 3D CNC and use
Openscad
to carve some 3D wood objects for me ... far, far dream ...
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2
, git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context:
http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14143.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hi Runsun,
Actually I started with a user-space library :-). Unfortunately I
quickly reached a wall due to the complexity of the algorithms, hence
the creation of this c++ plugin. However the fact that it is a c++
plugin (still a blurry definition :p) does not make it 'core' as it
could simply not disabled by default, with a preference activating it
for example.
Pascal
On 2015-10-16 02:04, runsun wrote:
> @Pascal, really cool thing you did there. Although I tend to agree with
> Jean-Paul that this would probably be a plug-in (user-space lib)
> instead of
> being the core, exploring more directions of application is, IMHO,
> always a
> good thing.
>
> If I have time in the future, I'd like to develop a 3D CNC and use
> Openscad
> to carve some 3D wood objects for me ... far, far dream ...
>
>
>
>
> -----
>
> $ Runsun Pan, PhD
>
> $ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2
> , git );
>
> $ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
>
>
>
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14143.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
R
runsun
Fri, Oct 16, 2015 12:48 AM
@ Pascal, I see. I think I understand the wall you are talking about.
Is it fair to say that your modification to the Openscad itself is to allow
Openscad to take your plugin ? This gives me an idea: maybe "requesting the
plugin capability" is a better approach than "requesting the plugin
capability to take specific plugin" like yours ?
I imagine that a "general plugin capability" would be more acceptable to the
development team and the community.
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14147.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
@ Pascal, I see. I think I understand the wall you are talking about.
Is it fair to say that your modification to the Openscad itself is to allow
Openscad to take your plugin ? This gives me an idea: maybe "requesting the
plugin capability" is a better approach than "requesting the plugin
capability to take specific plugin" like yours ?
I imagine that a "general plugin capability" would be more acceptable to the
development team and the community.
-----
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2 , git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context: http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14147.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
PE
Pascal Eberhard
Fri, Oct 16, 2015 1:33 AM
Hi Runsun,
Yes, the reason I am sharing this work on the carving plugin now is
exactly to have those kind of discussion.
The notion of plugin, in a strict sense suggest that OpenSCAD should
have a public API for plugins and link them dynamically or at runtime. I
expect it is a complex work (definition of the API, implementation of
the loading mechanism) and will add constraints to OpenSCAD architecture
and development to keep the API and its implementation stable.
A lighter interpretation could be to define a "carving feature" which
can be activated at runtime.
Pascal
On 2015-10-16 02:48, runsun wrote:
@ Pascal, I see. I think I understand the wall you are talking about.
Is it fair to say that your modification to the Openscad itself is to
allow
Openscad to take your plugin ? This gives me an idea: maybe "requesting
the
plugin capability" is a better approach than "requesting the plugin
capability to take specific plugin" like yours ?
I imagine that a "general plugin capability" would be more acceptable
to the
development team and the community.
$ Runsun Pan, PhD
$ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2
, git );
$ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
--
View this message in context:
http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14147.html
Sent from the OpenSCAD mailing list archive at Nabble.com.
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Hi Runsun,
Yes, the reason I am sharing this work on the carving plugin now is
exactly to have those kind of discussion.
The notion of plugin, in a strict sense suggest that OpenSCAD should
have a public API for plugins and link them dynamically or at runtime. I
expect it is a complex work (definition of the API, implementation of
the loading mechanism) and will add constraints to OpenSCAD architecture
and development to keep the API and its implementation stable.
A lighter interpretation could be to define a "carving feature" which
can be activated at runtime.
Pascal
On 2015-10-16 02:48, runsun wrote:
> @ Pascal, I see. I think I understand the wall you are talking about.
>
> Is it fair to say that your modification to the Openscad itself is to
> allow
> Openscad to take your plugin ? This gives me an idea: maybe "requesting
> the
> plugin capability" is a better approach than "requesting the plugin
> capability to take specific plugin" like yours ?
>
> I imagine that a "general plugin capability" would be more acceptable
> to the
> development team and the community.
>
>
>
>
>
> -----
>
> $ Runsun Pan, PhD
>
> $ libs: doctest , faces ( git ), offline doc ( git ),runscad.py( 1 , 2
> , git );
>
> $ tips: hash( 1 , 2 ), sweep , var , lerp , animGif
>
>
>
>
>
>
> --
> View this message in context:
> http://forum.openscad.org/OpenSCAD-carving-plugin-tp14136p14147.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
WA
William Adams
Wed, Jul 18, 2018 2:36 PM
Somehow I missed this when it first came through my e-mail, and then I
found it and added it to:
https://www.shapeoko.com/wiki/index.php/OpenSCAD#CNC_direct_interfaces
and then recently came across it again, and am hoping that it my be
applicable to my efforts to work up joints and cutting paths for boxes:
http://community.carbide3d.com/t/sharing-carbide-create-dovetail-files/9371
One thing which I've become curious about --- could one use OpenSCAD as a
previewer for a CNC toolpath? Given an arbitrary shape (the tool
definition) could one then subtract from the stock that shape moving along
a path? Forgive me if there's some obvious command for this (just point me
at the manual and I'll try to understand it better).
William
Somehow I missed this when it first came through my e-mail, and then I
found it and added it to:
https://www.shapeoko.com/wiki/index.php/OpenSCAD#CNC_direct_interfaces
and then recently came across it again, and am hoping that it my be
applicable to my efforts to work up joints and cutting paths for boxes:
-
http://community.carbide3d.com/t/sharing-carbide-create-dovetail-files/9371
- http://community.carbide3d.com/t/cnc-finger-joint-box/8880
One thing which I've become curious about --- could one use OpenSCAD as a
previewer for a CNC toolpath? Given an arbitrary shape (the tool
definition) could one then subtract from the stock that shape moving along
a path? Forgive me if there's some obvious command for this (just point me
at the manual and I'll try to understand it better).
William
WA
William Adams
Wed, Jul 18, 2018 2:48 PM
Interesting this was discussed here previously:
http://forum.openscad.org/nc-code-verification-td11373.html
William
