Has anyone seen this before?
Cutter: 1/8" flat endmill upcut
Material: 6mm Corian
Cutting depth: 5.5mm (in 2 passes)
Plunge rate: 20 ipm
Feed rate: 30ipm
All other cutting seem fine including the 1/8" drilled hole (Vcarve)
It looks like it might be chattering through the gap - I’ve had this on wood before. Maybe cut back the DOC?
1 Like
Does the same job cause the same effect in some scrap wood? If it shows up evening in each DOC pass your pulleys might be slipping on the shafts a bit, or there is some gunk on the vwheels.
1 Like
I thing is to fast Plunge , I put 7 or 8 ipm .
2 Likes
It’s odd that it deviated in the same location for both passes. Have you successfully cut that part in another material before?
Are you using conventional or climb milling?
3 Likes
Is that at the beginning of the tool path? I get that sometimes where the tool plunges in the same location for every pass. One way I’ve used to mitigate that is to make a second profile in CAD slightly wider than the tool, then turn it into a pocket instead of a profile cut. Takes a little longer, but then it’s not a full engagement groove on every pass. I try to avoid cutting tool width grooves anywhere I can except roughing passes.
Dan
1 Like
It seems that the gremlins are alive and at work - at my place anyhow. On trying to run he gcode file, in apiece of wood, it has disappeared completely, no sign of it anywhere on my computer - it’s gone into that big bit bucket in the sky presumably! What I do remember is that in the Vcarve simulation of the original there was no sign of the aberration.
I then generated a second gcode toolpath file from the Vcarve original. On running this in wood it performs perfectly. I am in the habit of having a cursory look at toolpath files before running them on the Shapoko and as I remember it there were differences between the original file and the second file mentioned above. What the specific differences were I cannot recall but there were differences.
Now, I have twice had troubles with Vcarve generating gcode files that perform in an unexpected manner when cutting even though the simulation looks OK. This is part of the reason I look at the gcode before putting it to work. On one occasion the cutter took off in the X+ direction at the same time as ramping the cutter to about 15mm into my workpiece. I looked at the file after that had happened and sure enough the CNC was just following orders and Vcarve had generated faulty code. On that occasion and in the other case I simply regenerated the toolpath and ran that without problems (after carefully looking at the file content).
Just out of interest I am running Vcarve in an old version of XP in VMware Fusion on a Mac. This is the only problem I have ever experienced with this setup.
So where am I heading with this: I suspect but cannot prove that the gcode toolpath was at fault. If ever that file reappears then I will be able to check this theory - but I’m not holding my breath. Thanks to all for your suggestions.
2 Likes
You could be running into a type conversion issue with that setup. Which post-processor are you using for vcarve? If you run the gcode through a simulator like CAMotics, does it look correct?
3 Likes
Thanks Adam. I am running the standard Vectric mm PP.
As for running the code through CAMotics the relevant gcode file has gone AWOL, its has simply disappeared, obviously lost somewhere between Win XP and the Mac. If I had the file I would run it through another toolpath animation application and probably have the gcode graphed in Excel.
You could be running into a type conversion issue with that setup.
Whatever the heck that means! If this is correct I had better start thinking about buying a PC. This frightens me because I have been a Mac user for about 15 years.
1 Like