A programming “knowledge library” is a collection of the tool, parameter and toolpath choices associated with workpiece features that occur repeatedly in parts throughout the shop. For example, a particular hole may always be machined with the same series of spot drill, drill and tap. Or, a particular programmer may prefer to always mill certain flats using the same series of rough and finish tools. In cases such as these, CAM software can offer the ability to store the preferences in a library so the programmer can easily call up the relevant machining routines whenever the recurring features appear.
Of course, storing programming knowledge is nothing new. Programmers have done it all along. Using a “crib book” or some similar notebook (often covered in Post-it notes), a programmer can record what tools and strategies worked once with certain materials and conditions to avoid having to rethink the process when similar circumstances arise. In fact, according to John Callen, frequent use of crib books is a clue that a particular shop ought to convert to a CAM-based library.
Mr. Callen is marketing vice president for Gibbs and Associates, the Moorpark, California, creator of GibbsCAM. Beyond programming efficiency, he says the far greater value of a knowledge library is the chance to standardize a shop’s programming “knowledge” by having programmers draw upon a single library together. Referencing standardized processes ensures that programmers machine the same features in the same way, and in particular, that they use the same tooling choices. The shop can thus make machining cycles more consistent and predictable, and it can reduce the number of different tools it has to order and track.
Knowledge libraries also address a potentially greater source of uncertainty that weighs on many shops. Namely, what happens when an experienced programmer resigns or retires? A CAM-based library allows a shop to define and maintain its preferences independent of particular employees, and keep those preferences in play as personnel change. The library also lets new programmers ramp up into an effective role for the shop more quickly.
Mr. Callen says GibbsCAM includes various features that relate to knowledge libraries. A “Save Process” feature allows the library to be populated through the programmer’s regular work. If the programmer makes a choice that deserves to be repeated for similar features, then Save Process can save this choice as a library entry. Complementing this is the “Multiple Process Programming” feature, which expands the definition of a process by allowing a sequence of tools and steps to be grouped as a unit and applied together. One advantage of this latter feature relates to design updates, because rough and finish passes grouped in this way are revised together if the underlying geometry changes. However, another advantage relates to the knowledge library, because a series of tools and steps—the aforementioned spot/drill/tap, for example—can be saved and applied as a single library entry.
The knowledge library itself is based on a file structure. The user controls the organization of the library by creating directories. A subtle advantage of such a structure relates to politics, Mr. Callen says. If a shop sees the value of standardizing programming, but has multiple long-time programmers with separate opinions about the best ways to machine, then does the shop have to choose among the different programmers’ methods?
Maybe not. The file structure permits a library that is not entirely standardized. Specifically, for long-time programmers named Bob and Joe, the file structure can allow for directories named “Bob’s Way” and “Joe’s Way.” The shop can then standardize within the area where Bob and Joe agree—a level of standardization that still stands to be significantly better than no standardization at all. Then, when Bob or Joe retires, the shop can look to that programmer’s preferences to decide which processes ought to be kept as part of the shop-wide practices.
One darker aspect of knowledge libraries can’t be ignored—the fact that the library can be copied. All knowledge tools have this weakness. If the purpose of the shop’s library is simply to standardize programming, then this possibility may not be a concern, but what about the shop whose library includes proprietary best practices? A CD or memory stick might let someone carry this library away.
This danger is still no reason to avoid using a knowledge library. After all, the alternative of relying on individual programming knowledge simply impedes the spread of best practices—and it doesn’t leave the shop any more secure.
Mr. Callen predicts that as more shops become specialists in particular markets, and as more of these shops standardize their programming, the challenge of securing programming knowledge will become more apparent. A technological solution is likely to present itself, he says. If it doesn’t, then it is likely that innovative shops will find some procedural solution that helps make critical house knowledge more difficult to transfer to other settings.