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.
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:
Obviously we would add support for at least:
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.
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.
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.
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.
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…
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.
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…
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:
Are there any CAD/CAM tools which could be usefully (and ideally easily) integrated?
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.
(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:
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.
Actually the problem may have been an error in my Python code resulting in the def not taking — still confused by how that works.
On the bright side, when I manage to code things correctly:
A DXF is generated which matches the Keyhole toolpath in multiple ways:
This is:
At this time the code is handling 0, 90, 180, and 270 degree options — next will be working out the in-between positions and angles using trigonometry.
Actually, for the in-between positions there are more cases than one would think — for each quadrant there are the following cases:
Not wild about having to do trigonometric comparisons in the If else blocks, so even though I have the first option almost done:
I’m going to bag this and change the Angle input to a textual N, W, S, or E and will circle back to it when there is a need for a more freeform approach.
I believe that using polar co-ordinates would be an elegant solution, but I’m not seeing an easy solution to rotating a rectangle and getting the 4 points of the corners — perhaps programming in terms of chords of a circle would work for that?
Next step is working up a module to handle arcs.
The interface and DXF portion of this are quite simple:
module cutarcNWCCdxf(tn, ex, ey, ez, xcenter, ycenter, radius){
dxfarc(tn,xcenter,ycenter,radius,0,90);
}
but the actual cutting is a bit more involved — once again, this all raises the question of “What does an algorithm look like?”.
In BlockSCAD:
(this code will work a bit more straight-forwardly in PythonSCAD where it is possible to store the previous position)
module cutarcNWCCdxf(tn, ex, ey, ez, xcenter, ycenter, radius) {
dxfarc(tn,xcenter,ycenter,radius,0,90);
for (i = [1 : abs(1) : 90]) {
cut(xcenter + radius * cos(i),ycenter + radius * sin(i),ez);
setxpos(xcenter + radius * cos(i));
setypos(ycenter + radius * sin(i));
}
}
Unfortunately, it and a similar module when put together so as to make a semicircle:
cutarcNWCCdxf(KH_tool_no, getxpos()-25, getypos()+25, -stockthickness, getxpos()-25, getypos(), 25);
cutarcNECCdxf(KH_tool_no, getxpos()-25, getypos()-25, -stockthickness, getxpos(), getypos()-25, 25);
Result in two slightly over-size arcs which do not fit together as expected:
Continuing to make progress:
One thing which I’ve found helpful in working is to write up comments in the .dtx file:
but do the coding in OpenSCAD:
and once code is working (debugged), then transfer it into the .dtx file so that it may be typeset:
and since then, I’ve expanded on this (as discussed on the OpenSCAD mailing list) with a top-to-bottom re-write (still in process) focused on improving the appearance and aesthetics of the documentation:
EDIT: Updated for International Book Lover’s Day (8/9/24)
gcodepreview.pdf (1.5 MB)
where the next stage will be to review each of the code files at each step and determine if “drawing” up the algorithm in OpenSCAD Graph Editor or BlockSCAD will help.
This does raise a fundamental question, which I’ve never seen answered:
What does an algorithm look like?
