The problem is OpenSCAD can only model solid objects, not laser tool paths.

The correct model for an engraved line would be a shallow trench with a
width equal to the laser beam width. I.e. it would be a 3D object and laser
host software won't process it.

I plan to build my own laser cutter next year and if I do I will write my
own CAM software to handle STLs. In the laser world the CAM step seems to
be missed out because the kerf is so small. The design modelled in a vector
art packages is the tool path.

On Mon, 21 Oct 2019 at 12:18, kitwallace via Discuss <
discuss@lists.openscad.org> wrote:

I am trying to visualize your problem, and am having difficulty in seeing how
you can export a DXF with anything OTHER than an outline. When you export
the two files, does the 'engrave' file have a 'fill' with no 'stroke'?

My usual method is to export all parts of the object, then use something
like Inkscape to set the colours for whatever I want the laser cutter
control software to do.

OpenSCAD mailing list wrote

--
Sent from: http://forum.openscad.org/

I think that only works if you want to engrave closed, non overlapping
loops.

On Mon, 21 Oct 2019 at 15:24, kitwallace via Discuss <
discuss@lists.openscad.org> wrote:

On 21.10.19 18:09, kitwallace via Discuss wrote:

Oh, indeed. I suspect this is trying to fix the issue
that some mail providers don't accept outside mails
claiming to come from a domain that does not own the
mail domain.
(https://en.wikipedia.org/wiki/Sender_Policy_Framework)

E.g. GMX publishes the SPF info via DNS so every
compliant mail provider will not accept any mail
coming from a Nabble server claiming to be from a GMX
address. And that's a good thing.
But that also meant I could not really use the forum
interface as most people would not receive the mails.

Looks like the mail part was rolled out but the forum
part is missing.

Thunderbird shows as mail sender now as:
kitwallace via Discuss discuss@lists.openscad.org
so there the author is visible.

ciao,
Torsten.

The main issue with OpenSCAD in regards to laser cutting / engraving is
that "Solid Modeling" does not transfer well to "line art".  There's no
practical way to define a standalone "hairline" with no width.  It works ok
If the line you want corresponds to the outline of a soiid, but the
"standalone" qualifier is the problem.  You can approximate lines with
thin rectangles, but the laser will end up doing a double pass along the
two long sides no matter what.  The other issue is that lines can't really
be made to overlap.

I'm not sure if its even feasible for OpenSCAD to support such features,
since its such a fundamentally different usage from solid modelling.

On Mon, Oct 21, 2019 at 11:01 AM kitwallace via Discuss <
discuss@lists.openscad.org> wrote:

On Mon, Oct 21, 2019 at 06:14:18PM +0200, Torsten Paul via Discuss wrote:

Still, "reply-to-author" in my mailprogram is probably broken by this.

Rogier. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

I use modules with a unique name suffix _dxf to denote they make dxf files,
+stl for STLs, etc. Then I have a script to export them. Another approach
would to be make the engraving another module with a different suffix, so
they both get exported and combined. I would probably use SVG instead of
DXF as it is easier to manipulate in Python with a library.

On Mon, 21 Oct 2019 at 17:57, Hans L via Discuss discuss@lists.openscad.org
wrote:

And we all seem to have made 45 posts.

The forum has never really worked properly. I stick to the mailing list.

On Mon, 21 Oct 2019 at 22:01, kitwallace via Discuss <
discuss@lists.openscad.org> wrote:

Kinda like Logo? https://en.wikipedia.org/wiki/Logo_(programming_language)

On 10/22/19 12:17 PM, Jordan Brown via Discuss wrote:

On Tue, Oct 22, 2019 at 11:10:03AM -0700, WillAdams via Discuss wrote:

I have probably missed part of this discussion, but for me: I use
openscad to design a box for a project in 3D and then I lay the pieces
flat and send the outline to be laser-cut. One popular box has a few
markings for the buttons. I can test-fit the design in openscad and
the current processing towards something for the laser-cutting-service
is too long and error prone. I'd much rather hit "export" in openscad
and that's that. But now there are a few more steps to add the
engravings in another program. (this "too difficult" has resulted in
problems that we'd fixed by adjusting an intermediate file, getting
overwritten so that we got an old problem back).

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

OpenSCAD mailing list wrote

OpenSCAD is heavily oriented towards 3D-printing, and, to some extent,
leaves us laser cutter guys out in the cold, or at least requiring us to
make irritating workarounds.

For example, a line is useless in 3D-printing, but extremely useful in laser
cutting (google "living hinge" for a good example).

I really hope that considerations for laser cuttings will enter into the
plan for OpenSCAD, it would mean a lot to us. 3D-printing is just too slow,
has too small work area and too limited in materials available to be useful
for me.

--
Sent from: http://forum.openscad.org/

The problem is a laser doesn't cut a line with zero thickness but people
pretend it does.

You can model any object a laser can produce in OpenSCAD. What is needed is
a CAM stage for lasers that creates the tool path, just as 3D printing and
milling. For some reason the CAM stage is ignored when laser cutting.

On Thu, 24 Oct 2019 at 09:39, Troberg troberg.anders@gmail.com wrote:

On Thu, Oct 24, 2019 at 10:56:15AM +0100, nop head wrote:

The CAM stage traditionally happens in the printer driver under
windows. A program, ANY program tells windows it wants to print
something. Then together with some confguration, the printer driver
translates e.g. the color of the line into different commands for the
laser (say: red: "all the way through at 100% laser power and 10%
speed, blue: "just a scorched line at 50% laser power and 100%
speed", green: "engraved in bitmap mode").

The problem is that with those things tightly coupled to the laser
device in question, and them being closed source, it is difficult to
optimize those things. For example, at my friends' the laser will
easily cut up a single "rounded box" outline into 4 lines and for
quarter-circles and do them in the woarst possible order you can
imagine.

Optimizing the toolpath is equivalent to the travelling salesman
problem and therefore NP complete. But that doesn't mean you can't do
a meaningful optimization. An easy optimization (that 3D printer
slicers should also do!) would be to always pick the closest
linesegment. In the rounded-box example that immediately leads to the
optimal solution. Then as a post processing step, investigate the
longest non-cutting moves and see if you can improve on them. Take a
segment between two long-moves and try to insert it in the path
somewhere to see if the total non-cutting path length can be reduced.

Sorry for my rant.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Yes but laser drivers don't offset the cut by half the kerf and they don't
accept a 3D model that represents a surface with engraving as trenches
equal to the kerf and so derive a tool path running down the centre. A CAM
tool to drive a mill accepts a model of the intended result, not a tool
path. Laser artwork is just the tool path in different colours not a model
of the desired end result. OpenSCAD can produce a perfectly good model of
the end result. It can't produce tool paths.

On Thu, 24 Oct 2019 at 11:50, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

There is no reason why a proper CAM program can't convert a thin cut equal
to the kerf into a single line down the middle.

On Thu, 24 Oct 2019 at 14:02, Troberg troberg.anders@gmail.com wrote:

nophead wrote

No, quite the contrary, we rely on it having some thickness, but we can't
model it with thickness, because that would make the laser cut twice.

We do have a CAM stage. In my case, I use LightBurn, and it does create a
tool path. But, for example, a living hinge, requires lines of minimum width
(ie the kerf of the laser, typically around 0.1 mm). The way OpenSCAD works,
I would need to model them as very narrow rectangles, which causes the laser
to cut twice (slow, cuts a wider line, leaves more charring and increase the
tendency of the material to cach fire). Sure, LightBurn can remove
overlapping lines, but as it's a very narrow rectangle, they won't overlap,
they'll just be very close to each other.

--
Sent from: http://forum.openscad.org/

Except that OpenSCAD can perfectly model anything you actually produce on a
laser because it is a 3D object. There is nothing wrong with OpenSCAD. The
problem is laser CAM doesn't work the same way as milling CAM and 3D
printing CAM. It could though.

On Thu, 24 Oct 2019 at 14:13, Troberg troberg.anders@gmail.com wrote:

On Thu, Oct 24, 2019 at 02:05:12PM +0100, nop head wrote:

That's a feature that you think that a proper CAM program SHOULD have,
or maybe you know of one that DOES have this.

Us mortals have to use the tools that are available now. I don't have
time to write everything myself. Other people don't have the time to
wait for the developers (of their CAM workflow) to include such a
feature.

Roger. 

--
** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 **
**    Delftechpark 11 2628 XJ  Delft, The Netherlands.  KVK: 27239233    **
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

nophead wrote

Actually, most laser software (LightBurn, RDWorks...) do offset by half the
kerf. Not only that, they do a lot of other stuff associated with a tool
path, such as which order to do things in (fastest, inside out, all at once,
one object at the time...), burnthrough (remain still after igniting the
laser for a short while to get a clean burn through), slowing down in
corners (to avoid bounce), using less power in corners/starting/stopping to
avoid overburn, adapting to acceleration limitations of the cutter and so
on.

They don't start from a 3D model, though, for obvious reasons. Lasers don't
get 3D, they get X, Y, power, speed and that's all (slightly simplified).
So, If I want to, say, cut out a circle with an engraved X, I need to model
a circle, then two crossing lines. These needs to be in different layers in
2D.

OpenSCAD does 2D fairly good, so usually it works out, but there are two
missing primitives which would help a lot: line and point.

--
Sent from: http://forum.openscad.org/

No I don't know any CAM that does that except some slicers. I expect to
have to write it myself because the laser world has got this wrong.

On Thu, 24 Oct 2019 at 14:21, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:

On 2019-10-24 15:22, Troberg wrote:

When you do 3D printing, the 3D model is sliced (you could call that the
CAM part) and reduced to G-code which is essentially the same as "X, Y,
power, speed" with some additions for extrusion parameters. So what you
need is a kind of slicer software specialised for laser cutting.

Constructive Solid Modelling cannot use points and lines in the main
process. But points and lines could be the result of postprocessing in
some cases.

What is the typical file format you feed your laser cutter? Plain DXF?

Carsten Arnholm

On 24.10.19 15:22, Troberg wrote:

That question does come up now and again, but nobody
really took the plunge to design something that fits
into OpenSCAD.

It's not as simple as just adding line() as that
would break some of the current assumptions. However
I believe having a state with unclosed polygons is
not a problem in general as for example this happens
inside of text() too.

Just to highlight what I mean, here's some dummy code
that could model something resembling the letter L

p = [
[36,-5],[12,-5],[12,-48)],[6,-48],[6, 0],[36, 0]
];

polygon() {
point(p[0]);
for (a = [1:len(p)])
line(p[a - 1], p[a]);
}

Now that looks not very impressive as this would
work with just polygon(p) too, but text() also uses
quadratic and cubic splines. At that point it gets
much more interesting I think.

In the example above, the polygon() would also mean
that at this point the polygon is closed and could
be extruded to 3D. Without that guaranty it would be
still exportable to DXF or SVG.

ciao,
Torsten.

I like to generate my engravings in the PostScript graphic language, which allows full algorithmic numerical control of the lines, and understands fonts well.
Acrobat or Mac OS convert the file to PDF, which most laser cutters can be driven by.

--
David Gustavson
dbg@SCIzzL.com

On Thu, Oct 24, 2019, at 6:05 AM, nop head wrote:

One of my requests from a while ago was to be able to "draw" or render an elevation (or designated plane) of a 3-D model into a 2-D line art (SVG?). I could use this in two practical ways. First for documentation purposes, and secondly to be able to print "proof of fit" paper shapes to quickly check if things work.

A third way this thread reveals (unfortunately I don't own a laser) is CAM packages could be developed from this format to control various forms of cutting tools. Just like there are many STL to Gcode "slicers" around to choose from, a similar ecosystem could spring from this feature in OpenSCAD.

Whether an edge is considered a line around a shape or how a colour is interpreted, layers etc etc is left up to the CAM interpreter, of which there could be many flavours. However at least a standardized OpenSCAD approach to a 2-D rendering system would be a major step in focussing efforts to progress in this area.

Just viewing this discussion as a very basic, but most appreciative, OpenSCAD User.

Cheers, RobW

On 25 October 2019 1:37:03 am AEDT, Torsten Paul Torsten.Paul@gmx.de wrote:

You can project 3D shapes onto a 2D plane and export them as SVG or DXF
files using projection().

On Thu, 24 Oct 2019 at 22:20, Rob Ward rl.ward@bigpond.com wrote:

I have been eying LightBurn, and have been thinking that I would buy it after
changing out my m2nano board. BUt this is the first time I've heard that it
offsets by half the kerf. Which direction is the offset? Generally, when I
want to cut or engrave  line, I want it where I put it.

I also wonder why a cut out circle and an engraved X need to be in different
layers. The software I use, Inkscape, allows me to colour the strokes and to
set the greyscale values of the fill. Because the control software I use
(K40 Whisperer), will cut a red line, vector engrave a blue line, and raster
engrave a grey-scale area, it means I don't have to mess with layers. I also
don't have to mess with line thicknesses, as any red or blue line is
considered a 'stroke' and will only cut or vector engrave once, right down
the middle.

I do agree that a line() would be nice in OpenSCAD. I do a fair bit of
design work in OpenSCAD that targets a laser.

Troberg wrote

--
Sent from: http://forum.openscad.org/

I use SVG only. DXF has way too many flavours, I think. If I get a DXF file
from somewhere, it's about a 50/50 chance that Inkscape will load it. If it
doesn't I convert it to SVG using one of the online file converters.

cacb wrote

--
Sent from: http://forum.openscad.org/

cacb wrote

So, have them outside the modelling logic. They are quite useful for
markings, measurement lines and so on. They are very useful for laser
cutting. But, neither of those applications need for them to interact with
other objects, they can easily be considered as a separate "layer" which
does not interact with anything else.

cacb wrote

Doesn't matter much, any 2D vector format works. I often use SVG, as it's an
understandable format that's easy to edit by hand if needed, but pretty much
anything can work.

--
Sent from: http://forum.openscad.org/

lar3ry wrote

You can offset in either direction. It decides what is "inside" and
"outside", and then it adjusts so that the "inside" gets the correct
dimensions. The algorithm for that is basically "count from the outside,
every time you cross a shape border, it switches "inside"/"outside".
Anything which isn't a closed object isn't offset, so a single line isn't
offset, neither is a point.

--
Sent from: http://forum.openscad.org/

Thanks nop head, I have looked it up and tried it. It has been a
blind-spot of mine.

projection() will be useful, especially for the printing of templates
for various sections to try for a fit.

However the  resulting drawing is one plane (cross section or profile at
one depth), rather than an elevation (the complete model as viewed from
the side or from the top) and also has to be rendered by F6 before the
projection() which eliminates any colour information.

I am not up with the technicalities of how OpenSCAD differs in preview
(F5) as opposed to render (F6), but it would be more useful, I think, if
the projection() worked on the preview stage and collapsed coloured
sides on to a profile as an elevation. It would also be handy to be able
to define a vector space to crop how much of the model is depicted. I am
wondering if this would allow new tool path designers (like Cura for
STL->GCODE) to be developed for OpenSCAD-> SVG -> GCode.

I suspect what I am wishing for is probably not technically trivial and
maybe not worth the effort. Comments? Explanations?

RobW

On 25/10/19 8:24 am, nop head wrote:

--

Rob Ward
Lake Tyers Beach, 3909
Lake Tyers Beach Website http://www.laketyersbeach.net.au
Ubuntu Mate - A great OS https://ubuntu-mate.org/

I get a warning about zero size in OpenSCAD 2019.05

WARNING: square(size=[100, 0], ...), in file ./, line 1

TRACE: called by 'square', in file Test, line 1.

Rendering Polygon Mesh using CGAL...

UI-WARNING: No top level geometry to render

On Sat, 26 Oct 2019 at 09:43, Parkinbot rudolf@digitaldocument.de wrote:

On 26.10.19 10:53, Parkinbot wrote:

This produces pretty much what is written... nothing, no
geometry as both are closed polygons with zero area so
the Clipper processing removes them.
I'm don't know if there's an easy way to warn about this,
but it should be doable as line numbers are now passed
down into the processing.

I'm not sure what you mean. It might be possible to have
some checks/warning at export time like in 3D case, but
the challenge of implementing those primitives is probably
more a clear definition of where they are allowed and how
to get more guaranties which then allows further operations
to be applied.

Pretty much like extrude does 2D->3D there would be
operations that do Open-2D -> Solid-2D and only after
that the CSG operations would be able to produce sensible
results.

All that is probably not hugely complicated but still
requires some dedication to work out the details.

ciao,
Torsten.