3-D solids assembly modeling: what's in your machine tool simulator?
Most CAM vendors could assemble some of these elements, but what the user gets can vary widely. Of course, all CAM systems have one means or another of creating or providing access to post processors. For the more advanced machines with multiple, simultaneous cutting devices, and multiple workholding positions, the post processor can be complex. Its use typically requires the correct integration of synchronization codes into the posted output if this type of machine is to be driven to its full potential.
When it comes to the simulation part of the machine tool support kit, the basic 3-D assembly model of the machine tool is the easy part--especially for CAM systems that are based on or come with a powerful CAD assembly modeler built in. For these systems, it's easy to set up and work with even the most complex 3-D solid model assemblies with far more detail than is normally associated with a machine tool simulation set.
It can be a significant benefit to have the 3-D model of the part to be machined, 3-D models of any clamps or fixturing, 3-D models of the cutting tools and holders, and the 3-D model of the machine tool all modeled in the same 3-D solid model assembly set. The powerful assembly modeling functions of full CAD/CAM combination systems make it literally a snap to position parts to be machined onto the 3D model of the fixture that is in turn assembled automatically to the 3-D model of the machine tool.
One thing that is improving is the number of machine tool builders that agree that making 3-D simulation-style, 3-D envelope models of their machines readily available to CAM vendors is of value to the industry and to their common customers.
A kinematic definition
The 3-D machine tool model is more than just an assembly model. It has to have a kinematic definition that defines which parts of the assembly should move, about what axis, and within what limits of travel. Here we need to refer to the machine toolmakers specifications. In NX CAM, all users get access to the NX Machine Tool Builder module that helps turn a basic 3-D assembly model into a full kinematically defined assembly ready for simulation. It enables the user to define each axis, type of motion, the limits of travel, and sets up the naming convention of each element of the machine assembly. It also sets up the automatic tool-mounting and workpiece-mounting positions and orientations that will enable fast, automatic arrangement of these relative to the 3-D machine tool model.
NC into 3-D simulation
However, the really interesting part of the puzzle is the little discussed element of software that works out how to move the 3-D model machine tool assembly model to represent what the CAM software is asking the machine tool to do.
We can start by looking back at what CAM systems have done for years--and still do--that is, to drive a representation of the cutting tool over a 3-D representation (model) of the stock material to verify the toolpath relative to the stock. We still typically refer to this mode as "toolpath verification," and it can be done without any representation of the machine tool present. In standard milling or turning operations, this level of validation of the intended toolpath is often more than adequate. With automatic material removal options selected, the speed of today's PCs coupled with advances in software algorithms can make this level of toolpath verification look quite impressive, and it does the job of proving out the internal toolpath. For this level of software we can simply read the internal definition of the toolpath that specifies exactly where the tool is relative to the surface being machined.
When it comes to the more advanced machine tools with multiple degrees of freedom in their basic motion, or with multitasking capabilities, things start to become a little different. Now we need to understand and show what the proposed toolpath will make happen once the controller and the machine tool see it.
The simplest way for a CAM vendor to approach this is to create software that looks at the internal toolpath definition, like that used for basic toolpath verification, and then turn this into a form of generic motion output that is linked to the axes of the machine model. The advantage of this approach is that it is relatively easy and, most important, it can be relatively generic. At this stage in the software chain, the motion definitions are relatively independent from the final target machine tool and controller make and model. Add in the fact that most CAM vendors choose to utilize a generic third-party plug-in system that takes care of the 3-D kinematics and motion display for them and you have the basic recipe for most CAM systems to build out their machine tool simulation solutions.
The post processor?
As we said earlier, the post processor is no trivial part of the overall system. More important, the only way most post processors pass on their data to the machine tool controller is by way of the well-known "G- and M-codes" and controller specific commands (like TRAORI, WAITM, etc.). Basically, a standardized set of codes that should be universal but, like all standards, becomes extended and interpreted in many different ways by each controller maker and machine tool builder or combinations thereof. Since the controller only has these codes and the attached numerical values associated with them to work from, the exact way in which the codes are interpreted is crucial.
With respect to our discussion on machine tool simulation, the first key issue is this: Shouldn't we be looking at the output of our post processor --the data that we sent to the controller--if we are to simulate the motion of the machine tool properly or completely? To do this, we need a whole new element of software that is an order of magnitude more advanced than the internal toolpath-based simulation drivers.
We need some software that can first intercept the output of the CAM system's post processor for the target machine and second, interpret the G- and M-codes as well as other controller specific commands and associated data fields and turn this 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, even down to the expected target configuration of that machine for a specific customer in some cases. The result however is worth it--a 3-D simulation that is driven by the same G-and M-codes that will go to the machine tool to cut the real part.
This software can also see other actions that may be added by the logic of the post processor but not be present at the earlier internal toolpath stage. The result more realistic, more complete simulation of what the machine tool will actually do. This can be critical in the confined, complex environments of many advanced machine tools, especially those with true, simultaneous multitasking capabilities.
If you are wondering whether your CAM system is capable of doing G-code-driven machine tool simulation, then one test is to see if it has any capability to read in and simulate an NC-program from an external source (e.g., created or modified by hand) or from the machine tool, and written in G- and M-codes. To do this requires the ability to reverse-engineer these codes for the given type of machine and controller.
There are some very good, standalone software packages that offer late-stage validation of the G- and M-codes that can read in the output from the CAM system and use the data in exactly the manner described above. Many production operations have invested in these external machine tool simulation systems, even though it means an extra investment over and above what they paid already for their CAM software.
Given that most CAM systems appear to offer machine tool simulation as a part of their systems, you might have thought that the days of these expensive, external systems were numbered. Not so perhaps when you realize that the machine tool simulators packaged up with most CAM systems aren't driven by G- and M-code post-processor output at all. Also, there is a separate concept of having a really accurate and complete machine tool simulator on the production floor for use as an offline NC program check for prove out without tying up the real machine. Or it might be used for operator training on how to use the machine. Either purpose can have a real value quite outside of the NC programmer's work.
This concept of using separate applications for G-code-driven simulation as an add-on to most CAM systems brings us to another issue that arises when it comes to synchronizing the separate elements of multichannel machine tools. The programmer will want to see exactly where key elements of the machine tool, toolholders, and cutting tools will be at any given instance. This is especially the case at the stage where the programmer is using the software to add "wait" and "sync" codes to the program operation sequence. These codes that manage the multiple machining sequences, like stop traffic signals handling traffic at a busy intersection, are critical in ensuring that multitasking machines don't become multicollision machines.
However, for reliable synchronizing, exact times per operation or NC block are mandatory. To calculate the exact times an exact representation of the controller capabilities along with the axis parameters (acceleration, maximum speed, jerk limits, exact stop windows, etc.) is required. A generic machine tool simulation can only provide rough values, not sufficient when we are looking at fast-moving equipment and tiny clearances when a programmer utilizing the full machine tool capabilities, quite apart from the horror of collisions.
Some programmers will add these codes by hand to the output of their CAM systems post processors and then use their external, third-party machine tool simulation packages to test the whole thing. Of course, if they see issues they either have to do some local, manual editing of the G- and M-codes or they go back into their CAM systems and run through the sequence again, on a kind of trial and error basis. Ideally, we want to have all of that capability available inside the CAM system when the programmer is synchronizing the overall set of operations.
In fact, what's ideally required is the complete integration of the post processor capability with internal "G-code-driven" machine tool simulation, Having that combination linked directly to the synchronization functions inside the CAM system means that the NC programmer has it all at his finger tips in the same software.
The real value of G- and M-code-driven simulation, although a big step up from basic internal toolpath-driven simulation, is dependent on how well the software interpreted those codes and what motion algorithms are applied to try to match what the machine controller and machine tool will do with them.
The next step in getting as close as possible to reality on the machine tool is to try to mimic what the machine tool controller will do with these G- and M-codes and the attached data fields. All controllers have software inside their boxes. Most have sophisticated algorithms used to interpret the data coming at them from CAM package post processors. No two controller makes are exactly alike in this area. So if we are to really simulate the true motion of the machine tool, we need to have some way of replicating what the specific controller software will do with a given sequence of G- and M-codes.
We can do this in one of two ways. We either build software that makes our existing "G-code driven" simulation more accurately (or more completely) represent what we know a controller and machine tool combination will do or, we take a version of the real software that's in the controller and plug that into our machine tool simulation package. If we do the latter, the "black box" software from the controller manufacture can be used to interpret the G- and M-codes in the virtual, digital world of the CAM system, in the same way as it would for real when sat inside the machine tool controller. This we call "controller-driven machine tool simulation." In fact, for both the CAM system or for the floor-based simulator, this controller-driven simulation can take us to a whole new level of completeness and accuracy.
This capability--to offer a plug in version of their controller's software that can be added to machine tool simulator software--is currently available from a small number of controller manufacturers. One is Siemens with their Sinumerik 840D controller that has PC-based software as a part of its standard build. UGS has adopted this Siemens software to offer CAM-based, controller-driven simulation inside their NX CAM system.
Your CAM software may have the coolest-looking 3-D simulation, complete with metallic and reflective surfaces on 3-D models whizzing around. The fact that your real machine tool may not look as shiny anymore is just a pity. But the fact that it might move to a different tune--the one that came out of your post processor, and not the theoretical one driven by the internal toolpath definition in your CAM system--could lead to a really bad day.
To deliver the expected value of your latest, most advanced machine tool what you may need is a G-code driver in your CAM system's internal machine tool simulator, which in turn is built into to the CAM system's synchronization software. To maximize the value of a machine tool investment, "controller-driven simulation" maybe the way to go, inside your CAM system for your programming task and on the production floor inside a stand-alone machine tool simulator for the ultimate in virtual machine tool prove-out. UGS Corp., www.rsleads.com/706tp-154
|Printer friendly Cite/link Email Feedback|
|Title Annotation:||software solutions|
|Publication:||Tooling & Production|
|Date:||Jun 1, 2007|
|Previous Article:||A tale of two siblings.|
|Next Article:||Machining centers.|