xoneeleven wrote:Thom,
I have actually considered doing what Thom suggested and breaking down the design. However, at this point, I am not convinced it is a design issue. That said, I will certainly be following Thom's advice on troubleshooting.
The breaking down of the design, that I requested, was to get rid of any confounding issues that might either mask the issue, inadvertently cause the issue, or just make the troubleshooting process needlessly longer.
I agree this is not a design issue. Nor a post-processor issue. But, in some cases, it also might be unavoidable without the application of $$$.00.
If I'm correct (admittedly a big IF), the root cause is that the stepper motors don't actually work at the same 0.001" resolution (or the equivalent in mm), because they are on a 1/4" per turn lead screw (two threads), but the motors only have 220 steps. That means that each full step of the motor is actually 0.00114". When the virtual Z is used to create a flat pocket, and the virtual-z offsets are very small, the z-axis movement demonstrates the equivalent of aliasing. If you can step-jog incrementally by 0.001", you'll hear a distinctly different sound as you jog through every about 7th increment (1/7 = 0.1428...).
I have previously seen what I believe might be the same thing. In my case, they were completely benign, but visibly present in a 0.002" deep engraving that was mapped onto the slightly sloped surface of the part. The below image is about 1/4" top-to-bottom.
- 0.002" deep engraving into a glass-bead blasted aluminum surface
Manual touch-up of those parts is not possible, especially not when I make them in production lots of 50 pieces.
In my case, I didn't use the virtual Z, but instead mapped an engraving path (again, restricted to 0.002" deep) onto a slighly inclined model of the actual deformed part stock (0.010" deformation across 1.5"). Yeah, it turns out that 90-degree aluminum angle isn't exactly 90-degrees when you're talking thousandths accuracy. The issue of motor resolution versus system resolution is detectable as a regularly-spaced just-slightly-off depth engraving that is not evident in the GCode, even when calculated to six decimal places. And yes, you guessed it: slightly off BELOW the expected surface.
If I had to guess, you're using a non-radiused (aka sharp-tipped) endmill, and your spindle/router is just slightly out of "tram". When the virtual-Z is calculating the needed position, it's adding very tiny amounts into the movement. Across wide areas of only very small height deviation, those aliasing effects can show up, and when combined with the out-of-tram spindle, make that visible. To help alleviate this, use radiused endmills (e.g., 0.030 radius on a 1/4" bit) so the transitions at the edge of the cut will be smoother, and ditch virtual-Z.
To put it plainly, wood warps as a cylinder. A cylinder cannot be accurately modeled with a pyramid, which is what virtual-Z tries to do.
To my mind, when working with reasonably flat wood, virtual-Z is more of a pain than it's worth. And when you're clearing out a big area, it's useless. The idea behind virtual-Z was that it could more-accurately place shallow features onto a surface where the surface deformation is significant WRT the intended features. Unfortunately, it requires a minimum of 9 points to even begin to model a cylinder. I'm guessing they decided their customers wouldn't put up with that many touch-offs. Not to mention that flat touch-off plate makes it difficult to even accurately capture a concave surface.
V-carved paths are especially vulnerable to the effects of different surface heights, since the change in apparent path width is very perceptible to the human mind. It's kind of like how easy it is for us to detect when circles aren't truly concentric. But, when you're trying to create an at-depth, flat surface, you don't care AT ALL what the old surface deformation was, because you're cutting it away.
Therefore, when I'm clearing any flat area down from the surface, I would never use virtual-Z. In fact, I never use virtual Z at all, because the implementation does not properly accommodate the material deformation it was intended to overcome. But, for me, it's really more because I'm doing aluminum smaller parts. If the material stock will be "normally" deformed, and I need a shallow feature carved in, I'll build a model in Fusion that represents that deformed stock, and then map the toolpath onto the deformed part's model, then cut that. And, if there are minor deviations where the model isn't exact, I'll use my GCodeShim tool to nudge a section of the toolpath in the appropriate direction. But, none of those techniques gets away from the underlying aliasing of vertical positioning: it's still there.
The reason, as I'm sure you're guessing, that you don't see any problems in the GCode, is that virtual-Z height offsets are added AFTER the GCode is produced.
Now for the good/bad news. This issue will be present on all machines whose native resolution is not actually the 0.001" the software systems believe. And by that I mean pretty much ALL machines that use a) 200/220-step motors, and b) that cannot micro-step with sufficient position-holding torque for the Z-axis. The shark, and potentially all units in the <$20K range will exhibit this behavior. The only real way to avoid it is to get a machine with true z-axis resolution well under 0.001". That can also be fixed with a 10x zero-backlash reducing gear on the Z-axis. It depends on how important this is to you, just how much you're willing to spend getting rid of it.
But for you, right now, I believe the simplest way to get rid of those, then, is to stop using virtual-Z
All those questions? Those would allow us to positively verify that is exactly what is happening at that moment in the toolpath.
Seem plausible? And yes, I'm okay with being completely wrong, if you're not actually using Vitual-Z.
. If I'm not proven wrong every day, then I'm not trying hard enough!
Regards,
Thom