CAM: dealing with cutter picking up tape adhesive

Long read (edit: somewhat reduced). Food for thought without concise conclusions.

I use double-stick tape to hold material. When cutting through to the tape, the cutter bit picks up adhesive which accumulates on and climbs up the cutter. I think this is not uncommon. I’ve found a few ways to deal with it, and some related “wish” ideas for K:M.

For a simple cutout, the through cut is the last cut. Then the job is done and I can de-booger the cutter before setting up the next thing.

Combinations of multiple passes (rough+finish), internal through-cut voids, and/or multiple parts can add (i.e. multiply) up to lots of cutting down to the tape then lifting up to continue with cutting something else. In that case, options include:

  • Ignore it. Which actually works kind of ok. Sometimes. My feeble machine wants shallow step-down and wide cutouts (i.e. not deep slots) anyhow so I don’t use the sides of a cutter or rely on clear flutes for chip evacuation. But meh. For reasons.

  • Watch and “hold” on lifts to scrape the cutter when it looks bad, before starting a finish pass, or when I feel like it. Works but consumes total attention, for additional time, is tedious, and relies on inconsistent judgement and motivation. Meh.

  • Let K:M do some of the work:

  1. set a “Z bottom” limit one step above through and complete essentially all of the job without touching any sticky stuff
  2. do [waves hand] and make all the through cuts at a slight stand-off from the part edges – maybe the same “leave material” margin as the rough cut – accumulating a major glue booger all in one go while not rubbing the almost-finished parts edges and not jamming up the “wide cutout” slots
  3. programmed stop to scrape off the glue booger
  4. do [wave other hand] and cut all the final tight-to-part outlines, accumulating much less glue because only a little remains in the thin margin next to the part
  5. I’ve tried clearing the cutter and running the final circuits again one or two more times to get down to near zero glue pick-up, and, having proven that’s possible, probably won’t do it again.

That process seems to basically work for making parts. But the [waves hand] part… So I suggest the workflow above is a use case to think about.

I can’t use outline ops to do the cutouts without removing the “Z bottom” limit. That requires generating and exporting part of the job with a “Z bottom” set, then manually unsetting “Z bottom” to generate and export the through cuts. And remembering to set it back, etc. That leaves me wishing for a way for an op to override a global parameter.

Generating an outline with “a slight offset” can be done by lying about the tool diameter for that op. I’ve been doing the same to generate outlines that are essentially an accessory to a roughing op with a “leave stock” value. That’s not hard, but it somewhat obscures intent, doesn’t animate correctly, and generates false tool changes. I can set my gcode sender to ignore tool changes, but that blocks using tool change as a proxy for “hold”. Which leaves me wishing for a “leave stock” parameter on outlines. And a pause/hold op.

When cutting multiple parts, false tool changes are a bigger problem with the current behavior of running through all ops for each part in turn then would be the case when running each op over all parts. The latter order would be preferred for this workflow, which would reduce the downside of false tool changes. (The upside is tool changes can trigger a “hold” which, absent an explicit “hold” op, is useful if there are few false holds).

Rather than fiddling “Z bottom” and generating multiple exports, I’m using trace ops because they apparently don’t care about “Z bottom” and can be used to generate through cuts within the same job following “Z bottom”-limited operations. That considerably streamlines both generating and running jobs.

There are some hassles with using trace ops this way. If the answer is to allow outlines to override “Z bottom”, then there is no call for (ab)using trace ops for this purpose.

But if thinking that using trace ops might actually be better than overriding “Z bottom” in outline ops, then some things to consider:

  • since trace ops can offset either inside or outside loops without reference to the part, tracing both outside the part and inside any through-cut voids requires two trace ops. And it seems like pretty near everything I want to cut has at least one void
  • running both slightly-offset and tight-to-part cutouts then likely requires four trace ops. Not a problem, adding ops is easy, but makes it easier to screw up selecting edges
  • the “slight offset” comes from lying about tool diameter, so wishing for a “leave stock” parameter for offset traces for the same reasons as above
  • a downside of using trace ops is that they require manual selection of edges to trace for each part. External and internal edges. And getting all the right edges in each of four trace ops without error
  • If considering this as a use case for always selecting outer or inner perimeters of bottom part faces (or more generally, part shadows at stock bottom), some auto-select options for trace ops might make sense. Like ‘outer perimeters of all part shadows at stock bottom’ and ‘perimeters of interior voids in all part shadows at stock bottom’. (other useful criteria?)

In any case, the relationship between trace and “Z bottom” could use some clarification. It makes sense that traces have intrinsic Z position regardless of “Z bottom”. I’m using trace ops explicitly for the purpose of cutting below Z bottom, so obviously I like that they do that. But that weakens the idea of “Z bottom” as a “limit”. As it is, I think it’s more of a documentation that function issue – to make clear that “Z bottom” is a “limit” in a limited sense. (at cost of adding complexity for limited benefit, possibly trace ops could respect “Z bottom” by not cutting traces below that level – in which case I’d want an option to override that)

̶I̶’̶v̶e̶ ̶w̶r̶i̶t̶t̶e̶n̶ ̶s̶e̶p̶a̶r̶a̶t̶e̶l̶y̶ ̶a̶b̶o̶u̶t̶ ̶o̶r̶d̶e̶r̶i̶n̶g̶ ̶o̶f̶ ̶m̶u̶l̶t̶i̶p̶l̶e̶ ̶o̶p̶e̶r̶a̶t̶i̶o̶n̶s̶ ̶f̶o̶r̶ ̶m̶u̶l̶t̶i̶p̶l̶e̶ ̶p̶a̶r̶t̶s̶.̶ ̶F̶o̶r̶ ̶t̶h̶i̶s̶ ̶u̶s̶e̶ ̶c̶a̶s̶e̶,̶ ̶I̶’̶d̶ ̶w̶a̶n̶t̶ ̶a̶l̶l̶ ̶r̶o̶u̶g̶h̶ ̶&̶ ̶o̶u̶t̶l̶i̶n̶e̶ ̶o̶p̶s̶ ̶a̶b̶o̶v̶e̶ ̶Z̶ ̶b̶o̶t̶t̶o̶m̶ ̶t̶o̶ ̶c̶o̶m̶p̶l̶e̶t̶e̶ ̶f̶o̶r̶ ̶a̶l̶l̶ ̶p̶a̶r̶t̶s̶,̶ ̶t̶h̶e̶n̶ ̶a̶l̶l̶ ̶o̶f̶ ̶t̶h̶e̶ ̶f̶i̶r̶s̶t̶ ̶r̶o̶u̶n̶d̶ ̶o̶f̶ ̶f̶u̶l̶l̶-̶d̶e̶p̶t̶h̶ ̶c̶u̶t̶s̶ ̶(̶t̶h̶e̶ ̶"̶s̶l̶i̶g̶h̶t̶ ̶o̶f̶f̶s̶e̶t̶"̶ ̶g̶r̶o̶u̶p̶,̶ ̶i̶n̶s̶i̶d̶e̶ ̶a̶n̶d̶ ̶o̶u̶t̶s̶i̶d̶e̶s̶ ̶o̶f̶ ̶a̶l̶l̶ ̶p̶a̶r̶t̶s̶)̶ ̶f̶o̶r̶ ̶a̶l̶l̶ ̶p̶a̶r̶t̶s̶,̶ ̶t̶h̶e̶n̶ ̶p̶a̶u̶s̶e̶,̶ ̶t̶h̶e̶n̶ ̶a̶l̶l̶ ̶o̶f̶ ̶t̶h̶e̶ ̶s̶e̶c̶o̶n̶d̶ ̶r̶o̶u̶n̶d̶ ̶o̶f̶ ̶f̶u̶l̶l̶-̶d̶e̶p̶t̶h̶ ̶c̶u̶t̶s̶ ̶(̶t̶h̶e̶ ̶"̶t̶i̶g̶h̶t̶ ̶t̶o̶ ̶p̶a̶r̶t̶"̶ ̶g̶r̶o̶u̶p̶)̶.̶ ̶ ̶C̶u̶r̶r̶e̶n̶t̶l̶y̶ ̶t̶h̶e̶r̶e̶ ̶a̶r̶e̶ ̶a̶ ̶f̶e̶w̶ ̶d̶i̶f̶f̶e̶r̶e̶n̶t̶ ̶w̶a̶y̶s̶ ̶I̶ ̶c̶a̶n̶ ̶g̶e̶t̶ ̶t̶h̶a̶t̶ ̶d̶o̶n̶e̶ ̶b̶y̶ ̶h̶a̶n̶d̶s̶-̶o̶n̶ ̶p̶r̶o̶c̶e̶s̶s̶.̶ ̶E̶a̶s̶i̶e̶r̶ ̶f̶o̶r̶ ̶a̶ ̶s̶i̶n̶g̶l̶e̶ ̶p̶a̶r̶t̶ ̶t̶h̶a̶n̶ ̶f̶o̶r̶ ̶m̶u̶l̶t̶i̶p̶l̶e̶ ̶p̶a̶r̶t̶s̶.̶ ̶E̶x̶p̶o̶r̶t̶i̶n̶g̶ ̶t̶h̶e̶ ̶z̶i̶p̶ ̶f̶i̶l̶e̶ ̶i̶s̶ ̶u̶n̶f̶o̶r̶t̶u̶n̶a̶t̶e̶l̶y̶ ̶̶n̶o̶t̶̶ ̶p̶a̶r̶t̶ ̶o̶f̶ ̶a̶n̶ ̶e̶a̶s̶y̶ ̶a̶n̶s̶w̶e̶r̶ ̶b̶e̶c̶a̶u̶s̶e̶ ̶w̶i̶t̶h̶i̶n̶ ̶t̶h̶e̶ ̶z̶i̶p̶,̶ ̶t̶h̶e̶ ̶t̶r̶a̶c̶e̶ ̶o̶p̶s̶ ̶g̶e̶t̶ ̶l̶u̶m̶p̶e̶d̶ ̶t̶o̶g̶e̶t̶h̶e̶r̶ ̶b̶y̶ ̶p̶a̶r̶t̶ ̶w̶h̶e̶n̶ ̶I̶ ̶n̶e̶e̶d̶ ̶t̶h̶e̶m̶ ̶s̶p̶l̶i̶t̶ ̶a̶c̶r̶o̶s̶s̶ ̶a̶l̶l̶ ̶p̶a̶r̶t̶s̶ ̶b̶y̶ ̶o̶p̶ ̶s̶e̶q̶u̶e̶n̶c̶e̶.̶ ̶G̶e̶n̶e̶r̶a̶l̶l̶y̶,̶ ̶a̶n̶ ̶o̶p̶t̶i̶o̶n̶ ̶t̶o̶ ̶s̶o̶r̶t̶ ̶w̶o̶r̶k̶ ̶b̶y̶ ̶o̶p̶s̶ ̶f̶i̶r̶s̶t̶ ̶i̶n̶s̶t̶e̶a̶d̶ ̶o̶f̶ ̶b̶y̶ ̶p̶a̶r̶t̶s̶ ̶f̶i̶r̶s̶t̶ ̶w̶o̶u̶l̶d̶ ̶s̶i̶m̶p̶l̶i̶f̶y̶ ̶t̶h̶i̶s̶ ̶w̶o̶r̶k̶f̶l̶o̶w̶ ̶w̶h̶e̶n̶ ̶c̶u̶t̶t̶i̶n̶g̶ ̶m̶u̶l̶t̶i̶p̶l̶e̶ ̶p̶a̶r̶t̶s̶.̶

How about a “checkpoint” op (by whatever name)?

Thanks for reading.

I think adding an optional offset to outline is a good idea. An op for pause or hold or even arbitrary gcode injection is also a good idea. Allowing a set of parameters that are on the right hand menu to be included in each op would solve a bunch of this. I just haven’t figured out what the UI would look like and still be relatively intuitive. The alternative is cramming tons of new params into each op pop menu, which I am loathe to do.