Simulating NC Cutting Processes
New simulation tools offer manufacturers more precise toolpath and full-machine visualization
By Patrick Waurzyniak
Simulation software speeds NC toolpath programming and verification, aiding CAM software programmers in the process of proving out multiaxis machine tools cutting complex parts.
Manufacturing software developers have refined a range of capabilities for simulation and verification with more powerful simulations of NC toolpaths, aside from additional visualization tools for plant-floor planning and analysis. More advanced NC simulation capabilities have been added to many CAM software packages over the past few years as multiaxis and multitasking machines (MTM) gained popularity, due to lower machine prices and to the productivity gains offered by such machines.
Programming complexities posed by newer MTM and multiaxis machines mandated that software developers provide users with additional simulation and verification capabilities for programmers to be able to accurately program machinery cutting highly complex parts.
"We have a growing need amongst our customers for making sure that the part's perfect before it goes into the machine, because if you've got $1 million and $2-million machines, an hour of wasted time is a terrible thing," says Bill Gibbs, president and founder of Gibbs and Associates (Moorpark, CA).
With the demand for visualization tools, many machine tool CAM software suppliers add advanced simulation capabilities from CGTech Corp. (Irvine, CA), developer of the highend Vericut NC toolpath simulation, verification, and optimization software package. Other CAM companies either deliver their own internally developed simulation solutions, or instead opt to license a simulation software toolkit from MachineWorks Ltd. (Sheffield, UK) used by OEM CAM software developers to incorporate into their software to handle simulation and verification tasks.
Simulating and verifying directly from G-code offers advantages for manufacturers. Not all simulations are based on G-code data, but instead rely on NC toolpath data generated by the CAM system. "Vericut provides an independent check of the NC program created by the CAM system," notes Bill Hasenjaeger, CGTech product manager. "Using a CAM system's own internal simulation to check an NC program it created is somewhat like a student grading his own test. This is true whether the CAM system is simulating using its internal path data [neutral, not postprocessed], or from G-code, created by a postprocessor, then read back again by the same postprocessor's 'reverse' function. It is a closed loop, interpreting what it created using the same code that created it.
"G-code, the program that runs on the CNC machine, is created by a computer program, usually called a postprocessor," Hasenjaeger states, "but whatever its name or how it is managed by the CAM system, a computer program converts NC path data from a neutral, machine-independent format—sometimes internal in the CAM system, sometimes an external file formatted as APT section 3, or CL data—to a machine-specific format often called G-code or ISO code."
The postprocessor software can make mistakes, he adds. "The mistakes may be due to bugs in the postprocessor program, ambiguous conditions encountered when converting from the neutral format to the machine-specific format, or manually inserted incorrect G-code commands [i.e. human error]," Hasenjaeger says. "These kinds of errors are not discovered when simulating from the neutral path data."
With Vericut, NC commands are processed directly from the G-code program, Hasenjaeger says. "Our software interprets the meaning of the G-code language using a control emulator," he adds. "The control emulator moves Vericut's virtual machine axes and triggers other virtual-machine actions for nonmotion commands, such as coolant on/off, spindle speed and direction, pallet motion, programmable workpiece or fixture supports, etc. The various actions triggered by the control emulator are then checked for correctness. For example, the spindle on/off condition, speed, and direction are simulated. If the Gcode program attempts to cut at an invalid speed, or with the spindle off or spinning in the wrong direction, Vericut issues an error."
Collaborating with CAM software suppliers, CGTech has developed custom interfaces that seamlessly integrate Vericut with CAM packages including the company's recently announced partnership with Gibbs. Under that agreement, CGTech and Gibbs will offer customers the ability to run Vericut under GibbsCAM to easily simulate and optimize their CNC part programs. GibbsCAM users also will be able to directly use Vericut's extensive library of CNC machine models and controls.
GibbsCAM already offers simulation capabilities internally, which enables users to more accurately set up parts, and with its optional machine simulation module. "Our basic software comes with what we call Cut Part Rendering," Gibbs explains. "Its responsibility is to allow the customer to verify that the tool is cutting the right part. It's what we call a part-centric view of machining. It focuses on tools, toolholders, primary fixtures, and the part itself, and it does this for all the machines programmed—mills, lathes, mill-turns, and MTMs. When you step up to Gibbs' simulation [optional module], the user now has to set up the part more accurately in the machine, and he's also responsible for building his own machine models. We provide basic models, but we don't offer the service to build all models for all machines.
"For our simulation, the user does his own models and simulation is integrated directly into GibbsCAM," Gibbs adds. "CGTech's a little different. It is a much more expensive product. CGTech has a wider variety of analysis tools that come with it, beyond just simple verification. It offers optimization, and CGTech will provide the machine model building as a service. Another difference is that CGTech will offer G-code verification, and we do not offer G-code verification at this time."
Eliminating toolpath errors as early as possible was a major goal with the latest CATIA Version 5 Release 17 (V5R17) from CAD/CAM software developer Dassault Systèmes S.A. (Paris) and its Delmia Corp. (Auburn Hills, MI) subsidiary, notes NC Kishore, Delmia manager, machining solutions. "In V5R17, there's a major release with a new way of doing things," Kishore says. "We wanted to help NC programmers to be more productive and significantly reduce the time taken for an NC program to reach the machine on the shop floor.
"Our latest software enables NC programmers to eliminate toolpath errors as early as possible in the NC code-generation lifecycle, rather than wait till the end of the simulation. Instead of doing that late in the whole cycle, we are enabling them to eliminate error up-front, much more upfront in the whole lifecycle of the NC code."
By integrating its CAM and simulation systems, CATIA V5R17 significantly speeds up the process of proving-out NC toolpath programs, Kishore states, when compared to the traditional flow of data between CAM and simulation systems. In the traditional CAM and simulation approach, NC code data goes from the CAM system to an APT/CL (Automatically Programmed Tool/Cutter Location) file, to the postprocessor, and then to a reverse postprocessor before simulation, explains Kishore. With CATIA V5, the postprocessors from CATIA partner companies ICAM, CENIT, and IMS, are integrated within CATIA's CAM system.
"Traditionally, with the flow of the given G-code, they have a CAM system, they generate APT source, CL file, postprocessor, reverse postprocessor, and then simulate it, before it goes to the actual machine," Kishore says. "With this flow, the problems are always identified late in the lifecycle, and that's typically during the simulation of the NC code on a simulation system. And when he finds a problem, what does the NC programmer need to do? He needs to track back to the APT source/CL file, then go to the CAM system and fix those problems, and then regenerate the whole thing again. So he generates the APT source again, and generates the postprocessing again.
"Once a collision is detected in a simulation system, they have to fix it in the CAM, and it's a long process," adds Kishore, noting that an NC program can be 100,000 lines long. "Following a cure in the V5 environment, the machine simulation is again integrated up-front, so they can simulate the toolpath even before they generate the NC code, and eliminate those errors up-front."
With its direct postprocessing methodology, Kishore says NC programmers have integrated postprocessing applications within the CATIA V5 environment. "Since they all do the direct postprocessing, there is no need for an NC programmer to generate or interact with the APT source file at all. The NC programmer specifically does not have to do those steps, because it is done in the background. It is still an option; if the NC programmer still wants to interact with the APT source file, he can still do so, but here is a better way to do it in CATIA V5. The whole cycle is compressed 50%, compared to the traditional flow."
Extending its simulation capabilities, CAD/CAM software developer UGS PLM Software (Plano, TX), the former UGS Corp. recently acquired by Siemens AG (Munich), has added to its G-code-driven simulation capabilities in the NX 5 CAM package announced in April, which now also includes controller-driven simulation.
In the new NX 5 software, UGS has added to its capabilities for machine tool simulation by intercepting the output of the CAM system's postprocessor for the target machine. According to UGS' Vynce Paradise, the system interprets G and M codes as well as other controller-specific commands and associated data fields, and turns the information into corresponding motion inputs for each axis or controllable device on the machine tool. "This requires a detailed knowledge of the specific target machine tool and controller, with the resulting effect being a more realistic and complete simulation of what the machine tool will actually do, since it is driven by the same G and M codes that will go to the machine tool to cut the real part."
Unlike CAM vendors using MachineWorks' simulation toolkit, the company uses its own internally developed simulation, Paradise adds. "We're quite unusual in that sense. We didn't take a toolkit. We looked at toolkits, including MachineWorks', but that's not used for machine tool rendering, it's used in our modeling software. MachineWorks itself comes as a toolkit—you can do what you like with it. It's a basic kinematics and model-display program, and how a CAM vendor chooses to drive it is really up to them. The folks at MachineWorks, they're not experts in machine code, they just give you the kinematics, and it's up to the CAM vendor to decide how to drive those kinematics systems.
"What most CAM vendors will do is to choose the straightforward option, which is to drive it off their internal toolpaths, because driving off the G and M codes, the next stage in the process, means you have to write a reverse-engineering piece of technology to reverse-engineer the G and M codes back into motion, to see what the controller is doing—and that's a tricky thing to do. It's very time-consuming, it's very specific to individual makes and models of machine tool and controller, and most CAM vendors just don't have the bandwidth to get into that space, so they do a more generic simulation off their pre-postprocessed data."
In addition to G-code simulation, UGS also now offers controller-driven simulation. Working with Siemens, UGS' controller-driven simulation in NX 5 integrates a version of the software used on the actual machine tool to replicate what the specific controller will do with a given sequence of G and M codes on the machine tool. With this capability, the system can consider elements of the equation such as acc/dec, and true swept paths, as well as having access to the way in which special cycles are utilized, says Paradise, adding that the controller-driven simulation is similar to what CGTech has offered with the Siemens Virtual Numerical Control Kernel (VNCK) that has been available in the Vericut simulation/verification software package for some time.
"Basically, we've done the same thing," Paradise adds. "They're unusual in that they are one of the first machine tool controller companies to have software on the controller that runs under Windows. An analogy I use here is a flight simulator. If you have a flight simulator to simulate an aircraft, a software programmer knows how the aircraft will react; you can take software from the advanced aircraft itself, the software that drives the controls in the aircraft, and embed that into your simulator. And of course, you can imagine that the response at the controls is going to be more complete and accurate when you're using the software from the actual aircraft in Flight Simulator. This is exactly the parallel here. We're taking the software from the controller itself and using that to analyze the G and M codes, then look at what the responses will be to drive the kinematics."
This article was first published in the June 2007 edition of Manufacturing Engineering magazine.