1.4.1 Variant CAPP Systems
A Variant CAPP system is suited to dealing with a set of designs that tend to be variants of other standard designs. The basic concept is that new process plans are not completely redone when a new design is received. An existing process plan for a similar design is used as the basis for the new process plan. The old plan is edited to compensate for the differences. This reduction of human intervention provides advantages in terms of efficiency, reliability and standardization. But, human intervention is still required for adapting the plan for the new part.
Nolan [1989] presents a thorough overview of Variant planning as well as making a good case for its use. There are also a number of papers discussing Variant planning systems [Emerson and Ham, 1982] [Carringer, 1984] [Mehta et. al., 1990].
Variant systems are probably best explained with reference to Group Technology (GT) codes. The decision to use GT should be determined by product variety. There must be a large number of parts that can be divided into groups, based on geometry, function, or production. The first implementation stage requires the development of a GT code. This code must then be verified. To verify the code, a sample of parts (10-20% of all parts is suggested) must be coded, then the results examined critically. If there is too much duplication, or too few similarities between codes, then the code should be corrected. After the code has been verified, the remainder of the parts should be coded. After all parts are coded, the GT system can be used for referencing stored designs and various associated information, like standard process plans. If standard process plans are also stored in the system, the GT code for a new part can be used to find a similar design and, consequently, a similar process plan.
The GT code is made up of a string of digits or letters that identify specific features of a part. The entire string of digits may be related or unrelated. If they are unrelated, that is a polycode, then the meanings of the code are found using a list of features for each digit individually. If they are related, referred to as a monocode, they can be represented with a decision tree. In the decision tree, each digit would represent a branch in the tree. This allows the code to take on a wider variety of meanings. Hybrid codes are also used that are a combination of monocodes and polycodes. One example is the first GT system developed by the Dutch, called MICLASS [Nolan, 1989] which uses a four digit monocode followed by a polycode. An example of a GT code is seen in Figure 1.3 A Group Technology Example for the MICLASS GT Code.
There are some suggested guidelines for selecting the digits in a new GT code,
• they must differentiate products,
• must represent non-trivial features,
• only critical features should be encoded,
• every digit should be significant.
Parts can be encoded using process flow, tool axis, tolerance, function, material, and shape. If a GT code is poorly chosen, there may be problems with too many or too few matches for the new GT codes, or the code might be inflexible to technological change. If the Group Technology code has been well implemented, it is easier to identify standardized routings, estimate work content, assure quality, and maintain the database integrity.
There have been a number of approaches explored for applying GT to process planning. One of the common approaches is to follow the procedure for coding parts in a factory. After the parts are coded, standard part families and companion standard process plans are identified and stored using the GT codes. When a new design is developed a GT code is found for it. The GT code is then used to find the closest part family and, thus, a standard plan. Finally, the standard plan is edited to suit the new design.