Normand Côté
06-20-2008, 05:55 PM
Hi everyone,
We've just finished modeling a subway repair shop and would like to share some of our experience with this model.
The shop contains a dozen lanes and can perform more than 30 different activities on a subway. Some activities can take place only on specific lanes and only during predefined periods every day. We have modelized each activity as a coordinated task sequence because it involves coordinating a subway, or an element of it, a lane and some resource to work on it.
During the development and debugging process, we were most of the time trying to figure out what the subway was doing at the shop. If you look at the taskexecuter's active task sequence you find that your taskexecuter is always TE_ALLOCATED. Because Flexsim can be customized, we make debugging easier by doing the following simple actions:
1- Give a name to each coordinated task sequence. For example :
treenode cts = createcoordinatedtasksequence(subwaydispatcher);
setname(cts,"PeriodicMaintenance");
...
2- Modify the profiletasksequence() command (more exactly the taskdisplay() command) so that when it profiles the sequence, it outputs the rank and the state of a task before its description as in the following picture. Displaying the state of a task is usefull because not all executers have reach the task where the coordinator is blocked at. So you quickly know on which task each executer is working on.
3- We added a new item in the ortho view's popup menu (see the picture) so that when we right-click on a taskexecuter we have access to a command that profiles the taskexecuter's active tasksequence in the output console with a single click. If the taskexecuter is allocated then the command profiles the coordinated task sequence in which the taskexecuter is allocated. This is a handy place to put a command frequently used.
We would also have like to have a set of tasktypes like : TASKTYPE_IF, TASKTYPE_ELSEIF and TASKTYPE_ENDIF to be able to execute a particular block of tasks based on the result of a test (true/false) evaluated during the tasksequence execution as oppose to during the tasksequence creation. Without these functions, you have to break you tasksequence down into multiple sequences every time you need to conditionnally execute some tasks. It makes model development and debugging much longer.
We also came accross a strange behavior of the coordinated task sequence. We found that a taskexecuter, in some circumstances, can start over all its tasks again when it returns from a preemptive tasksequence. This can happen when a taskexecuter has finished all its tasks in a coordinated task sequence but is not yet deallocated when it is preempted for example by a stopobject() command. Sometimes when it resumes from the stop it will redo all the tasks starting from the rank of its allocation task.
When searching for the previous problem we also came accross an undocumented function : insertmultiallocatetask(cts, 2);. This function allows to wait before allocating a number of taskexecuters until they are all available. It is amazing to discover a function that you can use immediatly in your model !
We've just finished modeling a subway repair shop and would like to share some of our experience with this model.
The shop contains a dozen lanes and can perform more than 30 different activities on a subway. Some activities can take place only on specific lanes and only during predefined periods every day. We have modelized each activity as a coordinated task sequence because it involves coordinating a subway, or an element of it, a lane and some resource to work on it.
During the development and debugging process, we were most of the time trying to figure out what the subway was doing at the shop. If you look at the taskexecuter's active task sequence you find that your taskexecuter is always TE_ALLOCATED. Because Flexsim can be customized, we make debugging easier by doing the following simple actions:
1- Give a name to each coordinated task sequence. For example :
treenode cts = createcoordinatedtasksequence(subwaydispatcher);
setname(cts,"PeriodicMaintenance");
...
2- Modify the profiletasksequence() command (more exactly the taskdisplay() command) so that when it profiles the sequence, it outputs the rank and the state of a task before its description as in the following picture. Displaying the state of a task is usefull because not all executers have reach the task where the coordinator is blocked at. So you quickly know on which task each executer is working on.
3- We added a new item in the ortho view's popup menu (see the picture) so that when we right-click on a taskexecuter we have access to a command that profiles the taskexecuter's active tasksequence in the output console with a single click. If the taskexecuter is allocated then the command profiles the coordinated task sequence in which the taskexecuter is allocated. This is a handy place to put a command frequently used.
We would also have like to have a set of tasktypes like : TASKTYPE_IF, TASKTYPE_ELSEIF and TASKTYPE_ENDIF to be able to execute a particular block of tasks based on the result of a test (true/false) evaluated during the tasksequence execution as oppose to during the tasksequence creation. Without these functions, you have to break you tasksequence down into multiple sequences every time you need to conditionnally execute some tasks. It makes model development and debugging much longer.
We also came accross a strange behavior of the coordinated task sequence. We found that a taskexecuter, in some circumstances, can start over all its tasks again when it returns from a preemptive tasksequence. This can happen when a taskexecuter has finished all its tasks in a coordinated task sequence but is not yet deallocated when it is preempted for example by a stopobject() command. Sometimes when it resumes from the stop it will redo all the tasks starting from the rank of its allocation task.
When searching for the previous problem we also came accross an undocumented function : insertmultiallocatetask(cts, 2);. This function allows to wait before allocating a number of taskexecuters until they are all available. It is amazing to discover a function that you can use immediatly in your model !