So do you have calipers? Measure your end mill. Many tools are not measuring wht they say! Ohh that reads weird. Verify your tool diameter is all, lol.
So far as I know, Estlcam is looking for a diameter, and not a radius, however, the actual tool diameter and the width of the cut kerf may not match.
I use various tools, but for example, using the 1/8" mills from the V1 store, I measure them as 1/8" (3.175mm) but if I plug that into Estlcam, I get parts too big, and holes too small. Careful measurement of the slot cut when that tool goes through the wood gives me near dead on 3mm.
A value of 3.1mm gives me parts that don’t fit together. A value of 2.9mm gives me a slightly loose fit. 3.00mm gives me a tight, but manageable fit that glues beautifully in plywood and MDF. My overall size looks good, too. So, that’s the value that I use for 1/8" bits.
I have some other brands and models that cut a bit differently. My 1/4" straight flute router bits seem to like 6.30mm as a diameter, whereas the upcut spiral flute likes 6.15mm. I have a long 1/8" bit that likes 3.10mm, and a long downcut that likes 2.95mm, so it seems to depend on the bit. All of mine seem to like less than the nominal width though. Maybe that’s a property of the local humidity range.
Definitely measure the actual diameter of your end mill. They are often close but can be undersized. Estlecam will take two decimal places, but rounds the displayed value to one decimal space. Not sure if that is different in the newest version. Also, are you doing a finish cut.
I measured the actual cut of a slot and it was 3.1mm so its pretty close to 1/8".
I decided to try the same 50mm x 100mm rectangle with gcode generated by Fusion 360 and it cut at exactly the right sizes with the 3.175 diameter specified.
So - I assume I have something misconfigured in ESTLCAM but have not been able to figure out what.
If anyone has other thoughts or questions I’ll definitely take them into consideration and see if we can find a resolution to add to the forum for future reference.
There are multiple things at play here, potentially. The thickness of the cutter, the deflection of the cutter, backlash in the motion system, a router that’s far out of tram, all sorts.
Thinking of that 50x100 piece, the path the cutter should follow is roughly 53 x 103 leaving a 50x100 piece in a 56 x 106 pocket.
Assuming a perfectly rigid machine and cutter, but either an inaccurate cutter diameter or a cutter that cuts larger/smaller than its diameter, you’d end up with the cutter having perfectly followed the path for a 53x103, but either a part that is undersize and a pocket that is oversize or vice versa. So in that case, measuring the width of the pocket and subtracting the width of the piece would get you a number other than 2x cutter diameter.
Assuming a situation with a perfect cutter that is the correct width and cuts a slot exactly the correct width but has significant deflection during cutting, you’d expect to see the cutter deflect one way or the other based on the direction of feed. If the cutter deflects ‘outwards’ then you’d get a piece that was larger than 50x100 and a pocket that was larger than 56x106. Measuring both and subtracting the piece width from the pocket width would still get you 2x cutter diameter, but both parts will be off-size.
A good sanity check would be to trace the path with something that causes no load. Doing the lightest cut you can still measure would be one option, making the cut in some foam might be one, using a pen to plot the path might be one. If the machine is tracing an exact 53.2 x 103.2 square with no load, you’d then know that it isn’t ESTLCAM or the machine setup that’s an issue.
Thanks for the thoughts - in particular I’ll do a test of the ESTL cam output with a no load option to see what it does.
That being said - I feel like the Fusion 360 test - resulting in a perfect cut - eliminates all variable except for ESTLCAM and points to something I have configured incorrectly.
True, that’s definitely an interesting datapoint. It could always be that something is miconfigured in Fusion and it’s coming out right ‘by luck’, but I’d say that’s significantly less likely.
Another thought is that it’s pretty easy to inspect the G-code directly. That’s a good skill to have when figuring out stuff.
Something to try.
Make a line with a pen on some stock. Position your finest pointed tool on the line (just above) and them move using Estlcam a distance of say 200mm (further the better) and make a mark where that tool lands. Now measure the actual distance covered and if it doesn’t match the distance you told Estlcam to move you need to make some adjustments to the number of steps for that axis in the setup. After getting one axis correct, check the other axis and make changes where needed.
I have the same problem to start with and made these tests and modified the setup and now everything cuts perfectly on size.
You can also do the same with the Z axis. I used a set of drill bits to test with. Using a 12mm drill bit I placed on the workpiece and then positioned the end of the tool on the workpiece and told Estalcam to raise Z by 12mm. If it travelled too far or not enough, tested by rolling the drill beneath the end of the tool, adjustments need to be made there also if not 12mm exactly
Hi I have no exeriance with GRBL however for this kind of problem i would do a pen trace/engrave from both ESTLCAM and Fusion and compare the results (bigger the better). If they are both acurate i supect some differance in your cutting tool paths “Finishing” settings is possible and Climb vs Conventional milling.
yes, climb vs conventional milling is a likely culprit if the same drawing results in different outcomes depending on CAM program used.
In Estcam the milling direction can be changed in the basic settings dialog.
But: if this setting “solves” the issue there is still an underlying mechanical backlash or lack of stiffness issue - the problem will appear again in other situations.
Other possible reason is if the drawing is a SVG file - there are different default DPI settings which can cause different interpretations from software to software (Programs creating SVG should be set to use a fixed unit like millimeter or inch instead of device dependent units like pixels)