Yes, please, send an example to [email protected]. Thank you. I don't think this is a known issue (at least, I don't recall seeing this).

In MC2023, I finally got the computation error - I have to move the 3D HST operation after the one other operation, regen, move it back, regen, move it forward, regen, and, eventually, I will get the error. Logged this as D-53533. This error doesn't seem to repeat in MC2024 and MC2025.

I believe you! I got the computation error, once, when I did a copy/paste and regen. But now I cannot duplicate it either. I'll keep trying.

Hi, when you have a chance and if you are able, would you please email us your part? Send it to [email protected]. I created my own MC2023 Mill test part and it works (one other op before or after). Perhaps there is a specific parameter setting that is causing trouble. Thank you.

If you have a slow finish/contour toolpath, please send it in and we will have a look. We recently discovered a regression with bull nose tools (now repaired).

Disregard my response. Rekd’s answer is correct - see stock on floors and walls in Model Geometry. Those may default to a nonzero amount.

Yes, check the stock to leave amount. In this classic surface toolpath, the drive stock to leave is found on the second tab page. Also, check the tool tip/center option also found on the second tab page. Maybe it is set to “center”.

When flowline was first released, it only handled a single surface. Then was added the ability to handle multiple drive surfaces by flowing along a row of surfaces (crossing over one shared edge between two consecutive surfaces). Later, was added the ability to handle a wider set of connected drive surfaces such as multiple rows or a grid or a quilt. The "single row only" allows you to revert back to the first algorithm, should that do a better job (on a single row) than the latest quilt or grid approach. The top toolpath is a single row (using the single row option). The bottom toolpath is a grid or quilt with "single row" unchecked.

Yes, please send it in. We may be able to provide insight. When it regenerates quickly, I suspect that it is able to reuse cached data. When opening the file the first time, maybe there is no data cached (or it is not reused).

Got it! Logged as R-32276.

It looks like the containment boundary is defined in the front view. Change your CPlane and TPlane both to Front and regen. Now look from the front view and you will see that you machine everything outside the "D" shaped containment boundary. That is because you have enabled the option to include the silhouette. Using a silhouette boundary AND a containment boundary gives you a checkerboard effect (in, out, ...). Uncheck the include silhouette option and regen and you will see that you machine everything inside the "D". As filed, in the Top view, you are machining everything in the silhouette boundary and the containment boundary looks like a straight line in Top view and is (quietly) ignored.

What happens when you create surfaces from that solid? Do they hold their shape? What happens if you use HST/Raster with the same geometry (solid and surfaces)? If you duplicate the issue, please send it to [email protected]. Thanks.

Classic surface rough/pocket supports undercutting. I was just able to use zigzag pocket method (with finish pass off) to get cutting motion a little bit like rough/parallel. I used the gap settings to order the cuts from the bottom to the top. I used an entry point. (Alternative - turn off roughing passes, turn on finish passes with nonzero spacing and more than one pass.) Rough/parallel does not support undercutting.

Looks like the raw flowlines are painted in the hard-coded color "DK_GRAY". I entered S-87089 to see if we can improve this (allow the color to be user-determined). Thank you for reporting this.

It is the Tolerance! Your Resolution is ignored if it is less than your Tolerance. (I didn't know this until I looked with the debugger...) The processing code reverts back to 1.25mm resolution. I have submitted this as D-45483. As a work-around, set your Tolerance to just less than your 0.01 Resolution (I used 0.009). You will notice that the processing takes longer. The answer I got was 87.01775. Thank you for reporting this.