A Discussion of CAM features

I’d like to get feedback on a few planned changes and also open the floor to suggestions for new or improved features.

  1. limit roughing to inside. no more cutout in roughing.
  2. expand outline to inside, outside, or both. not just both or inside.
  3. tabs would only be active for outlines.
  4. outlines in outside-only mode = cutouts
  5. split out surfacing from an implied roughing operation
  6. add a “flats” operation to clear flat areas separate from roughing. or combine with surfacing as an option.
  7. add new strategies for roughing operations. the offsetting works OK, but I have others in mind that might be faster and cause less tool wear.

I’m in the process of looking at adding drag-knife support in laser mode. But I’m on the fence. It could also fit in CAM mode. However, that would require adding a “knife” mill type and that would complicate things. Thoughts?

These changes are designed to:

  1. simplify the code
  2. make it more robust
  3. make the features more discrete
  4. make room for new features

I have just not done enough milling to comment on 1-7 but as for the drag-knife goes, people will CNC’s are fitting diode lasers onto them more and more as the prices have come down and they are seeing what can be done with low wattage(less than 7W) diode lasers. So anything which can make the 3(milling, laser, drag-knife) easier for the average CNC guy/gal would be great.

I have a small CNC, a couple of lasers(CO2 and diode) along with a small Silhouette vinyl cutter.

Hi Stewart and thanks for the ongoing work on kiri:moto.

Having to option to separately enable inside/outside/both for the waterline op would be welcome. I split the gcode into separate inside and outside files by hand quite often for some workholding setups. And in this context it makes sense to me to only have tabs for outlines.

Limiting the roughing to the inside and only doing cutouts as a outline operation would be fine, however there must be a ‘leave stock’ option for outlines. At the moment I rely quite heavily on a small leave stock value for roughing and then a separate full depth waterline op to get better dimensional accuracy and surface finish.
Edit: also the wide cutout option should ideally remain available for cutouts, it helps quite a lot with deep slotting.

In this context do you mean surfacing as in the surfacing that kiri:moto does when ‘z top offset’ > 0? And I’m not sure I understand how the new ‘flats’ operation mentioned at point 6 would work.

In terms of new strategies, adaptive clearing would be very very welcome, but I’m aware it’s more complex and it might take too much time to implement.

Hi @DougL and welcome. For drag-knifes, I plan to support gcode, svg, and dxf output, which is why I’m leaning toward adding it to Kiri’s existing laser mode. My first personal use case will be cutting cardboard for an interesting construction project.

Does your vinyl cutter support an open file format?

Hi @cosmin. Good to have you here, as well. I plan on preserving all existing capabilities, one way or another, including wide cutout and leave stock.

I would like to have the process of finding and clearing flats be district from roughing. The current implementation blends the two, which is convenient, but can have some unintended behaviors and leads to complex code. When ‘z top offset’ > 0, it creates an implicit surfacing pass. That could become part of a flat clearing process in the future when processes can be mixed and re-ordered.

My plan is to make roughing strategies pluggable which should make the code cleaner and allow more experimentation. Adaptive clearing is definitely on the list.

By the end of the next 2.3.x branch, I would like to have a fully modular set of CAM operations that can be added, edited, and re-ordered.

I use a plugin for Inkscape to output to the vinyl cutter so it supports formats Inkscape does.

I might have told you, I don’t do Windows. Nor Mac.

1 Like

There are some good ideas in your list.

    1. tabs would only be active for outlines., What about loose parts in the center of your object, lets say you cut out a circle it would be nice if there is the option to enable tabs for loose inside parts.

Things I’m looking for are:

  • a way to limit the working area lets say you import a cube, cylinder (random model) with cutouts and holes to be made on the top plane. This way you could make it just mill the holes and not the contour of the 3D model. Why lets say you need a specific hole or shape cut out in the middle of an existing work piece. I don’t know what otherwise would be the right way to import only the hole that has to be cut.

  • This feature is something that’s maybe on the list but I’m not sure I understand you completely. A way to do a quick clean up operation with a big large diameter endmill and after that only clean up what is left with a small endmill.

  • Something to do V engraving like F-engrave built in would be awesome.

Keep up the great work!

@Bruce these are some of the things on my todo list or 2.3:

  • manual placement of tabs. this would also aid in internal connections.
  • selecting or limiting a work area given a feature like a flat area, lip, or outline
  • multiple operations with different settings / endmills
  • linear path following for V and taper mills

I will begin to push new features aggressively to the development channel. Kiri’s version will now appear as a changing number related to the target release branch. When the first push happens in about 12 hours, you will see it as 2.3.D0 with the # after D indicating how many iterations have been pushed.

I will also try to limit my changes to the 2.2.x release unless there is a real bug to fix.

what do you mean with the linear path following?

as an alternative to polygon offsetting of edge features, I would like to be able to select an edge or groove center (like for lettering) that a tool tip can follow. this would allow for easier chamfer cuts, for example. it would also allow a ballmill to follow the bottom of a rounded channel, something that is currently not really possible.

1 Like

that sounds awesome!

but another approach would be nice as well, so that you import a 2d image just as in f-engrave and it generates a tool path for a v-bit and changes it’s depth to match the the tool width from the v-bit and the are to carve.
I hope it makes sense what I’m saying, if not I’ll elaborate.

that makes sense. image import is something I’ve looked into and is on the list.

Called “rest machining”. Would be a big step up.

@stewart - you mentioned cut simulation/visualization. Seems like that would be most of the work toward dong this.

I think it’s great a windfall for the rest of us that you’re actively working on this. Especially with Fustion 360 tightening up recently and FreeCAD not really having >2.5d CAM together yet. I thought I had notes for a few coherent comments, but this turned into a giant ramble that went off in unexpected directions. So, it’s sketchy. But here goes:

These seem like four sides of something to think about as a whole.

I agree with @cosmin about roughing then finishing outside outline cutouts. And wide cutouts.

It’s not immediately obvious whether that means roughing with outside outlines as a selectable target, or outlining with roughing options like ‘leave stock’ and ‘wide cutout’.
In any case, it seems like tab options should be available wherever outside outline cutting can happen.

Would like to be able to order operations so that the first outside cut happens after the last inside cut.

About tabs:

  • Would like to be able to rough down to stout tabs, finish anything else, then skim away nearly all of the tab material with light cuts that don’t have to travel around at zero distance from much of the perimeter.
  • Just heard that vacuum table users like “onion skinning” their cutouts down to a very thin uncut remainder - as another way to do accomplish what tabs do so maybe the two could be presented together.

Adding much for operating on flats would make use for a vertical ‘leave stock’ roughing parameter.

So far as I can see, ‘surfacing’ currently ties directly with Z top offset in a way that is direct but not self-evident to a newcomer. If true, should one drive the other? Maybe no surfacing option but instead a notice when a roughing op will include surfacing because of a non-zero top offset? Or make surfacing the selectable option and top offset a parameter to surfacing when selected? But maybe I’d want to rough a pocket only and start the top of the pocket below the material surface in which case I’d want to set a top offset without surfacing? – or define “surfacing” to include clearing above-part surface material down to a depressed zero plane even if cutting only a pocket where none of that “surface” will remain? In any case, I’ve rambled into wondering if “top offset” has meaning outside the roughing context – because what does “top offset” mean after you’ve cut the top away? Put another way, rather than offsetting a part down into the material, one might start with some excess material over the part. The roughing operation(s) needs to know about that, and then it doesn’t exist anymore.

That was about top offset – because it was about “surfacing”.
And the top surface is a defined plane rather than a detected plane.
So initial “surfacing” and operating on flats within the part geometry differ.

Maybe what’s missing is an option to cut all of the chosen work area (stock area, part area, pocket, whatever) down to the “top” plane only regardless of part geometry

Down in the part geometry, KM can clear “flats” now by setting very large stepdown. I think it makes sense to provide a direct way to state that intention.

Possibly there could be use for specifying flats by Z. e.g options like: at the level nearest a given Z; within +/- a given Z; within a given Z range; deepest only.

How do you feel about GUI interactive selection?

I’d use a flats-only operation more often for finishing than roughing, I think. So lifting it out of roughing makes sense. I’ve just persuaded myself of a difference between roughing away excess material down to a first defined surface and operating on flats within the part geometry. And below that first plane there’s no other surface until some more roughing has happened. So - flats as a surfacing operation.

About surfacing, then:
There are kinds of operation (e.g. offset, zigzag, adaptive, …) and kinds of surface (flats, curves, verticals, sloped flats, simple/compound curvature, …) and locations (inside, outside, selected pocket,…)
Are those orthogonal (even if some combinations not preferred) or are there impossible combinations?

Lots of potential to add lots of value there. It seems the generalization of smarter strategy is constant tool engagement rather than geometric path definition. So there’s a high-level categorization.
Another low-hanging fruit could be to add stepdown limits to any (?) of the surfacing operations and iterate. Which muddies the roughing/surfacing distinction…

Maybe any operation can be roughing or surfacing - the difference being whether the target surface is directly accessible or there is more than ignorable material in the way.
So maybe: first choose an operation (toolpath type, target surface), then indicate if it can be done directly to an accessible surface (probably as a finish/cleanup operation - but not essentially so) or the operation needs to advance incrementally through uncut material. If roughing through material, then roughing options like maximum stepdown, leave stock, etc. become available. If so, this might be a place to plug in “rest” machining as a third option which would trigger calculating material cut by previous operations.

It could fit, and as @DougL mentioned, people can add all sorts of tools to something that started out as a mill/router. But I’m not sure treating the result as mill-with-knife/laser/whatever would be easier than making the UI for a machine a machine work like the tool an attachment makes of it.

So adding knife to laser makes more sense than adding knife to CAM.

But if you’re writing new stuff, what do you call the generalization of laser/dragknife?

Perhaps instead of orienting the UX around machines, the schema could start with:

  • linear: lasers (vector ops), pen plotters, drag knife, V bit (adds a parameter but that parameter is a function of position along a linear path), even 3d-CAM-oriented router/mill when simply tracing line art could use a simple UX. KM’s multi-layer laser function stacks linear operations.

  • area: “2.5d” ops defined by 2D geometry and a number (depth). Including a small number of numbers (different depths). Where doing something with multiple depths, the geometries at each depth may have correlations but largely independent definition. Can include lots of work done on 3d-capable mill/router machines. Constant-intensity raster ops obviously. Image raster ops? That exceeds the 2D+number definition but “number” could extend to a 2D field of simple magnitudes. I’d even extend that to include “3D” cutting a field of varying depth in a single pass as with X or Y “contour” ops in KM.

  • volume: Additive or subtractive ops where the third (or more) axis is not trivially derived from linear or area inputs. Then choose a process. This part maybe looks most like current KM with FDM, SLA, CAM, whatever.

I can’t think of much to do with a pen plotter that would call for a “volume” UX, but work on a CNC mill might fit best in any one of those modes. e.g. running a V-bit needs a 3-axis machine with a spindle but isn’t an all-up CAM function.

1 Like

this was the original intent for roughing / finishing (now outline and/or contour). use a big endmill for roughing. leave stock. then use finishing passes to remove the remainder. roughing has historically cleared flats implicitly leaving nothing for the finishing passes except the side walls. this will change going forward. exact implementation TBD.

So much good stuff to respond to in this post, I don’t know where to start. While I like a UX oriented to task rather than tool, I think that will have to wait until I’ve had a chance to do other major refactors. I wish I’d known 5 years ago what I would be doing with the code today.

I would love to implement this. The hard truth is that UI work is 10x more time consuming than the math and geometry code. And as of right now, I’m the only one coding on this thing. I would welcome anyone who wants to join in, though.

The path work isn’t hard. But any changes like this are really predicated on a more sophisticated UI. See above.

Short term, I doing a lot of core (math, poly, slice, mesh) refactoring to make these types of things easier to implement. Once that refactor is done (or nearing completion), I will start to look at UI strategies for region selection, constraints, ordering of arbitrary operations, etc.


One edge case is where the big cutter can’t get into narrow or tight spot and leaves more material than a surfacing operation can blow through with a smaller cutter - or enough to disrupt the surface quality where the finishing pass has to actually cut stuff. Similar to the large offset/tight corner problem.

A variation of the same is roughing something that with an obvious feature that obviously will require a smaller cutter than you want to rough the whole thing with.

The difference, I guess, being whether it was already part of the plan before User got started, or a problem that emerges.

Not news I’m sure. Just trying to articulate the concepts while you’re refactoring.

Yes. Part of the thought was a schema for thinking about data structures, module boundaries and interfaces, etc. But I had to stop writing somewhere.

Yeh. That’s why that was a question rather than a UI wishlist.

Just pushed a new development release 2.3.D1 that contains a massive code refactor around drivers. But more relevant to this discussion, a completely new depth-first strategy for roughing. It does not, yet, change the way roughing is calculated. That’s still offset. Also in this releaser is a totally new way to handle workspace mm/inch units.

This refactoring is paving the way for some of the more interesting features enumerated above. Large amounts of code were moved around today. Please help with debugging.

1 Like