Rewriting gcodepreview with Python

This was mentioned originally at:

and the Python aspect discussed at:

Starting a new thread 'cause the others were getting long.

First up is exporting SVGs — this is working now, except for the problem of SVGs having a different coordinate space from OpenSCAD and DXFs, so when exported, they are mirror-imaged top–bottom — may need to do yet another re-write to allow this to be handled in a reasonable fashion.

1 Like

Given the difficulties with SVGs, a work-around may be to instead use multiple DXFs — a separate file for each tool should make importing and cutting more straight-forward.

This however, wants that each sort of tool be defined/supported — the current project needs:

  • small square endmill
  • small V endmill (same diameter as the small square)
  • large V endmill

Obviously we would add support for at least:

  • small ball endmill
  • large ball endmill
  • large square endmill

which hopefully won’t be too onerous…

Doing that the variable definitions look like:

so we just need to add a check for each variable and if present, create/write to/close the matching file.

1 Like

Hallowe’en update — it now writes out separate files for each tool:

Next up:

Adding support for two more variables for the current project, then doing alternate versions.

1 Like

Small up-date for Veteran’s Day, and managed to get one half of the remaining modifications for vertical joinery done:

Balance and a test cut later today.

1 Like

and for Small Business Saturday we have a working file:

with usage shown at:

2 Likes

I’m curious why the bottom rabbits don’t extend into the 45 deg end cuts otherwise the base will need its corners cut out.

They do, just not very deeply — naturally, this could be set as desired by the person cutting the part.

1 Like

Starting in a re-write as a Literate Program using the LaTeX package docmfp:

Hopefully I’ll get this to a working state by the end of the weekend…

1 Like

Done with the first pass.

See:

and

Interestingly, there is a file integration option in GitBook:

but, unfortunately, it only incorporates entire files for a given code block, so there isn’t a facility to stitch together one complete file from multiple code blocks. Unfortunately, the only work-around I can think of (using a separate file for each code block, then stitching them all together) seems rather clunky and awkward.

1 Like

And it now works:

(downloaded the .dtx, updated to TeXLive 2024, made some minor edits — the Mac doesn’t complain about some underscores in \DescribeFoo{}, fixed my misunderstanding about spaces since it caused a Python indent error, and got a working set of files which has been synched back up using GitHub Desktop)

Now we see if the now-documented code will be more tractable for my actually getting something done…

1 Like

First thing is making working up some basic shapes a bit simpler, so we add a file for

cut2dshapes

a prototype of which was initially developed in OpenSCAD Graph Editor:

but this results in code which has algorithmically generated variable names:

which does not help clarity.

Other considerations for this are:

  • relationship of geometry to toolpath — arguably there should be an option for each toolpath (we will use Carbide Create as a reference implementation) which is to be supported:
    • Contour — No Offset — the default, this is already supported in the existing code
    • Contour — Outside Offset
    • Contour — Inside Offset
    • (Rectangular) Pocket — such toolpaths/geometry should include the rounding of the tool at the corners
    • Drill
    • Keyhole — a nice feature for this would be to include/model the areas which should be cleared for the sake of reducing wear on the tool and ensuring chip clearance
  • tool geometry — it should be possible to include support for specialty tooling such as dovetail cutters and to get an accurate 3D model
  • feeds and speeds — if outputting G-code it would be nice to be able to import feeds and speeds from external files such as the .csv files used for user tool libraries in Carbide Create
  • Starting and Max Depth — are there CAD programs which will make use of Z-axis information in a DXF? — would it be possible/necessary to further differentiate the DXF geometry? (currently it is getting written out separately for each toolpath in addition to one combined file)

Are there any CAD/CAM tools which could be usefully (and ideally easily) integrated?

1 Like

In the re-writing, the template/sample file was re-made:

but it is so prosaically simple and naïve, that the matching DXF:

when imported into a typical CAM tool:

cannot be readily assigned toolpaths to make the diagonal/sloping cut.

A reasonable approximation could be made by deciding how many segments one would be willing to cut/assign toolpaths for, reducing the line by that number:

Done

and duplicating and aligning and assigning toolpaths to cut each copy to the desired depth:

and then assign each line segment after the first with a suitable toolpath:

incrementing as we go along:

until we arrive at:

which once cut may be easily cleaned up with a suitable tool.

1 Like

(essentially thinking out loud here)

Working on adding support for dovetail and keyhole tools, which has been slow going, and also bogged down a bit by:

so experimenting a bit and playing around with the idea of using METAPOST to make SVG instead.

This is reasonably straight-forward:

  • install TeX, ensuring that it gets added to the filepath

  • make a .mp file like to:

    outputtemplate := “%j.svg”;
    outputformat := “svg”;
    input mpcolornames;
    beginfig(1);
    draw fullcircle scaled 72bp withcolor Blue;
    endfig;
    bye

  • call it using:

    import subprocess
    subprocess.run(“mpost test.mp”, shell=True)

which results in:

test

and best of all, imports as expected:

but of course, raises the question — is it worth introducing a second tool?

Managed to puzzle out the DXF issue:

and have found something which one needs to be aware of when working w/ PythonSCAD/PythonOpenSCAD — the .py files are compiled to .pyc files in a hidden folder, so:

“C:\Users\willa\OneDrive\Documents\GitHub\gcodepreview\gcodepreview.py”

generates:

“C:\Users\willa\OneDrive\Documents\GitHub\gcodepreview_pycache_\gcodepreview.cpython-311.pyc”

Since the .py files are now being generated from a Literate Program:

that .py file was not being seen by PythonSCAD to be evaluated/recompiled save when called — which generated errors where a module was undefined, since apparently while in the .py file, the .pyc file had not been updated to match.

1 Like