In the case of the tray carton, each of the four gusset corners can be regarded as a dyad。 If each is thought of as being cut along its diagonal fold, as shown in exaggerated form on the left in Fig。 4, then the resultant face graph is that shown on the right of the figure。 This graph is a now a tree, in fact a spanning tree of the original graph, and its edges represent transforms which involve

Fig。 5。    Constraint resolution for links forming a  dyad。

Fig。 4。    Tray carton with cuts and associated spanning tree of face graph。

rotations about the corresponding edges in the carton net。 The cuts in the dyads represent non-linear equations which need to be solved。

The approach adopted here is to deal with each dyad in terms of a geometric constraint [28–30] requiring its two sides to join。 Use is made of a constraint modelling environment [31,32] in which the geometric entities and the constraints between them are specified via a user interface language。 What is done is to create automatically the command file for the constraint modeller from a description of the net for the carton (and its dyads)。 The command file specifies the constraints which need to be solved to assemble the carton at any stage in its erection。 A simulation can be obtained by specifying a sequence of values for the rotations about the uncut edges。 These can then be stepped through and at each stage the constraints resolved。 The next section looks at the creation of the command file from the carton net。

Finally in this section, a brief overview is given of the constraint modelling approach which is used for the examples in this paper。 A number of approaches to constraint-based design have appeared [33–38] with applications including graphics, conceptual design, and embodiment design。 Various means for resolving constraints have been used including computational reasoning and numerical solution of simultaneous equations。 The constraint modelling en- vironment [31,32] uses optimisation techniques for constraint res- olution。 It has an underlying language in which design parameters are declared。 These can include graphical entities such as points, lines and arcs。

A constraint is specified as an expression involving some of the design parameters。 This is deemed to be true when its value is zero; if it has a non-zero value (as a real number) then this is a measure of its falseness。 For each set of constraints, the user specified which parameters can be changed in order to satisfy those constraints。 The system then treats the sum of the squares of the constraint expressions as a function of the parameters which can be varied and searches for a (local) minimum value using numerical optimi- sation techniques (such as Powell’s direct search method [39])。 If a minimum of zero is found, then it is known that the constraints have been resolved satisfactorily。 A non-zero minimum suggests that the constraints are in conflict and cannot be fully resolved。

The aim is to find a single satisfactory configuration。 This means that the initial values of the variable parameters is important as this is the starting point for the numerical search。 The approach is intended as an aid to the designer in exploring the design space。 In the early stages of the design process, the constraints are evolving as the designer gains understanding of the design task。 Specifying the known constraints to the environment allows their

implications to be assessed so that the constraints can be modified or extended as necessary。

As an example, part (a) of Fig。 5 shows a representation    as

a ‘‘stick model’’ of the four bar mechanism given in Fig。 3。 The lines representing the coupler and driven links are Lcoupler and Ldriven and the constraint to bring their ends together is

rule( Lcoupler:e2 on Ldriven:e2 );