Meshcam - depth first

(Frederic Detienne) #1

I frequently need meshcam but am often worried about the time it takes.

It seems that MC is rather smart in the way it analyzes the object and/but comes up with convoluted toolpaths, especially while roughing. I would love a dumber option for roughing.

Since this is a 2.5d tool anyway (bear with me), it would be very nice if meshcam would “slice” the object and focus on depth first in the roughing pass. I.e. Proceed with each layer/slice without looking ahead (“down”). When a layer becomes non contiguous (starts having isolated “pools”), focus on one pool at a time to the maximum extent of the tool length.

This would save a lot of tool retracts and progably simplify tool retracts management.

Hope my algorithm makes sense… It would seem a lot more efficient in some situations (at least lots of “my situations”).

I like Meshcam. I owe it to have been able to start in the wonderful world of CNC. Hope this would be useful.


@TotallyFred, MeshCAM does do roughing one level at a time. It actually puts comments in the gcode telling the level it’s on.

But you will never get past retracts. When MeshCAM completes a level, it goes back to the previous level and makes an outlining pass to clean up that level.

If you are literally doing a 2.5 part (just outlines and no part-depth pockets) there is no reason to do roughing at all.

For a 2.5D general part that includes pockets, make sure Use Parallel Roughing and 3D Roughing are unchecked. That makes MeshCAM do the more traditional outline-offset method of roughing toolpaths.

For all parts, always use Geometry only, with a machining margin of about 75% the cutter diameter. That will minimize the roughing outside the part.

MeshCAM was written, and primarily is still, a full 3D machining program. Look at the included samplerhino.stl for the type of workpiece MeshCAM was/is aimed at. The 2.5D functionality is pretty much a side benefit of what MeshCAM does in 3D. That said, there are 2.5D specific programs that are better at “flat” parts than MeshCAM is. But that is a second program to buy. I have used one, for just about as long as I’ve been using MeshCAM (since Beta 5 in 2003…)


(Frederic Detienne) #3

Please let me split the discussion in two parts

1- Terminology
I may have used the wrong term and I realize that 2.5D is an overloaded term. I meant that on a 3 (x,y,z) axis which is what Shapoko and Nomad are, we only can carve a 2D function in a 3D block of material. I.e. as output of a job, for every (x,y) coordinate, there is only on possible value of z=f(x,y). It may not be a continuous function but it is a projection from (RxR) into R. As such, the function exhibits “peaks and valleys” that are local minimums (minima) and maximums (maxima).

MC may be capable of handling true 3D but i want to stick to SO and Nomad for the purpose of the discussion.

Let’s name this kind of geometry the way you want but it is an important use case for the population of this forum and way more than a mere outline as you righlty pointed out. I would be tempted to call this pocket milling (it fits the wikipedia definition) but it seems that pocket milling is more closely related to extruded surfaces (prisms in MC jargon).

The f(x,y) surface I care about here is something “more 3D” than “prismatic” (using MC terminology) but less than full 3D. I.e the kind of job we can get done on a regular 3 axis SO/Nomad without rotating the part. Also notice that double-sided or multi-sided machining is the result of rotating the geometry and carving the f(x,y) function along the chosen z axis.

2- processing the said 3D surface
Anyway… I haven’t found that by enabling/disabling any option, the toolpath were more efficient (slighlty more or less but still sub-optimal).

I see that MC indeed proceeds layer by layer but as valleys (local minimas) appear, MC attends all the pockets at a given layer before proceeding to the next layer. MC apparently always completes layer-first.

This poses two problems:

  • the necessary retracts and rapids is too high (by “too much”, I mean it can be reduced)
  • I understand the coding difficulty to optimize that resulting in additional unnecessary retracts and rapids.

On a 3 axis, one can assume that an area to be carved out at a given layer (technically, the layer is pocketed) will be completely included under the carving area of the previous layer since the tool can’t reach underneath the non-carved region of the said previous layer.

By attending an entire valley rather than finishing an entire layer before addressing the next layer, many retracts and rapids could be avoided. I am taking a common complain (job time and tool path efficiency) and I am merely saying that for the type of job SO and Nomad can perform, there exists a fairly simple method that reduces the overall computational complexity compared to a holistic 3D analysis of the part. In short: go from an NP-Complete problem to a (probably) linear problem O(v) where v is the number of local minimas in the f(x,y).

Maybe “depth-first” is not the right way to describe the proposed algorithm either. It is a “valley-first” algorithm. The practical advantages of valley-first are on a 3 axis machine (x,y,z)
1- reduce the theoretical number of necessary retracts and rapids compared to a layer-first
2- reduce the computational complexity to obtain more efficient tool-path by helping to reduce unnecessary retracts and rapids.

MC also sometimes seems to “look ahead down the z-axis” and avoid clearing regions where it may simply surround the zone instead. I.e. a “large through-hole encompassed within a 2D boundary” will generate a tool path that will surround the hole rather than clearing up the material inside that hole. This is a nice thing to do as it reduces the surface to mill (preserving the cutters) but it complexifies the tool path further. I am unsure what triggers (which option and exact geometry) triggers that behavior. This behavior could be preserved with valley-first though it should be left as an option to the operator as that can generate many sub-valleys that are not present in the initial geometry (source of current long tool-path).

Disclaimer: this may be the way MC is supposed to work but then it seems i should report a bug.


@TotallyFred, Robert is always open to feedback at the MeshCAM support email address.


(Frederic Detienne) #5

thank you as always! I had not realized this was the preferred method. I will do that.