Kayvon wrote:The post processor use G20/G21, rather than G70/G71. G20/21 are preferred, even when interpreted synonymously, because G70/71 have an alternative meaning that has something to do with repetitive finish cycle diameters. I know Mach3/4 software can take either pair, but even their documentation says, "See also G20/G21 which are synonymous and preferred."
I wasn't familiar with the prior problems causing erratic controller behavior, but the G20/21 used as part of the current post processor files prevents any issues. Additionally, Vectric's software does the mm/in conversions for you behind the scene to align with whichever tag is in use, so there shouldn't be any problems. Unless maybe you conjoin mixed tap files, I guess--I've never tried that.
Right...I was reading backward through the list of G's and came to 70/71 first, not thinking
. Thanks, I'll fix my post
.
There is a significant "perspective" difference that is important to note here: for erratic behavior of a machine in an environment where customization is EXPECTED, it is IMO not acceptable to expect that only the unchanged, company-issued files are somehow authoritative for use. To say that a post file or application is somehow error free is absurd on the face of it. Not only for the bug-free fantasy, but the silly idea that the actual controller requirements (embedded or implied in the post) somehow don't need to be identified because everyone should be using the specific software and post files that they give us. Well, the world doesn't work that way. I use Fusion and BobCAD as well as Vectric, just a few of dozens of CAD/CAM packages that might be used with a Shark CNC controller. Nearly all of those have non-company issued post files as default. Heck, I'm not confident NWA even COULD make a Fusion post file from scratch: it's actual C-style code. The idea that somehow not identifying the low-level requirement to set the units in the file, or that a + in an address value is somehow a fatal error, is the lazy company's way of saying they don't really understand their own controller. They're saying that after many hours, they got it to work, and please, Dear GOD, nobody breathe on it because they don't actually know what made it work. Engineering BS, if you ask me, that results in a) having no real reference as to the system requirements, and b) a bunch of really smart people struggling with and having to figure out why a + sign breaks everything, or why there's a new hole in the bed because of a minor post-file error leaving a crucial setting uninitialized, or why it clips the side of a part on the way out, or any of a number of strange behaviors related to post processor files and often fully-conformant controller behaviors.
I'm sure you remember the excessive G64 value that was in the posts, and causing part gouges and out-of-tolerance parts? Another excellent example of a bug that NWA intentionally put in there. It's things like that that make me not confident that "just use what they tell you" will produce acceptable results. I'm only willing to say "I'll use it if and when my review shows zero changes needed."
.
As for the slicing and dicing, I tend to use the "currently in-use" bit for roughing and the "next in line" bit for finishing, even when they're the exact same geometry. By doing all the roughing and then all the finishing for a single part/machine-setup, and combining the individual toolpaths, I reduce the bit-changes and file-loads to a minimum. When there's just a v-carve and a profile, it's not a problem. When there's 40+ individual features across six different machine setups (think a cube with machining on all sides), it becomes problematic to make even minor changes. In BobCAD, I can output every single one of the toolpaths into a single file, and then my software does the "splatter-gather" operations, stitching them together based on a line in a text file, and then naming them in step-sequence for easy loading.
Cheers, and thanks for the correction, greatly appreciated!
Thom