Please excuse if this comes across as a rant; it's only partially intended as that.
The vast, VAST majority of things I read about people on this forum having to deal with amount to "errant cuts", caused either by what you're giving the machine, or what it decides to do instead. It's kinda on NWA to solve that second one.
I'd like to talk to you all about that first kind: the one where in fact the toolpaths are WRONG, and HAVE ERRORS. Just because Vectric creates it, does NOT mean it's right. If you don't verify that what you're giving the machine...not what VCarve or Asprire imagines it is, but what you're ACTUALLY feeding to the machine, then you don't really know what is going to happen, and you're trusting a set of systems that time and again have proven they can't be trusted to work 100% of the time without fail, ever, even on Saturdays with the full moon. When it's impossible to generate bad GCode or toolpaths, THEN you can trust it. Until then, verify!
The thing maybe people don't realize is that Vectric's toolpath-display (aka "backplot") is NOT a representation of what's in the GCode. What you see on screen is the display of Vectric's internal representation of the toolpath, which is NOT GCode. Instead, that internal representation is translated by applying the rules defined in the post-processor file ("when you have to do A, put out this GCode..."), and storing the resulting GCode. So, what you see on screen is NOT really what you get out, nor is it what you're sending to the machine. No, what you're sending out to the machine is, in fact, a DERIVED ENTITY. Errors in that derivation can lead to you not detecting that a problem is about to occur.
I've suggested the brand I use numerous times, so I won't call it out by name, but please....I URGE YOU...go find a third-party backplotter, learn it, and USE it. Learn it so well you trust it MORE than you trust Vectric's output. Vow to never again run any cut until you've first inspected it...INSPECTED IT...in that other backplotter. Look for unexplained or really big Z-axis excursions, like if it wants to start the bit 2 feet in the air, or plunge if 2 feet through the bed. Look for when it tries to move the bit to places you didn't expect, or make some divot somewhere. A 10 minute careful check of a large toolpath will do wonders to not only make sure you're going to be successful, but also so you learn more about GCode and how the CAM program is translating your toolpath definitions into actual toolpath GCode.
That said, even backplotters can't do all things. Some will complain heavily if there's no command to turn on the spindle motor, for example. But, they are essential tools in your modern bag of tricks. And, they're nearly all FREE.
I honestly can't count the number of machine crashes, or parts being scrapped, or bits broken, that has been prevented by taking that one simple step.
So please, go find yourself a third-party backplotter and use it. I'll leave out mention of the one I use, but will leave you with this, instead:
https://www.bing.com/search?q=GCode+backplotter
Thanks for listening, and my apologies for being one whiny condescending jerk-face moron....if that's how it came across
.Regards,
Thom
