You will want a higher convexity on that

On Thu, 22 Apr 2021, 17:29 Jordan Brown, openscad@jordan.maileater.net
wrote:

On 21/04/2021 18:16, A. Craig West wrote:

I think that is the major problem. However in my quest to overcome that,
in examining what I need for 2.5d 3 axis milling, I've decided to use
'projection', slicing the 3d model at various levels. However, the
levels required for slicing, are not the depths required for machining.
I was translating in x/y each projection and saving it as a single dxf
file, then realigning them in my 2d drawing package, going around the
houses to get back to where i started, so to speak.

I'm wondering if there is a more automated method, whereby each
individual projection could be saved as a dxf, (without translating them
in x/y plane) then I could simply import them into the same drawing in
my 2d drawing package, without having to realign them. I'm thinking it
may require a separate program to parse the scad file, identify the
commented out projections, uncomment them one by one, running openscad
via command line for each  projection, and saving as a uniquely named
dxf. . A bit convoluted, but doable. I could also include other
information, too, tool type, for example. I'm not sure if it is worth
the effort, I see it more as a journey, rather than the destination. At
the ed of the day, there is still a fair bit of manual adjustments that
need to be made, in getting from a simple drawing to final object, it is
not the same as profile milling an stl file.

//for dxf drawing
//projection(cut=true) translate([0,0,100])first_op();  // z- 100 T15
//projection(cut=true) translate([0,0,90.1])first_op(); // stand off 
T15 z-95
//projection(cut=true) translate([0,0,40])first_op(); // square T15 z-90
//projection(cut=true) translate([0,0,24.9])first_op(); // notch T15 z-25
//projection(cut=true) translate([0,0,.1])first_op(); // lip  T21 z-10

On 4/25/2021 4:57 AM, Ray West wrote:

You don't want to externally parse the .scad file.  That could be a
nightmare.  But you don't need to.  OpenSCAD knows how to parse them,
and it'll do it right.  You just need to use OpenSCAD to derive the
list, and then to select the desired layer.

Something like so:

// Display/operation mode
mode = "3d";    // [ 3d, all, one, list ]
// Which layer to select if mode="one"
layer = 0;    // [0:0.1:200]
// List of layers
layers = [ 100, 90.1, 40, 24.9, 0.1 ];

if (mode=="3d") {
    first_op();
} else if (mode == "list") {
    for (z = layers) {
        echo("LAYER", z);
    }
} else if (mode == "all") {
    for (z = layers) {
        translate([0,0,z])
            projection(cut=true)
            translate([0,0,-z])
            first_op();
    }
} else if (mode == "one") {
    projection(cut=true) translate([0,0,-layer]) first_op();
}

You write an external script that runs openscad with -Dmode="list"
(which, if you're in a UNIX shell, would be something like
-Dmode="list").  You have the script collect the output, looking for
lines that look like

ECHO: "LAYER", 100

and stripping off everything before the comma and space.  Your then have
it repeatedly execute openscad with -Dmode="one" -Dlayer=N, where N is
the successive layer values, having it generate a DXF file.

Congratulations, you now have your N DXF files.

Note that it's rigged to let you use the Customizer to play with the
options manually.

JordanBrown wrote

I'm probably missing something, but wouldn't it be easier to run an STL or
3MF though a slicer and then write an external program to parse the GCode
layer by layer?

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

On 4/25/2021 8:47 PM, lar3ry wrote:

GCode is a toolpath, and your CAM pipeline is going to want something
more like a line drawing.  You'd have to figure out that those hundreds
or thousands of tool movements total up to a a 2D shape, that the CAM
pipeline can then turn into its own totally different toolpaths.

JordanBrown wrote

OK, so what about something like a slicer designed for MSLA 3D printing?
Perhaps something like Chitubox? It's binary and not open source, but are
there other, similar programs that give you a layer by layer representation
that would be easier to parse than an STL?

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

On Monday 26 April 2021 06:58:27 lar3ry wrote:

Sure. I slice with cura, which has a preview mode where you can watch it
build your project or take it apart if you  pull the slider backwards,
or an enterprising bash author could knock out a script that could split
the resulting gcode up into layer by layer files if you need that level
of granularity. But tall projects will generate hundreds of files doing
that.

Cheers, Gene Heskett

"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.

• Louis D. Brandeis
  Genes Web page http://geneslinuxbox.net:6309/gene

Something like a slicer would work, after all that is what
projection(cut=true) does. If i sliced it in Cura, say, then I can get
the gcode for a specific layer height, but it would need parsing a large
file of possibly thousands of layers to get the four or five usually
needed. The Cura g-code is for laying down the path for a filament of a
finite width. I would need the outline of the final printed path,
including the width of the layer as a dxf file. The Cura gcode would
need a lot of maths applied to get back to the outline of the object,
convert it to dxf or hpgl format or if going straight to cnc machinable
g-code would need to add the tool offsets, which may not be known at
this stage.

I can directly machine stl files anyway, more or less automatically, but
although that process is maybe good enough for wood, or ornamental work,
there is generally not precise enough control of the cutter paths and
speeds for what I need. I possibly have an irrational mistrust of stl
format for precision work.

On 26/04/2021 11:58, lar3ry wrote: