Thanks for the Ncviewer recommendation. I used to use NCplot years ago, but when I switched computers a few years back I lost my license, and never bought one again. While pretty basic and it doesn't pickup g70-72 canned cycle parameters (NC plot didn't either) it works great for visually double checking my finger cam lathe programs for egregious errors. It'll come in handy as I try and teach the young guy here how to program and run the lathe over the next couple months. He's more of a visual guy like me. Thank you!
For mill programming I use Edgecam, and it has a good backplot built in automatically (most cam does now anyway). Very rarely do I ever run full sims anymore to check for issues. If it looks good, it is good. After years of tweaking my post processors for our machines, I know what is on the screen is what I'll get at the machine. Any of the errors I usually make are almost never in the toolpath, it's always the wrong TLO or something similarly fat fingered. Catching that by reading the program at each toolchange, and watching the distance to go, is a great safety net habit to get into. Sometimes the idiot at the desk, tries really hard to out idiot the idiot at the machine.......Best be on your toes.
As for toolpath editing. I/we don't do much production, mostly one offs, high precision tooling work with a lot of 3d surfacing. But occasionally a job will come in the door that is too good to turn down, or we'll help the shop next door with some over run. I usually strive to get something running quick with the bones of the program/fixturing in place, and making dimensionally good parts. Then from there I can pare away at the program by CAM and by hand, cutting out extra air time, and extra moves, taking more/less aggressive cuts. etc All while the machine is making good parts. For the one offs i do, there is no point in trying to edit programs for outright speed, as it's pretty easy to sit down for 10 minutes picking away at a program trying to shave 2 minutes off. Not worth it, just make a note of it, change your approach and get it on the next one. After a day or two, you get pretty good at making efficient one off programs out of the gate, just by paying attention to the details along the way, and doing it right the first time. I still have occasional "why did I do it THAT way" moments, but heading back to the desk to make changes, eats up whatever time I would have saved anyway. I save a lot of time by using the same parameters and cycles for the same tools and approaches. Hard to explain, but it's my way of turning ones offs into production runs in a way. After a while the built up tool libraries and cycles make it pretty cut and paste, freeing up time to do other things.
Programming for production vs one offs is like running. There are marathon runners, and there are sprinters. A marathon runner would get slaughtered in a sprint race, just like a sprinter would be gassed quickly in a marathon. Sometimes you need to sprint, and sometimes you need to run a marathon. It helps to have both arrows in the quiver, and use them when required. We've had production programmers in here before, and that mentality doesn't fly with one off, and special ordered material. You can't "burn" a few parts/blocks to dial in a program/tool to get it running right, and roast tooling constantly just to save a few minutes of cycle time on a 4 hour program. Alternatively, you can't spend all day trying to write the perfect program for a 10 run production of $50 dollars worth of material, which you have racks of. Totally different approaches. I am a much better one off programmer, than production, but I enjoy the process of production programming more. When I get to the point of a nice efficient program spitting out parts, with reliable tool life, I want someone to take over quickly though.
Editing stuff in CAM is only so good, some programs are better than others. I think the final seconds to come out of a production cycle are best done at the control, or in notepad, by watching and learning what the machine is doing line by line. The hard part then becomes documentation, when the job comes back in months/years, and you need to pickup where you left off. Brackets () in the program are great to explain what's happening, and I use them a lot for production programming, not so much for one offs. That's another can o worms.....Take lots of notes, and have good housekeeping. It pays off.
Knowing what your machine can get away with is another story altogether. A bit of a learning curve programming my Tormach after years of running Haas'.....Every machine is different. Even our Haas' from the VF6 to the VF2 need different approaches for some stuff. Not having a toolchanger means more holes get helical milled, vs drilled, etc....
Wow, sorry for the rambly ADHD info dump.....It's a subject I enjoy a great deal, and have made a living doing for almost 20 years now and still learning new/better ways of doing stuff all the time.
