We use cookies to personalize content, interact with our analytics companies, advertising networks and cooperatives, and demographic companies, provide social media features, and to analyze our traffic. Our social media, advertising and analytics partners may combine it with other information that you’ve provided to them or that they’ve collected from your use of their services. Learn more.
Hey all,
I’m trying to do an inlay with sharp corners. I’ve got everything sized correctly and the parts fit well, but I can’t get the corners to be square. Everything looks great up until the last pass of the toolpath when the v bit needs to travel up and down the corner, making a sharp point. The bit seems to be too wide for the movement and cuts into the adjoining faces, making notches on either side. I’ve included photos for reference. I’m very sure I’ve seen a video somewhere or read a thread about this problem, but I can’t find it for the life of me. I was also going down the path of possibly a wrong angle size on the bit, but I can recreate this problem with both a 22° lining bit and a 15° tapered bit.
If anyone can point me in the direction of how to correct this, I would be greatly appreciative.
I’m using V-Carve Desktop to create the toolpaths and using the x-carve post processor to import the g-code into Easel.
This is the pocket using the smaller 15° taper from Bitsbits.com. It has a very small flat tip (I think .15, I’d have to check.) Same issue on the corners.
I have not. I don’t have Easel pro, but I think I should use a free day to try a few pieces to see if it’s a Vectric thing or an X-Carve thing. Thanks for pointing that out.
I could be wrong but I think that the Vetric software is meant to work with mach 3 or 4 machine code depending on the purchase date. The mach 4 update has tool paths for this specific purpose which may not be able to be processed properly with the open source code used with the x carve processors. This is my hang up in purchasing an x carve, which I have been considering. I would prefer to use Vetric if at all possible… This was my primary consideration, however in reviewing some of the forum it appears that the gantry design has required a stiffening modification to accommodate the additional weight of the Dewalt spindle configuration and this has become a consideration as well. Please let me know what you find out and if I am able to speak to the inventables staff I will do the same.
I’ve tried two different bits, and the reason for the smaller angle bits is to allow for a deeper inlay. I have a 60° and a 90° bit that I’ll try, but then I’d have to redo the math to get the inlay and the flat gap to be correct.
I think you might be on to something. I just did this very quick test. The pocket is done with Easel Pro and a 15° taper flat end mill (with a .015 flat tip) The other cut out is a project I made in V Carve, but where I told V Carve I was using a 17° bit. The corners show a very little bit of the problem, but not as much as it did when it thought is was a 15° bit.
I doubt that the deflection is present in the G-code. This is probably flex in your X-Carve. Easel won’t show you the path if it comes from imported G-Code. You can preview the path in V-Carve, or there are other packages that will let you look at the G-Code that V-Carve produced. This should tell you if your problem is in the G-Code.
I really don’t think it’s the gcode itself. The VCarve preview shows up perfectly. And, the same type of pocketing procedure done in Easel Pro looks perfect in the wood, meaning no deflection (or as little as possible) in the X-Carve. The problem only exists when I save a tool path in VCarve using the Easel post processor, and import it into an Easel project. But that’s where my knowledge is lacking.
I have since discovered that Easel does not support the “arc cutting” tool path. The VCarve software is updated to give a tool path that uses an arc cut to square up the corners with the V tool and that the Easel software improperly interprets this arc tool path. Going by your photos it seems that it is seeing the arc because it begins to deviate at about the same area that would be the last cutting paths, but cutting too deep to accomplish it. Try insuring that your Post Processor is set to the correct model of machine you are using in VCarve before you save it to export it. I understand that there is a drop down box to select your machine and it should be one of the last two on the list.
Is it Easel or grbl? The fusion 360 post processor for x-carve and generic grbl has an issue with creating arcs that grbl doesn’t understand stand, which the Carbide post processor has fixed.
Well that’s a bit of information that’s interesting. I figured that geometry being what it is, the corner squaring move with a v bit would be a straight line. Since all the previewing I did to try and catch the one corner clearing move, I started to figure that perhaps my problem is that the plunge rate was too slow, and that the X and Y were moving too fast. I also thought that maybe my Z rate is in fact off. I have a stock X-Carve and wonder if the plunge rate can really be calibrated that closely. I did try to save the VCarve tool paths with Vectric’s X-Carve (in) post processor, but when I tried to take that into Easel to run the gcode, Easel gives a notice that the Inventablesd post processor needs to be used. I had already downloaded and installed the Easel/Vectric post processor, which appears to be the only one that works. And since I’m not to versed on what the post processor is doing, and I’m only just beginning to understand gcode, I don’t know if I could use any other post processor.
I really wish I could find the thread or the video that went into detail about this problem. I remember thinking at the time that the information was interesting, but since I wasn’t doing those inlays yet, I didn’t bother to keep track of it. Now I’m kicking myself for losing it.
The corner moves with a v bit… How do those moves get translated to g code? As I think about it, of course the v bit needs to move in an arc to get the corner sharp. But if g code gives an X:Y:Z start and end, is it up to the machine controller to figure out the math? Is it the post processor that does that? In my testing, if I make a tool path within Easel Pro to cut out a pocket with square corners, it does it no problem, with any angle bit I use. Where is the disconnect then if I import a g code with the same shape into Easel and it no longer cuts the shape correctly? Where is the failure?
My problem is now solved. I spoke with Inventables today and they confirmed that there is no arc interpretation for imported g code. In using UGS, my toolpaths work as expected from VCarve Desktop. I have learned a ton along the way. I’ve just scratched the surface of g code, and I can tell it’s going to be a deep rabbit hole!
Thank you to all who gave out info. It was very helpful!
Hi Tony,i’m having the exact same issue you’re having, but i’m actually creating my toolpaths in easel and carving in easel. How do i stop easel pro from rounding out those edges? i’m going nuts.
Definitely. It’s the same problem as I’ve read on the forums dating back 3 years ago. On the last pass of a v carve, the took path goes into the corners trying to sharpen the corner and sinks the bit in too deep Causing a rounded edge…which will then leave a gap in the inlay.
This is an example of just today, trying to figure it out by carving a simple letter L that is .2 deep. No took change…/just using a 20 degree v bit for the while carve.
And my machine has ZERO play in the z axis. (Or any axis for that matter.
Others mentioned this problem when creating the tool path in other programs and using easel to run the g code. But in this case everything is done using easel from the start.
As I was told by Inventables, the issue is that Easel does not do the math to move the bit in the arc that’s needed to make the squared off corners. What is happening is that the final pass of the v bit is an arc in the z axis, and the machine is running it in a straight line. The angle of the bit itself is rounding out the edges. This was what I learned, and was the point that I dropped using Easel for anything more advanced than just cutting out shapes. I moved to VCarve Desktop and transitioned into UGS. Yes, I had some issues with the newest version of UGS (it would skip the 4th or 5th line of code, gouging a line across my work piece), but by using the previous version of UGS, I was able to create the cutouts you are trying for with no problem.
I can’t remember if Inventables told me that it wasn’t possible at all, or if I’d need Easel Pro. I know I tried a free Pro day to try and fix the problem, but It did not make any difference.
Easel doesn’t use arcs, but it generates a linear approximation. What math did they say was incorrect?There should be no arc in that move anyway. It should be a straight line. @CalebASanz
Typically, big dimples like that in V-carved corners are a function of:
