Also, I just realized that I was using the default uncalibrated $100/101/102 values (I keep messing with my GRBL params all the time and more often than not I forget to restore them)
@kylea / @neilferreri, are you using calibrated $100/101/102 params? I wonder now if a very subtle difference in X or Y or Z calibration versus the other two, could lead to that effect.
First thing I checked…mine are good.
Throwing these files up quickly…
V-Carve - testForumVCarve_cornerSQUARE.nc (1.1 KB)
Fusion - testForumFusion_cornerSQUARE.nc (645 Bytes)
Easel - testForumEasel_cornerSQUARE.nc (1.4 KB)
I did not pay much attention to feeds as I was trying to test late last night. Anyway, I saw the effect in corners of all three.
I guess we need someone with a Nomad to run any of those G-code samples, or any v-carved corner really, to see if the increased steps per mm alone fix this. At least we would know whether the resolution thing is a good lead or not.
@Radiation, @enl_public if you are listening ? 
hi,
I don’t have time at the moment, I would have tested the program too. I find it strange that there are differences in precision from one shapeoko to another… (apart from mechanical or software concerns…)
I’ve never had a precision problem on mine.
what’s the point of changing the GRBL $100/101/102 parameters?
and how do you do it?
maybe I change the subject… 
haha, no way! I’m gonna run it. I just ran into a hiccup, I blew up my cncjs on the pi trying to update things, so I’m falling back to an amd64 build on a laptop 
Should get it done in the next day or so.
It’s a way to compensate for belt stretch: https://docs.carbide3d.com/shapeoko-faq/how-to-calibrate-the-machine-for-belt-stretch/
But if you get precise enough results for your needs as is, don’t bother. It’s easy to become obsessed with calibration (I would know…) and at the end of the way it’s more efficient to just compensate for dimensional inaccuracy by tweaking the CAM.
Yeah I can run a thing.
Thanks everyone! I’m looking forward to seeing more test results.
If I get the chance tomorrow, I’ll see if I have a tool for this (I don’t do vee carving, so my tool selection is limited that way) and try it, if it hasn’t been resolved yet. Right now, the machine is hammering away on a large chunk of PEEK.
EDIT: I found a 60deg bit. I will run a sample on Nomad…
Here’s one way to calibrate with a caliper:
Changing CM or grbl firmware won’t be impactful. CM is basically just a fancy serial port transfer tool, and grbl firmware hasn’t experienced issues that could be attributable to something like this in a very, very long time.
mmh, by the way, how come the CC preview on an advanced-vcarved rectangle shows a very similar looking effect in corners ?
VCarve preview for a similar case shows a “perfect” simulated corner:
It might be a completely different matter related to the way CC computes the preview, but I still wonder about the coincidence.
EDIT: yeah it’s a CC preview thing, because the generated toolpath itself shows that more material will be removed in that corner than what is being rendered (see green move partially hidden in material, and the diagonal pass for the last pass is completely buried under that.)
The other question I have now, is why would the post processor need to do these diagonal moves at all in perfectly straight corners, just taking a sharp turn would work?
.
EDIT:mental note to not post before morning coffee
Thanks Julien. So I may not be interpreting your conclusion correctly (Only on my first cup of coffee). Is the fact that this anomaly is showing up in the CC preview a validation that the machine is cutting exactly what the code is telling it to cut? And, I guess I’m unclear why Aspire and CC show different previews. Thanks again.
Aspire and Carbide Create are two different programs with different toolpath approaches — it’s to be expected that their previews are different.
The 3D preview of the cut, and the 2D toolpath preview in Carbide Create are optimized for speed of rendering at the expense of verisimilitude — it’s best to verify the preview in a 3rd party tool if need be.
As regards this issue, here are some things to consider/investigate:
I would suggest making a series of test cuts using the same endmill, but which are defined as the tool being somewhat more or less acute than is specified and see if one of them yields a perfect corner.
to put the preview issue to rest… has someone tried the various gcodes in camotics ?
Here we go.
I redid the form in Inventor, because I know it well and it was faster than confirming all of the other gcode here for the tool I have.
The tool is a generic import 60 deg vee, 3.175mm dia, 0.1mm end flat, ran it at 10KPRM, 1500m/min feed.
The profile is a rectangle, 1.5mm wide on the sides, 2mm on the top and bottom, just because I figured that if there is an issue, the change in width will highlight it. (pic of screen since the camera was in my hand…)
The entry and exit were at the lower left corner to get
cut into my well used wasteboard (it is over a month old now. less than 1mm to the aluminum under the engrave here)
You’ll note that three of the corners are pretty dead on, except for fuzz. The fourth, where the entry was, seems a little kicked out. The fuzz makes it look a little worse than it is, but it measures about 0.2mm out at the corner. (measured with a Bausch and Lomb magnifier like this: https://www.bausch.com/our-products/vision-accessories/professional-magnifiers/hastings-triplet-measuring-magnifiers using a 0.05mm graduated scale. Don’t look at the prices of these. I got mine way back when I was in the semiconductor lab. Watch for fakes, by the way)
Why is this? I have a few guesses.
First, tool deflection. When the tool came back around on the fourth edge, it would have been pulling the right a little looking from the front of the machine (left from the perspective of tool travel). As it broke through the the clear at the entry point, the deflection would be relieved. The nomad is pretty rigid, but the engraving is pretty much plowing through solid, so the tool will push hard and the stickout was 19mm or so (I used my 19mm gauge when I put it in).
Second, tool profile doesn’t help. Checked on the comparator, the angle is within a degree, but the tip profile is a little odd. The edges flare slightly at the end. The flat is 0.1mm, but the angle changes over the last 0.2mm or so of the cutting edge
I thought it might be an illusion, so I checked it on another machine.
Visible here, as well. A good look under a microscope showed the same thing. Small, about 0.05mm to either side-- it looks as if the end of the tool is the theoretical point from the cutting edges, and the flat is formed by flaring the edges slightly. This will contribute to the corner issue, as when the tool retracts to draw the sharp up to the surface, the tip geometry will be a bit off.
For those curious about the setups on this (I like my comparators. Darn useful)
Using the HDPE riser to get backlighting from a surface illuminating source
Setup for the contour illuminator (telecentric) on the other machine:
And the profile with the tool rotated, showing the cutting edge clearance is pretty significant here. It is still between the 60 degree lines.
And the g-code, if anyone cares:
engrave-test-60deg.nc (1.7 KB)
@kylea : my thinking there was that if CC preview anomaly is linked to a precision limitation in the way it renders thing, then maybe that could provide a hint as to the root cause of the issue in the real cut, just by analogy. But that’s far fetched and probably not valid.
@WillAdams is right that the very first thing to do is the famous test where one cuts the same rectangle but generating the vcarve toolpaths for vbits declared to have subtly different angles for each rectangle, e.g. 59.1, 59.2,…60.9 and then visually check which one grants the best corners. I seem to remember we did that last time and it did not fix the issue then, but it is definitely important to do the test anyway to make sure what our Vbit angle actually is. If it is not spot on 60deg, there will always be artefacts in the cut.
@fenrus good idea, but I need to figure out how to increase render resolution in Camotics, by default on small objects it’s noot good enough.
@enl_public thanks for the test (and cool tools there !) but is it just me or do the four corners look ever so slightly “pinched” in that picture ? maybe it’s an illusion. It’s much closer to perfect than in our other tests at least
EDIT: I’m away from my machine but of course I’ll test more when I get a chance. I would love it to just be a tool angle thing.
Three of the four are very slight. It looks worse due to the fuzz. I think it is due to a combination of bit deflection and the form at the tip of the tool. The inside-corner motion seems to have cleaned the fuss a little at the corners, as may also have contributed by relieving the deflection load on the tool (guess, but it is consistent with the result). I’d call these pretty close to dead on, as the offset isn’t large enough t measure without pulling the wasteboard (less than 0.1mm)
The forth corner is much worse, and I am fairly sure the primary issue is deflection of the tool. When the tool reaches the endpoint and breaks into where the start was, the tool loading and side thrust relieve.
I have a long 1/8" bit that is prone to deflection, but that deflection only occurs when I push it with deep DOC and speed. Reducing DOC is the key to deflection for me in the wood I carve at my favorite speeds.
Also, I’ve followed a toolpath with a problem corner with an open vector toolpath just to clean up the deflection.
camotiocs : edit->settings has the rendering resolution
the interesting thing also there is that you can change the angle of the tool in the renderer until the simulation matches reality.
that gets you how many degrees off the bit is, just in the opposite direction
very good point, I’ll try that !
