Checking For Clashes

Principles

Having set up the obstruction list and defined any non-default clash specifications (touch and clearance settings, restricted region of interest, Branch BCHECK option), the user can now tell Model which design items required to check (the check list).

The clash-checking process is carried out in two stages, as illustrated in the following Figure:

Diagnosis of potential/real clashes

• In Stage 1, the obstruction limit boxes that enclose the individual design elements (as represented in the spatial map) are checked for overlapping. If no overlap occurs between the obstruction limit boxes of two elements, then no clash can exist. If, however, the boxes do overlap, then a potential clash exists and the second stage of checking is carried out.

• In Stage 2, the detailed geometry of the elements within overlapping obstruction limit boxes (as represented in the Geometric Modelling Library) is checked to see if any of the constituent primitives overlap. If they do, then an appropriate clash is reported.

To confirm the absence of clashes in a proven design, or to run a superficial check on a new design, carry out just the first stage of the checking process, known as a box check. Note, however, that if you run only a box check on an unproven design, you are likely to generate a report containing many spurious clashes resulting from situations such as the one illustrated in the Diagnosis of potential/real clashes image. The extra time taken to analyze the output report can outweigh the time saved by running the simplified checking procedure, so use this option with care.