Hi,

I've stumbled on this bug on a current project, but was able to reduce it to the following minimum:

1. Create a new Project, and create a new layer with the  treeoflife3d.jpg file from the example images download
2. Set the size to 50mm  x 50mm x 10mm
3. Introduce 2 tools: 4mm flat endmill, and 1mm ball endmill
4. Create parallel machining operation with the 4mm endmill
5. Create parallel machining operation with the 1mm endmill (with a 1mm cutting depth to force multiple passes)

If the Operation in #5 is marked as "rest machining", this is the result:

If the operation in #5 is not marked as "rest machining", it works fine (meaning it produces the model created in the first step)

(Other parameters seemed to not influence the result; I looked at the tool paths in PixelCNC and in my CNC program to ensure this isn't a simulation/rendering issue - the toolpaths would create this result; Using the rendered versions above was the best way to visualise the issue)

Please let me know if more information is required to debug this, or is not reproducible with the steps provided.

thanks,
Mike

Hi Mike, thanks for taking the time to figure out how to reproduce the bug you've found, that saves the trouble of the back-and-forth with users to get to the actual cause of the problem. I'm able to recreate what you're seeing over here with the instructions you've provided so I have a good specimen to work with now.

I have an inkling that somehow the rest-machining is confusing the feeds and rapids, where a rapid has attached to it a retract-to-safe-Z move, then  the actual rapid to the next cut's XY, followed by a feed/engage move to begin the cut, but if it's flagged as a "feed" it doesn't generate the retract, rapid, or engage moves and instead just treats it like any other feed move. It could very well be something entirely different, maybe in some of the geometry logic that "cuts out" the area that's already removed by previous operations from the generated cut paths that should only cut where there's still material.

In either case I'm on it! I'll let you know once I've squared it away and the fix will be rolled out with the v1.43a release. In the meantime feel free to let me know  if you have any questions, suggestions, feedback, or come across any other issues that need to be looked at.

Thanks again :)

Charlie

Fixed it! I went ahead and re-created the test case that fails to generate a correct toolpath in v1.42a in previous versions and found that rest machining  worked fine there. I was then able to deduce that there was a code change from v1.40a to v1.41a that was missing an additional line of code that was needed, resulting in rest machining being broken in certain situations.

I'm working on some new canvas editing functionality at the moment and once they've been knocked out v1.43a will be rolled out, including the fix for the rest-machining bug.

Thanks again for the bug report!

Charlie

Wow, that was fast! Thank you so much for the quick response and fix

looking forward to the next release
thanks again,
Mike