discuss@lists.openscad.org

OpenSCAD general discussion Mailing-list

View all threads

ot, how to generate g code for machining boxes from sheet material

RW
Raymond West
Tue, Apr 12, 2022 4:12 PM

For something as simple as a box, it is easy enough to programmatically
generate g-code in your favourite programming language. It is far more
difficult to try to automatically generate it from an stl/dxf, unless
you give additional information. (Although for some stl shapes a rotary
acis can often be used, and for simple profiling/pocketing then a dxf is
useable. The attached jpg is more or less the minimum information that
you will need for a free standing program  (written in free basic, three
years ago, primarily for making cases for dial gauge indicators and such
like - different values of course.)

For 3d printing, since the slicer does the conversion, and fdm basically
lays down threads/lines, then working from a graphics file
(stl/whatever) is relatively straight forward, although 12 years ago, i
was also generating g-code directly, since not every shape is 'sliceable'.

I guess, if you really wanted to be awkward, and use openscad/whatever,
then maybe apply offsets and generate the paths into g code. That can be
done, as we've mentioned before, using echo statements, and parse them
to remove the characters not needed, or, since the scad file is plain
text, do it some other way with a more specialised program, along the
lines that a union is a profile, and a difference is a pocket but
whatever, it is bound to be a bit cludgy - no such thing as a free lunch.

Best wishes,

Ray

On 12/04/2022 16:05, William F. Adams via Discuss wrote:


OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org

For something as simple as a box, it is easy enough to programmatically generate g-code in your favourite programming language. It is far more difficult to try to automatically generate it from an stl/dxf, unless you give additional information. (Although for some stl shapes a rotary acis can often be used, and for simple profiling/pocketing then a dxf is useable. The attached jpg is more or less the minimum information that you will need for a free standing program  (written in free basic, three years ago, primarily for making cases for dial gauge indicators and such like - different values of course.) For 3d printing, since the slicer does the conversion, and fdm basically lays down threads/lines, then working from a graphics file (stl/whatever) is relatively straight forward, although 12 years ago, i was also generating g-code directly, since not every shape is 'sliceable'. I guess, if you really wanted to be awkward, and use openscad/whatever, then maybe apply offsets and generate the paths into g code. That can be done, as we've mentioned before, using echo statements, and parse them to remove the characters not needed, or, since the scad file is plain text, do it some other way with a more specialised program, along the lines that a union is a profile, and a difference is a pocket but whatever, it is bound to be a bit cludgy - no such thing as a free lunch. Best wishes, Ray On 12/04/2022 16:05, William F. Adams via Discuss wrote: > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email todiscuss-leave@lists.openscad.org
RW
Ray West
Tue, Apr 12, 2022 11:17 PM

grbl runs on the mega328 - an 8 bit controller. It is a cheap system,
and it is expecting a lot if it is thought that it would be fast enough 
to process macros and other more advanced g-code methods. You have to
pre-process the g-code to expand the loops etc., as the grbl wiki
suggests. The controller interprets the gcode to stepper/servo steps and
direction, and that is about as much as it can do, and that is with
relatively slow moving axis. The solution is  quite simple - either
spend the cash to get the system that you think you need, or get over
the problems by either learning to write your own software, or adapt
spreadsheets/whatever to do the task. It will not be a turnkey solution.
There is a reason why solid works et-al are priced as they are, so the
time you will spend in trying to find an existing off the shelf, low
cost solution tailored to your specific machine, would be better spent
in some other way.

It is obvious to me that openscad will not provide the solution you are
looking for, although I and others use it as part of the solutions to
our problems, hence I have labelled my posts as ot.

On 12/04/2022 17:12, Raymond West wrote:

For something as simple as a box, it is easy enough to
programmatically generate g-code in your favourite programming
language. It is far more difficult to try to automatically generate it
from an stl/dxf, unless you give additional information. (Although for
some stl shapes a rotary acis can often be used, and for simple
profiling/pocketing then a dxf is useable. The attached jpg is more or
less the minimum information that you will need for a free standing
program (written in free basic, three years ago, primarily for making
cases for dial gauge indicators and such like - different values of
course.)

For 3d printing, since the slicer does the conversion, and fdm
basically lays down threads/lines, then working from a graphics file
(stl/whatever) is relatively straight forward, although 12 years ago,
i was also generating g-code directly, since not every shape is
'sliceable'.

I guess, if you really wanted to be awkward, and use
openscad/whatever, then maybe apply offsets and generate the paths
into g code. That can be done, as we've mentioned before, using echo
statements, and parse them to remove the characters not needed, or,
since the scad file is plain text, do it some other way with a more
specialised program, along the lines that a union is a profile, and a
difference is a pocket but whatever, it is bound to be a bit cludgy -
no such thing as a free lunch.

Best wishes,

Ray

On 12/04/2022 16:05, William F. Adams via Discuss wrote:


OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org


OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org

grbl runs on the mega328 - an 8 bit controller. It is a cheap system, and it is expecting a lot if it is thought that it would be fast enough  to process macros and other more advanced g-code methods. You have to pre-process the g-code to expand the loops etc., as the grbl wiki suggests. The controller interprets the gcode to stepper/servo steps and direction, and that is about as much as it can do, and that is with relatively slow moving axis. The solution is  quite simple - either spend the cash to get the system that you think you need, or get over the problems by either learning to write your own software, or adapt spreadsheets/whatever to do the task. It will not be a turnkey solution. There is a reason why solid works et-al are priced as they are, so the time you will spend in trying to find an existing off the shelf, low cost solution tailored to your specific machine, would be better spent in some other way. It is obvious to me that openscad will not provide the solution you are looking for, although I and others use it as part of the solutions to our problems, hence I have labelled my posts as ot. On 12/04/2022 17:12, Raymond West wrote: > > For something as simple as a box, it is easy enough to > programmatically generate g-code in your favourite programming > language. It is far more difficult to try to automatically generate it > from an stl/dxf, unless you give additional information. (Although for > some stl shapes a rotary acis can often be used, and for simple > profiling/pocketing then a dxf is useable. The attached jpg is more or > less the minimum information that you will need for a free standing > program (written in free basic, three years ago, primarily for making > cases for dial gauge indicators and such like - different values of > course.) > > For 3d printing, since the slicer does the conversion, and fdm > basically lays down threads/lines, then working from a graphics file > (stl/whatever) is relatively straight forward, although 12 years ago, > i was also generating g-code directly, since not every shape is > 'sliceable'. > > I guess, if you really wanted to be awkward, and use > openscad/whatever, then maybe apply offsets and generate the paths > into g code. That can be done, as we've mentioned before, using echo > statements, and parse them to remove the characters not needed, or, > since the scad file is plain text, do it some other way with a more > specialised program, along the lines that a union is a profile, and a > difference is a pocket but whatever, it is bound to be a bit cludgy - > no such thing as a free lunch. > > Best wishes, > > Ray > > On 12/04/2022 16:05, William F. Adams via Discuss wrote: >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email todiscuss-leave@lists.openscad.org > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email todiscuss-leave@lists.openscad.org