Bx Examples Repository
Title: The CAD-CAM-CNC Process Chain in the Industry Automation Domain
Version: 0.1
Type: Industrial, Sketch
Overview
In the domain of manufacturing engineering (a sub-domain of industry automation), products to be manufactured are described using multiple models.
This example discusses three of these models as an example of a multx that is typically decomposed in practice into a network of three bx. The consistency of the network is maintained (mostly manually as of today) by following a fixed workflow stating when which model is to be made consistent with which other model(s).
Models
The three involved models are:
- A CAD (Computer Aided Design) model describing the product from a geometric and aesthetic point of view.
- A CAM (Computer Aided Manufacturing) describing the product from an operational point of view, i.e., as a sequence of manufacturing operations that can be executed to produce the model from a starting raw material (e.g., a cube of metal). Each step (operation) in the CAM model states which machine is necessary, and the action to be executed (drilling a hole, clearing away some material, etc.). CAM models can be executed in a simulator to preview the manufacturing process.
- The final model is a CNC (Computerised Numerical Control) model, which is essentially machine code to be executed by a particular family of manufacturing machines. Generating CNC code from a CAM model is not trivial as it requires knowledge about the kinematics of the machines to be able to plot a feasible trajectory. The most common CNC programming language is G-code.
Consistency
The CAM model is consistent with the CAD model if it realises (produces as end result) the geometric shape described by the CAD model.
The consistency relationship between the CAM model and CNC code is more concrete as essentially the same sequence of manufacturing operations must be represented in the code. There are however a series of (technical) challenges:
- The CAM model has comments and other commands (such as PAINT commands) that are only relevant for the CAM simulator. Such information is irrelevant for and is thus not present in the corresponding CNC code.
- CNC code has a different set of (low-level) comments and some details (such as — unbelievably — line numbers) that are also not present in the CAM model.
- CNC code is very flexible in the sense that the configuration details of machines can be repeated in each command, but do not have to be as the old values simply apply if omitted. This means that the same program can be represented in its most compact form, only repeating settings when they change, or in its most verbose form, repeating every setting in every command even if the values do not change.
- The generated CNC code for a CAM model can be non-deterministic. The reason for this is that certain atomic operations in the CAM model (e.g., drilling a countersunk hole) can be decomposed differently but — at least from a CAM point of view — equivalently (e.g., first drill a pilot hole, then countersink, or first countersink then drill the pilot hole). The variants of CNC code can thus be "syntactically" very different but still be consistent with the exact same CAM model.
Consistency Restoration
Given a network consisting of CAD, CAM and CNC models, consistency is restored (or maintained) via a forward engineering process going from CAD to CAM to CNC code.
Changes made to the CAM or CAD models of course have to be allowed, and are handled by pushing them "up" the chain as suggestions for fixes to the higher models. E.g., if the generated CNC is changed (e.g., the position of a machine tip is adjusted to better fit the dimensions of the supplied raw material), then these changes are propagated to the CAM model and are presented as a change request. The manufacturing engineer (in charge of CAM models) then views the change request and decides if, and how to accommodate this change. This might result in a further upwards push to the CAD model. As soon as consistency has been restored on the top-most level, the forward engineering process is triggered and consistency is enforced downwards. This workflow indicates a sort of hierarchy of importance of the three models.
Discussion
This example was investigated as a one-year Software Campus project together with Siemens AG as industrial partner.
It is used as the running example for Anjorin's PhD thesis [1], and in a series of papers [2,3].
References [optional section]
Author(s)
Anthony Anjorin.
Reviewer(s)
Comments
Artefacts [optional section]
A screencast is available demonstrating a prototypical TGG-based CAM/CNC synchronisation tool realised as part of the project.
