Encuesta y análisis conjunto en mercado chileno

If all previous steps were successful, the command list can be executed to gradually transform the fixture configuration. This is done in two phases, as shown in Figure 5-23. These phases can be indicated by the fixture coordinator by the setting of state variables which the command objects can access. The first phase is carried out before the workpiece is placed in the fixture. All modules are repositioned on the transport components and the

roles of all modules are changed to their target specification. Additionally, the tip positions of all modules acting as locators are adjusted. However, the commands to adjust the tip position of modules acting as clamps are not executed in this phase. Consequently, these modules remain retracted in this phase. After the workpiece is placed in the fixture, the second phase commences which adjusts the tip positions of the clamping modules.

Workpiece placed?

For all commands cmd := next

command

Execute command

For all commands cmd := next command Execute command Yes No Phase I Phase II ChangeTipPositionCmds attached to

modules acting as Clamps remain idle

ChangeTipPositionCmds attached to

modules acting as Clamps are executed Figure 5-23: The Two Phases of the Command Execution Sequence

As can be seen in the flow chart, the command execution sequences in both phases look similar. This is because each subclass of ReconfigurationCommand can implement the execute()-method differently. The class ChangeRoleCmd updates the required role in the internal data model of the fixture coordinator by setting the attribute currentRole in the class ProvidesRole. In case, the module can act as a clamp or a locator, the sense force capabilities are activated adequately. For example, if the module acts a clamp in the next configuration, the capability class SenseClampingForce is activated and the capability SenseReactionForce is deactivated. This way it is avoided that conflicting force sensor information is received during the clamping procedure. The class ChangeTipPositionCmd implements the execute()-method such, that it returns immediately without doing anything during the first phase of the reconfiguration process. In the second phase however, the command object publishes the module identifier and the desired value for the tip position, using the communication infrastructure. These target values are received by the software of the concerned fixture module which subsequently performs the required movement and publishes the current tip position into a separate data topic. As a consequence the fixture coordinator is informed about the progress of the movement and updates its internal data model accordingly. The command object waits until either the target position has been reached or a deadline has elapsed in order to prevent the command from waiting eternally.

The execute()-method of the ChangeBodyPositionCmd class works according to the same principle. The target values are published and it waits until the desired values have been retrieved by the fixture coordinator and updated in its internal data model. The details for the communication infrastructure and the individual data topics are described in chapter 6.

The main advantage of the followed object-oriented design pattern and the delegation principle is that the software framework becomes independent from a particular fixture setup. This is because the command objects do not contain any implementation code to reconfigure a particular fixture module. Instead, each command publishes the desired values for its module, thereby delegating the responsibility for the execution to the fixture modules or other stakeholders which have been registered as subscribers. As a result, the fixture coordinator is unaware of the components responsible to carry out the actions of the command. For example, when a ChangeBodyPositionCmd command is executed, it triggers its associated fixture module object to publish the desired body position and orientation, thereby delegating the task to the equipment responsible for moving this fixture module. However, for the fixture coordinator it is irrelevant which component has subscribed to this information. In the experimental test bed, presented in chapter 7, the software programs controlling the movement of the rail carriers are the subscribers for this information. In other scenarios, the subscriber might be a robot, picking up each fixture module from its current position and placing it at the target position. Furthermore, due to the common interface of the command objects, the complexity of the entire reconfiguration process is reduced to simple calls of a variable number of execute()-methods. These methods are invoked by the fixture coordinator without knowing any implementation details or even the type of a particular command. As a result, the reconfiguration process becomes independent from these aspects. This allows programmers to introduce new command classes in the future or to change the implementation code of existing commands without affecting the overall logic. Additionally, the same algorithm works for simple and complex reconfiguration tasks in the same way as this is reflected only by the number of command objects in the list.

5.4.

Chapter Summary

A new decision-making methodology for fixture reconfiguration has been described which consists of two parts, namely the capability recognition method and the setup adaptation method. The first part describes how the elements of the object-oriented data model are instantiated by both, the fixture module software and the fixture coordinator, in order to reflect the capabilities of the current fixture setup. As a consequence, the software framework is rendered applicable to a large variety of different fixturing systems. The second part defines the steps to reconfigure an existing fixture layout for the next workpiece. The core idea is based on matching the fixture module objects with the contact point objects from the fixture design. This assignment makes it possible to delegate the generation of the reconfiguration sequence to each individual fixture module.

The methodology is a significant improvement over existing approaches because it addresses the adaptation of the fixturing software during the reconfiguration procedure. Unlike existing concepts which appear to be limited to a specific fixture layout, the presented methodology is applicable for a range of different systems. This is achieved through the dynamic generation of the object model elements in order to reflect the capabilities of a given system. In addition, the concept allows for the combination of capabilities when fixture modules are added and uses software delegation to fulfil requests during the operation of the fixture. Moreover, the methodology has contributed to the field of object-oriented design patterns by applying the Command pattern to a new area, namely the fixture reconfiguration problem.