Please let me split the discussion in two parts
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.