TaskExecuter is the top level class for several objects in the library. Operators, Transporters, ASRSvehicles, Cranes and other mobile resources inherit from the TaskExecuter class. All of these objects can travel, load flowitems, unload flowitems, act as shared resources for processing stations, and perform many other simulation tasks.
To learn more on how to begin using TaskExecuters, refer to Lesson 2 of the Tutorials.
Details
TaskExecuters and their sub-classes are able to execute task sequences, perform collision detection, and execute offset travel.
The TaskExecuter is also a sub-class of the Dispatcher class, and thus a TaskExecuter can actually act as a team leader that dispatches task sequences to other team members. Its handling and dispatching logic have subtle differences from the Dispatcher, however. When the TaskExecuter receives a task sequence, it first checks to see if it already has an active task sequence. If there is no active task sequence, or if the newly received task sequence is preempting and has a priority greater than the currently active task sequence, then it will start executing the new task sequence, preempting the active one if needed. Otherwise it will go through the normal Dispatcher logic. If the task sequence is not passed on immediately, then it will queue up in the TaskExecuter's task sequence queue, and if the task sequence is still in the queue when the TaskExecuter finishes its active task sequence, the TaskExecuter will then execute the task sequence.
User-Defined Properties
All TaskExecuters have the following fields that can be defined by the modeler.
Capacity: This parameter defines a value for the maximum content of the object. In default operation, the object will never load more flowitems than this value specifies.
Note for advanced users on the capacity value: this value can be deceiving if you create your own task sequences. Since the TaskExecuter's first and most important responsibility is to execute task sequences, if you give the object a task sequence to load more flow items than its maximum content, then it will load the flowitems anyway. The only real instance in which the maximum content value is used is for the TASKTYPE_BREAK task. If the TaskExecuter comes to a break task, and it has reached its maximum content, then it will not perform the break, and will continue on its current task sequence instead of breaking to another task sequence. This works in the default case when task sequences are created automatically because each task sequence is responsible for the loading of just one flowitem.
Maximum Speed, Acceleration, Deceleration: These define the TaskExecuter's maximum speed, acceleration, and deceleration. Maximum speed is defined in units of length per unit of time, while acceleration and deceleration are defined in units of length per squared unit of time. If you are defining your model in meters and seconds, for example, the speed value is in m/s, etc. These values are used in defining the object's peak speed and change in speed while executing the task types such as TASKTYPE_TRAVEL, TASKTYPE_TRAVELTOLOC, etc.
Travel Offsets for load/unload tasks: This value determines whether the TaskExecuter should execute offset travel to the load/unload location when it loads or unloads a flowitem. For example, if this is not checked, and the TaskExecuter is traveling on a network, then it will only travel to the network node that is at the load/unload station. It will remain on that node while doing the load.
Rotate while traveling: Here you can specify if you want the object to rotate in the direction that it is traveling. This will have no effect on model output. It is only for visual purposes.
Load Time: This field is executed at the beginning of each load task. Its return value is the delay time that the TaskExecuter will wait before loading the flowitem and moving on to the next task. Note that if the TaskExecuter is configured to travel offsets for load/unload tasks, then it will first travel the correct offset, and then start the load time. Thus the load time is added onto the end of the offset travel time; it is not part of the offset travel time.
Unload Time: This field is executed at the beginning of each unload task. Its return value is the delay time that the TaskExecuter will wait before unloading the flowitem and moving on to the next task. Note that if the TaskExecuter is configured to travel offsets for load/unload tasks, then it will first travel the correct offset, and then start the load time. Thus the load time is added onto the end of the offset travel time; it is not part of the offset travel time.
Break to Requirement: This field is executed when the TaskExecuter comes to a break task or callsubtasks task. The return value is a reference to a task sequence. The logic within this field should search the TaskExecuter's task sequence queue, and find a task sequence that is appropriate to break to.
Offset Travel
Offset travel is a mechanism by which different types of objects can travel differently, yet use the same interface for traveling. For example, an object wants to place an item into a given bay and level of a Rack. The way in which the object travels to the correct location to drop off the item depends on the type of object it is. An operator walks to the bay's location and places the item in the level. A Transporter travels to the bay, but must also lift its fork to the proper height of the level. It can travel in both the x and y direction, but only its fork can travel in the z direction. An ASRSvehicle will only travel along its own x axis, lifting its platform to the height of the level, and then pulling the item from the Rack. Hence, each object implements its travel differently, but the interface is the same: travel to the right spot to place the item in the Rack. Offset travel is essentially the only thing that distinguishes each sub-class of the TaskExecuter. For information on how each sub-class implements offset travel, refer to the "Details" section of an object's help page. Offset travel is used in load and unload tasks, in traveltoloc and travelrelative tasks, and in pickoffset and placeoffset tasks.
The offset travel interface is very simple. Every type of offset request translates into an x,y, and z offset distance, and sometimes a reference to a flow item. For example, if an object is given a traveltoloc task for the location (5,0,0), and its current location is (4,0,0), then it automatically translates that task into an offset request for (1,0,0), meaning it needs to travel one unit in the x direction. A travelrelative task translates directly. For example, a travelrelative task for (5,0,0) tells the object to travel 5 units in the x direction. Load and unload tasks also use offset travel if the "Travel Offsets for Load/Unload Tasks" checkbox is checked. When an object needs to load a flowitem from a station, it queries the station for the location of the item. Also, when it needs to unload an item, it queries the station for the location to unload the item. The station returns an offset x/y/z distance, and the TaskExecuter uses this distance to travel its offset. Also, for a load and unload task, the TaskExecuter has a reference to the item in its offset request. This may or may not affect the way the object travels, depending on the type of object. For example, the Transporter's offset travel mechanism is implemented so that if there is an item, or in other words, if the Transporter is loading or unloading an item, the Transporter will lift its fork in the z direction. If there is no item, or in other words, if the Transporter is doing a traveltoloc or travelrelative task, then it will actually travel in the z direction, instead of lifting its fork.
Offset values should be calculated relative to the x/y center of the object, and the z base of the object. For example, a robot is positioned at location (0,0,0). It has a size of (2,2,1). From this the x/y center and z base can be calculated as the location (1,-1,0) (Note: y size extends along the negative y-axis). All offset calculations should be made from this (1,-1,0) location. While giving the robot a traveltoloc task will automatically make this calculation for you, sometimes it is necessary to calculate this location manually and use a travelrelative task. If the robot is given a travelrelative task of (1,0,0), this means that the correct position to travel to is one unit to the right of the robot's x/y center and z base. This translates to the location (2,-1,0). Note that this does not mean that the robot will travel such that its own location is (2,-1,0). Neither will it travel such that its x/y center and z base are at that location. Because it is a robot, it will rotate and extend its arm so that the end of the arm is at the location (2,-1,0). Its actual location will not change at all. Thus the calculation from the object's x/y center and z base allows you to specify a desired destination location which is the same for all objects, but which allows each type of object to handle that destination location differently.
Collision Detection
The TaskExecuter and its sub-classes have the capability of detecting collisions with other objects. Collision detection is performed by adding collision members to a TaskExecuter, then adding collision spheres to it and its collision members, then executing logic when one of the spheres of the TaskExecuter collides with one of the spheres of one of its collision members. Each collision sphere you specify has a location in the TaskExecuter's frame of reference, and a radius. The TaskExecuter repetitively checks for collisions at time intervals that you specify. At each collision check, the TaskExecuter checks for collisions on all of its collision spheres with all of the collision spheres of all of its collision members. If a collision is found, then the TaskExecuter fires its collision trigger. It does not fire the collision trigger of the object with whom it is colliding. The other object's collision trigger will fire if and when it does its own collision checks. Note that the collision trigger fires for a specific sphere-to-sphere collision. This means that within one collision check the collision trigger can fire several times, once for each sphere-to-sphere collision encountered in the check.
Be aware that you can very easily cause your model execution speed to decrease significantly if you are not careful with collision detection. For example, if a TaskExecuter has 5 collision spheres and 5 collision members, and each of its collision members has 5 collision spheres, then each collision check will need to check for 125 sphere-to-sphere collisions. If all 6 TaskExecuters are checking for collisions, then 750 sphere-to-sphere checks are being made at each collision check interval of the model. This can slow the model down considerably, especially if your collision interval is very small.
You can turn collision detection on and off for a given TaskExecuter by using the setcollisioncheck() command. See the command summary for more information on this command.
States
The TaskExecuter's states are purely dependent on the types of tasks that the TaskExecuter performs. Many tasks are associated with a hard-coded state, but with some tasks the modeler can specify an explicit state for the TaskExecuter to be in when executing that task. Here are some of the states that you will see often with a TaskExecuter. For more information on tasks and task sequences, refer to Task Sequences.
Travel Empty: The object is traveling to a destination object and doesn't contain any flowitems. This state is exclusively associated with the TASKTYPE_TRAVEL task.
Travel Loaded: The object is traveling to a destination object and has load one or more flowitems. This state is exclusively associated with the TASKTYPE_TRAVEL task.
Offset Travel Empty: The object is performing offset travel and doesn't contain any flowitems.
Offset Travel Loaded: The object is performing offset travel and has loaded one or more flowitems.
Loading: The object is loading a flowitem. This state corresponds to the TASKTYPE_LOAD task, and applies only to the time when the object has finished its offset travel and is waiting its modeler-defined load time before loading the item.
Unloading: The object is unloading a flowitem. This state corresponds to the TASKTYPE_UNLOAD task, and applies only to the time when the object has finished its offset travel and is waiting its modeler-defined unload time before unloading the item.
Utilize: The object is being utilized at a station. This state is usually used for an operator, when the operator has arrived at the station and is being utilized for a process, setup, or repair time. The utilize state is usually associated with a TASKTYPE_UTILIZE task, but that task can also specify a different state. Also, other task types, like TASKTYPE_DELAY, can use the utilize state.
Blocked: The object is currently traveling, but is blocked on the network.
