To make sure up front: The milled result is always fine.
But is this a known behavior, when the milling bit is not shown in the exact dimension? Here I use a 3.175mm bit and it should not leave gaps between the paths.
endcover.kmz (210.3 KB)
To make sure up front: The milled result is always fine.
But is this a known behavior, when the milling bit is not shown in the exact dimension? Here I use a 3.175mm bit and it should not leave gaps between the paths.
endcover.kmz (210.3 KB)
All of your tools are ID 1, which is a problem for the engine, so it picks the first one. Each tool should have a unique ID. When I set the tool ID of the 3.175 end mill to 2, it’s unique and renders / animates properly.
Thanks for your reply. Yes that solved it.
I misinterpreted the ID. I thought it’s a tool number which affects the milling process.
You’re not wrong. But it only affects simulation. So perhaps that’s a bug, too.
I’ve confirmed this is a bug in animation when tools share a #. it’s a tough fix because by the time path data gets to the animation engine, the tool’s internal ID is lost (gcode only cares about the tool #) … will think about this a bit more.
I’m still seeing a similar error. The simulation tool seems strangely offset.
The generated gcode seems fine.
I’m using a LinuxCNC machine and I set the tools to be 3/4 in and the machine dimensions are millimetres.
I can repro this every time.
please right-click export workspace and email the .kmz
file to me [ sa at grid dot space ]
Sorry, I replied via email… that was a mistake…
as a new user I can’t upload, accept google drive link, thanks!
simulation appears to be working correctly for me in chrome/edge. I would also recommend adding a roughing pass before the contour so that you’re not plunging too deeply into the material
tool-test-wing.kmz (673.2 KB)