cnc-0.0 by Trenton Henry

cnc is a command line tool for creating gcode from ddd stencils.

Command summary

It's basically: cnc command args

cnc ddt2g - saves a stencil as a gcode file, with a .tap extension

    <fname> -- the name of the ddd stencil file to view

    [-m material] -- the billet material, one of FR-1 (default), WAX, BIRCHPLY, MAHOGANY

    [-t tool] -- the bit, one of 1/8, 1/16, 1/32 (default), 1/64, ENGRV

Devlog

01/15/22

Here are some sample shapes drawn with ddd stencil. They are converted to gcode via cnc ddt2g and loaded into Universal Gcode Sender. As of today the unreleased not even pre-alpha version it is very rough around the edges. And, well, around the middle also. But it seems to have hopes of being minimally viable. Of course, I still need to actually mill some of these. That is likely to result in multiple iterations before I actually try to 'release' a proper version 1.0.

Observations

When I try to load these gcode files into the old Bantam software (1.2.2) on a new M1 Mac the app just crashes. This may be Rosetta related, I am not sure. However, when I load the same files into the same version of the software on an older Intel Mac it loads up and seems to work. So, use the Intel Mac when playing with the Bantam software for these.

The Bantam software (1.2.2) reports a warning that the retract may be so high as to be beyond the limits of the machine, possibly damaging it. [fixed]

Looking at the renderings of the expected result, even with a .003 engraving bit, the cuts are awfully close together, and are likely to fail. There are two obvious knobs; the plunge depth may be too great causing a wider V cut than desired, and the design may be scaled too small for the resolution of the software renderer, or even the machine. [scaling]

The center of the stencil model coordinates is at the LLC of the spoil board. I should probably move the toolpath when I generate the gcode so that it is at the LLC. Otherwise each stencil I convert and load appears at an unpredictable location. And that make things unnecessarily tedious, particularly if trying to tile multiples. [tbd]

01/19/22

A little tweaking and I managed to get to the point of being bold enough to actually try to mill something.

OtherMill + modern Bantam SW == Not Supported 😞

M1 Mac + old Bantam SW (rosetta) == Crash 😞

OtherMill + UGS == "Connected to TinyG 0.97. The setup wizard is not supported for this controller". Which means I will have to configure the machine settings manually, once I figure out how... 😞

Intel Mac + old SW == Working 😃

* I had to adjust the height of the toolpath. So my SW isn’t handling the material thickness correctly yet.

* My cut depth was maybe too deep. In some places it goes through the white inner material to the brown outer layer on the bottom, making the lines look light or dark.

* My first attempt to cut a toolpath I generated all by me onesies and I don’t break any bits or wedge the machine! Go me.

Click an image to view details.

02/01/22

Not much time to work on this recently, but here is the gist of what's happened:

I wanted to switch from the bespoke data structure DDTLINE I was sing back to DDDMESH because that is an offshoot of my venerable ObjC 3deity code rewritten in C. Part of the reason to do that was to get DDDMESH et al up to snuff. But, I think I made a mistake when doing that since I convert the NSData / hgn_data (depending on which variant you look at) into C arrays. I used my EARR elastic array code, and it pretty much worked, but there were issues. First off, there were subtle bugs in insert and remove. And the whole implementation is 90% sequential macros with a couple of underlying function calls for actual reallocations.

I never really liked it that much, although I did use it in yopcc along with ESTR, which  is elastic strings built out of elastic arrays, and that worked out ok. I also used it in ibtui and zentiu and some other things and it worked out fine. But it was always tricky to use properly and I never really warmed to it. So, to the DDDMESHes etc I replaced the EARRs with new things, called ARRAYs. These are modified versions of iblvm's bytes.c allocator, but using malloc instead of an incremental allocator.

Anyway, I did all of that, and it seems fine. But I also ended up not using DDDMESHes because as I was porting things I began to view the innards of the DDDMESH data structure is somewhat cumbersome and grotesque. I mean, it works ok, but it is based on the idea that vertices, edges, triangles are all packed arrays that can be turned into vertex array buffers etc for OpenGL or Metal. Which is fine when trying to render things in a puff scene or a game but isn't so great for trying to model things.

So I now have a thing called a DDCADMESH (yeah, I know, I need a sane short name) which contains an ARRAY of DDCADLINEs (also needed a decent name). There is no separate array of points, or triangles. So lines cannot share points. I do store vertex normals with the points of the lines, in the hopes that if I arrange the lines of what would be a triangle/polygon in CW/CCW order as if there were triangles/polygons that I can uas the normals to cull the backfaces (backlines?) so that even though meshes are rendered hollow the backlines are removed. Because ... that might be interesting. Particularly if I render in anaglyphic style.

So there you have it. A lot of work to go full circle back to where I was in a slightly different configuration. And some new bugs to kill. And no, you don't get any pictures this time.