As you'll recall from the chapter about Using 3D Objects, task executers are 3D objects that can move throughout the model and interact with flow items.
They are called task executers because they can be assigned tasks to complete in the simulation model.
Task logic, which is any kind of logic that will involve task executers, can sometimes be one of the most challenging parts of designing logic for a simulation model. Task logic has the potential to be complex because there might be several different logical problems involved in getting a task executer to complete tasks:
Each of these problems has its own system for solving that problem, meaning a set of tools or processes that you could use to solve the problem. Your simulation model might have a very simple answer to one or more of these problems, in which case it will be simple and straightforward to set up the logic. However, most simulation models will likely have a complex answer to one or more of these problems. This topic will discuss each of these different problems in more depth and will explain which tools and processes you could use to solve them.
One of the first problems you need to address when designing task logic is the obvious question of which tasks will need to be worked on by task executers. A task is a single instruction or action that is performed by a task executer. For example, task executers can:
Transportation tasks tend to be the most common tasks. For that reason, the standard logic on 3D objects has some simple and straightforward ways to set up a transportation task. For example, after setting up your port connections, sometimes all you need to do is check the Use Transport button on a fixed resource's Flow tab to set it up. The 3D object will allocate the transportation request using its center port connections and it will include the entire task sequence and information the task executer needs to complete the task.
One thing to keep in mind is that you can also use a process flow to accomplish nearly any task you could have created using standard logic on 3D objects. The main difference is that, when designing a process flow, you need to think a little more deliberately about the logic of which tasks will be assigned to task executers and in what order. For example, the process flow equivalent of a simple transportation task would look similar to the following image:
Some simulation projects that use task executers might need custom tasks. The best tool for building custom tasks is the Process Flow tool. The Process Flow tool has a library of commonly used tasks that you can combine together to create any number of custom task sequences.
One thing to keep in mind about the process flow tool is that usually most tasks can be represented by simple travel, delay, and acquire activities. For example, imagine you wanted to simulate an operator cleaning a machine during a machine changeover. You could possibly simulate this as a series of travels and delays:
The following image shows how this task logic would work during a simulation run:
Using the activities that are available in the Process Flow library, you'll be able to build most of the tasks you are interested in building. The task activities that are available in the Process Flow library cover most of the common tasks that are used in simulation modeling, such as loading, unloading, traveling, and delays. However, there are several more pre-programmed tasks that are available using the Custom Task activity in the library.
If you want to use any of these custom tasks, you should refer to Task Sequences Quick Reference. The Quick Reference can provide you with detailed information about how you should fill in the properties for each custom task type. It also links to more in-depth guides for each task.
When designing task logic, another problem that you also have to solve is which task executer(s) will perform the required tasks. The following are some related questions:
Any kind of simulation model in which there is only one task executer will generally be very easy to set up. You can either create center port connections to a task executer or you can assign the tasks in a process flow to a specific task executer.
Using more than one task executer is not much more difficult if you either connect them to a dispatcher object or put all your task executers in a group that will be linked to a process flow resource.
Any simulation model that uses more than one task executer has the potential to become complex, especially if those task executers are receiving task requests from multiple 3D objects and/or process flows at the same time. If task executers are receiving requests from multiple sources, you'll need to think through whether there will be any potential conflicts between those tasks and how they will get resolved. See How Task Executers Handle Tasks for a more in-depth explanation of why this might potentially cause problems for your simulation model.
Scenarios in which different tasks will take priorities over others also have the potential to become complex. One of the best ways to handle this scenario is to push tasks or task sequences to a list and have task executers pull tasks from the list based on a particular criteria. See Key Concepts About Lists for more information.
Another complicated scenario is when you need more than one task executer to work on a task at the same time, which is typically referred to as a coordinated task. You can create these kinds of tasks in a process flow by having parallel task logic for each task executer that is involved in the coordinated task. Each task executer's track of tasks will need to synchronize with the other task executer's tracks at various points. See Coordinated Tasks for more information.
Item flows and routing issues are related to task logic if task executers are involved in the transportation of items from one fixed resource to another. The important thing to keep in mind is that the logic for item routing is handled through fixed resources---not through any logic on task executers themselves. In other words, the logic that determines how items flow from one object to another is primarily determined by logic on the fixed resource or through process flows that are listening to events on fixed resources.
The simplest kind of item routing is when one fixed resource is passing flow items directly to a fixed resource that is adjacent to it. Port connections can handle this logic very easily. Ports can also handle one-to-many item routing without too many difficulties.
Any many-to-many item routing system is likely to be a little more complex to design. Other examples of complex systems are ones in which there needs to be a special criteria or conditional logic by which an upstream object sends items to different downstream objects.
Depending on your simulation model's needs, FlexSim has many different systems you can use to route items from one fixed resource to another, including lists, conveyors, and process flows. Consider reading the chapter about Connecting 3D Object Flows for more detailed information about how to build item routing logic using these different systems.
If task executers need to transport items or travel across long distances, you might need to create the logic that tells the task executer which path to take in order to get from one point to another.
By default, task executers will travel on the shortest path between two locations, even if there are other objects in that path. The default travel mechanisms might be all your system needs if task executers only need to travel short distances between objects.
If task executers have to travel distances that will not be in a simple straight line, you'll probably want to use one of FlexSim's travel systems to help task executers walk on more accurate paths. The good news is that each of these different travel systems operate on the same basic principles. Once you've learned how to use one of the travel systems, it's not terribly difficult to learn how to use the other systems since many of the same basic principles apply. See Key Concepts About Travel for a deeper explanation of the different advantages and disadvantages of the various travel systems.
FlexSim has three different travel systems. One is the travel network system:
Another is the A* navigation system:
And the last system is for automatic guided vehicle (AGV) networks:
To learn more about tasks, consider completing the following relevant tutorials to get hands-on experience with the concepts discussed in this chapter:
Consider also reading Reference - Task Executer Concepts for a more in-depth explanation about how task executers work.
The rest of this chapter will discuss topics related to tasks in general and specific kinds of task executers.