The multiprocessor is used to simulate the processing of flowitems in sequentially ordered operations. The user defines a set of processes for each multiprocessor object. Each flowitem that enters will go through each process in sequence. multiprocessors may call for operators during their process steps.
Details
The multiprocessor is a sub-class of the FixedResource. It receives one flowitem, puts the flowitem through its sequence of processes, then releases the flowitem. Once the flowitem has exited the multiprocessor, it receives another flowitem and goes through the processes again. Only one flowitem will ever be in the multiprocessor at one time.
For each process that you define, you can specify a name for the process, a process time, a number of operators to use for that process, priority and preempting values for the tasks sent to the operators, and the operator or dispatcher to send operator tasks to. At the beginning of each process, the multiprocessor calls the process time field, sets its state to the name of the process, and calls operators if the number of operators value is greater than 0. When the process is finished, the multiprocessor releases all operators called for that process, and calls the process finish trigger. It also passes the process number into the process finish trigger as parval(2).
Context
You would use the multiprocessor if you have one station that involves several operations with separate process times and/or different resources. You can also use the multiprocessor as a shared station for different types of operations. For example, itemtype 1 needs to go through operations A, B, C, and D, and itemtype 2 needs operations E, F, G, and H, but both itemtypes must share one station for their processes. Give the multiprocessor 8 processes: A - H, and for itemtype 1 have processes E - H have 0 process time, and for itemtype 2 have processes A - D have 0 process time.
Note that the multiprocessor does not accommodate piping of processes. Piping happens if, once a flowitem gets finished with process 1 and moves to process 2, another flowitem can take up process 1. Thus several flowitems can be "flowing down the pipe" at any given time. If you would like to simulate this, use several Processor objects connected in sequence.
States
Idle - There are no flowitems being processed
User-defined states - These are states defined by the user, one for each process.
Blocked - The multiprocessor has finished all processes for a flowitem, released it, but there is no downstream object ready to receive it.
Waiting for Operator - The multiprocessor is waiting for operator(s) to arrive in order to start a process.
Waiting for Transport - The multiprocessor has finished all processes for a flowitem, released it, and there is a downstream object ready to receive it, but the flowitem has not been picked up by a TaskExecuter yet.
Properties pages
multiprocessor
Flow
Triggers
Labels
General
