Sacha runa yachay 10

The naming of controllers, places and communication between controllers must be consistent in order to be as comprehensible as practicable, because the names will represent ideas in the Petri net graphs and in the occam code.

Naming

The controller names should represent the concurrent controllers identified in step 1 for the purpose of comprehensibility, and are lathe, miller, robot, conveyor, cell and status handler. Place labels or names should be designed to be understandable and meaningful. Instructions to controllers are labelled in the present tense and feedback to the status handler is in the past tense. For example, ‘load lathe’ and ‘lathe loaded’ in the lathe controller of Figure 6-2, where the instruction arrives from the cell controller and is passed to the level 1 controller, and when the operation is complete, then the feedback is received from the level 1 controller and sent to the status handler.

In the controller Petri net graphs, the Petri net structure and the Petri net place names are synergistic. For example, the lathe statuses of Figure 6-8 shows that when the lathe is loaded, then the lathe is no longer idle and it becomes not started. In isolation, not started could mean that the lathe could not be started that morning. However, within the Petri net graph it is obvious that not started is a state between being loaded and being started, so means that the part is ready to be machined and the lathe is waiting for the

instruction to begin machining.

The synergy can breakdown where there is insufficient information in the structure and the place names. This happens when the structure is complicated or a place represents a difficult or unexpected idea. In these circumstances, the Petri net graphs are accompanied by pseudo-code and place name descriptions. Referencing

taken follows output-work-backwards described above. In this way, a history of development can be kept to help in error checking and in future maintenance, because places can be numbered in the order they are drawn.

It is possible to provide every place with a unique number. However, it has proved simpler to start referencing from 1 for each controller or module within a controller, and make reference to a place as if addressing a house, e.g. place 1 ‘load lathe’ in lathe conditions of the cell controller. This is a more modular way, which enables easier modification. A very large system might require numbering of controllers in the same way as numbering places.

Where places appear more than once, i.e. replicated, then they must be cross-referenced. Places can be replicated within a module of a controller or between two or more modules of a controller. For example, during the development of lathe conditions in the cell controller, Figure 5-7 shows places 7 and 14

‘lathe work handling idle’ are mutually cross referenced, and this is indicated by ‘>‘. In further

development of the cell controller, Figure 5-8 shows in the lathe conditions appears renumbered as place 7 and is cross referenced with place 3 in index conditions. The referencing is denoted by ‘IW’, and correspondingly place 3 in index conditions is cross referenced ‘L’ for lathe conditions.

Petri net place reference codes appear with entry and exit places as source and destination codes, and with local Petri net places as place replication cross references. Entry and exit places are manifest as occam channels, and are not replicated. Local Petri net places become occam variables, but, unlike local places, variables are not replicated for comprehensibility.

Naming and Referencing

Communication between controllers is referenced and not joined by arcs, in order to reduce clutter. This communication is implemented as channels in step 4. Exit and entry places are given destination and source codes respectively. The codes are abbreviations for the controllers with which communication is intended, e.g. ‘LC’ is the alias of lathe controller. A combination of the codes is used in naming channels, see section 5.9.1, and is done for readability and to help in consistency checking.

Places can be drawn with different radii to accommodate voluminous place names, but place names should be abbreviations of understood ideas. It is preferable for the user to comprehend the idea, by learning the meaning of the accompanying description, rather than to read a Petri net graph with lengthy places names. Petri net place name descriptions supplement the names where there is doubt that the place is a sufficient or obvious representation. For example, in the pallet at lathe statuses of Figure 6-8, it is obvious when a full pallet arrives at the lathe and the lathe is loaded with a component, then the full pallet becomes empty. Unexpectedly however, as the pallet becomes empty, it also becomes lathe associated, and ceases to be not lathe associated. Here the respective accompanying descriptions would be ‘the part leaves the pallet but only that part will return to that pallet due to the association between the pallet and the lathe’ and ‘complement to lathe associated’. Users are informed that there is an accompanying description by a ‘+d’ in the place (not done).

LATHE CONTROLLER

LATHE CONTROLLER

LATHE CONTROLLER

The next sections pay particular attention to the decisions made for the different controllers. According to the output-work-backward strategy, the first to be considered are the workstation controllers, then the cell controller, then status handler, and the cycle completes with the workstation controllers again.