Call Two operators for Repair but wait until both are available

All,

Attached is a model that demonstrates how to call two operators for a repair process wthout having one operator wait for another operator to finish a task before getting to the repair task.

The model is set up with three sets of processors: A, B, and C. The A and C processors both breakdown with the Single Operator MTBFMTTR and use normal functionality. The B processors breakdown with the Multi Operator MTBFMTTR. This breakdown needs to have an A and a C operator to do the repair but we don't want either of the operators to travel to the processor to do the repair before the other operator is ready.

To do this I modified the MTBFMTTR Down Function to send a message to the processor to check and see if an operator of each type is available before creating the coordinated task sequence that would have been made with the default code. If one of the operators is unavailable then the code creates a task to have that set of operators send a message back to the processor when they are finished with their current tasks. The processor then redoes the check to see if both operator types have a free operator. If not it repeats the process and if so then it creates the coordinated task sequence to complete the break down.

All of the code that makes this model happen is located on the Down Function trigger of the Mili Operator MTBFMTTR and on the On Message triggers of th B processors. All of the code is commented line by line to make it easier for everyone to understand what is being done.

Anthony mentioned to me that in C++ there is a command for coordinated task sequences that will not allocate a group of TEs until all of them are available. However, that is not a possibility in Flexscript so I was able to accomplish the same thing this way.

Please let me know if you have any questions or comments,
Brandon

Thanks a lot for this post.

My team frequently encounters the following scenario in model building:

coordinated task sequences will (or SHOULD) NOT be allocated to a group of TEs until all of them are available.

This is not only for maintenance and repair tasks, but also for material handling, execution of long tasks requiring two or more operators etc.

Although Brandon's solution is quite elegant, obviously it is not straightforward to implement in a large-scale model.

If there is already "a command in C++" to do this, I believe this command should be added into the next version as Flexscript.

Brandon: Can you please create a poll for this to get the feedback from the user community.

Thanks again and best regards, GY

Hi Goksin,
I think the best way to handle a lot of resources wich interact with each other and need certain other resources to fullfill a task is to handle them manually. In the attached modell the Ops are seized in a list. If the task (or tasksequence) is finished the Op is set free again. Before the task is dispatched the code on the dispatcher checks if the necessary resources are available. Only when the resources are available the task is taken from the global table 'tasks' and given to a free OP. In this way you can seize an OP over more than one tasksequence, e.g. if there are stopppoints because the OP first neeed cart A and then cart B, but cart B might be used by another OP when it is required by the OP.
It would be nice to have more control over (a table in the dispatcher with all OPs, their states, objects and stations involved, or so would be nice) the strategie of taskallocation in the Flexsim dispatcher.

Brandon,

Thanks for this useful post. I have some simple questions. In the Down function of MTBF/MTTR, what is the parameter membercoupling? I cannot find its meaning in the help documentation. Also, in the On Message triggers of the B processors, you send a message back to MTBF/MTTR object with msgparam(3) as MTBF_MTTR_FINISH_DOWN_TIME_NO_RESUME. Is this a standard way to have MTBF/MTTR object not resume the down object? Can I find any more information about this in the Flexsim documentation?

Alan,

membercoupling is a treenode defined at the top of the Down Function and is set equal to parnode(4). From what I can tell it is a pointer to the node that contains a coupling to the down object. That node is located in the members node inside of the variables node of the MTBFMTTR.

Yes, although it is not the 3rd message parameter, the first two parameters in the inserttask after TASKTYPE_SENDMESSAGE are the to ad from objects. Having the first message parameter set to MTBF_MTTR_FINISH_DOWN_TIME_NO_RESUME is the standard way that the MTBFMTTR object resumes a downed object. The message is sent to the MTBFMTTR from the membercoupling node talked about above. You can check this by looking at the code behind the default "Execute stopobject() and call oprators" pick list options.

Brandon

Brandon,

Great posting but as I ran the model I observed some interesting behavior (see attached). In many cases it seemed that during down times rather than 2 operators being in an operation four operators were pulled into a single station.

Being new to Flexsim I am uncertain as to how the dispatcher selects the operator to assign to a processor beyond by first available, in your example. In cases where multiple operators are available I was wondering if there is a secondary criteria such as proximity or resource with lowest utilization. I could foresee a situation where 2 operators lower in the model tree could be assigned to a repair, then shortly thereafter 2 different operators could be assigned to a different repair to the machine, when in fact the first 2 operators are still physically at the processor.

A further observation. If you run the model for a significant period of time the model bogs down to the point where only one station of the B Processors remains operational. My assessment of the cause is that the regular Operator is not freed to move to a different idle station during repairs. Any suggestions on how that might be accomplished?

Thanks,

Henry Bell

Henry,

If you want to change the dispatching criteria then you would want to do that in the dispatchers at the bottom of the view. There you can tell them to dispatch to the closest available operator.

There was a problem with the model that was causing some wierd behaviour. The problem was that in the "Down Function" of the Multi Operator MTBF/MTTR I was returning a 0 instead of a 1. Returning a 1 informs the MTBF/MTTR that you are dispatching operators and will send a message to the MTBF/MTTR when the breakdown has finished. Because I had returned a 0 instead of 1 the MTBF/MTTR was creating two 2nd breakdowns instead of 1. This happend because it created one when I returned 0 and then created another when I sent the message from the operator. This was a compounding problem so there were four 3rd breakdowns, 6 4th breakdowns, and so on.

I have updated the original download in the first post and have also included the updated model here.

Thanks,
Brandon