ATTENTION

This FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices.


flexsim.com

Go Back   FlexSim Community Forum > FlexSim Software > Tips and Tricks
Downloads

Tips and Tricks Share helpful modeling ideas

  #1  
Old 06-19-2008
Brandon Peterson's Avatar
Brandon Peterson Brandon Peterson is offline
The Flexsim Consultant
 
Join Date: Jul 2007
Location: Salt Lake City, Utah
Posts: 382
Downloads: 29
Uploads: 6
Thanks: 192
Thanked 516 Times in 235 Posts
Rep Power: 490
Brandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant future
Default 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
Attached Files
File Type: zip XT Call two operators with no waiting V02.zip (81.6 KB, 396 views)
__________________
thats not normal.

Last edited by Brandon Peterson; 10-15-2008 at 01:13 PM.
The Following 6 Users Say Thank You to Brandon Peterson For This Useful Post:
Scott Mackay (10-07-2009)
  #2  
Old 09-23-2008
Goksin Yilmaz's Avatar
Goksin Yilmaz Goksin Yilmaz is offline
Flexsim User
 
Join Date: Aug 2007
Location: ON, Canada
Posts: 21
Downloads: 11
Uploads: 0
Thanks: 23
Thanked 13 Times in 6 Posts
Rep Power: 213
Goksin Yilmaz is a jewel in the roughGoksin Yilmaz is a jewel in the roughGoksin Yilmaz is a jewel in the rough
Default Call multiple operators for a task but wait until all are available

Thanks a lot for this post.

My team frequently encounters the following scenario in model building:
Quote:
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
  #3  
Old 09-24-2008
Nico Zahn's Avatar
Nico Zahn Nico Zahn is offline
Flexsim User
 
Join Date: Sep 2007
Location: Bingen am Rhein, Germany
Posts: 179
Downloads: 19
Uploads: 4
Thanks: 66
Thanked 60 Times in 32 Posts
Rep Power: 201
Nico Zahn has a spectacular aura aboutNico Zahn has a spectacular aura about
Default Resource handling

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.
Attached Files
File Type: zip Custom_Dispatcher_4_32.zip (96.3 KB, 318 views)
__________________
kind regards Nico.
The Following 2 Users Say Thank You to Nico Zahn For This Useful Post:
Scott Mackay (10-07-2009)
  #4  
Old 09-25-2008
AlanZhang's Avatar
AlanZhang AlanZhang is offline
Flexsim Super Moderator
 
Join Date: Aug 2007
Location: CA
Posts: 289
Downloads: 64
Uploads: 0
Thanks: 88
Thanked 91 Times in 47 Posts
Rep Power: 225
AlanZhang is a jewel in the roughAlanZhang is a jewel in the roughAlanZhang is a jewel in the rough
Default

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?
__________________
Best,
Alan
  #5  
Old 09-25-2008
Brandon Peterson's Avatar
Brandon Peterson Brandon Peterson is offline
The Flexsim Consultant
 
Join Date: Jul 2007
Location: Salt Lake City, Utah
Posts: 382
Downloads: 29
Uploads: 6
Thanks: 192
Thanked 516 Times in 235 Posts
Rep Power: 490
Brandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant future
Default

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
__________________
thats not normal.
The Following User Says Thank You to Brandon Peterson For This Useful Post:
Scott Mackay (10-07-2009)
  #6  
Old 10-15-2008
Henry Bell Henry Bell is offline
Flexsim User
 
Join Date: Oct 2008
Posts: 2
Downloads: 0
Uploads: 0
Thanks: 3
Thanked 13 Times in 2 Posts
Rep Power: 0
Henry Bell is on a distinguished road
Wink Great Posting but some Questions

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
Attached Thumbnails
Click image for larger version
Name:	ImageScrn.jpg
Views:	282
Size:	20.1 KB
ID:	468  
The Following User Says Thank You to Henry Bell For This Useful Post:
Brandon Peterson (10-15-2008)
  #7  
Old 10-15-2008
Brandon Peterson's Avatar
Brandon Peterson Brandon Peterson is offline
The Flexsim Consultant
 
Join Date: Jul 2007
Location: Salt Lake City, Utah
Posts: 382
Downloads: 29
Uploads: 6
Thanks: 192
Thanked 516 Times in 235 Posts
Rep Power: 490
Brandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant futureBrandon Peterson has a brilliant future
Default

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
Attached Files
File Type: zip XT Call two operators with no waiting V02.zip (81.6 KB, 317 views)
__________________
thats not normal.
The Following 2 Users Say Thank You to Brandon Peterson For This Useful Post:
Scott Mackay (10-07-2009)


Thread Thread Starter Forum Replies Last Post
How to model operators' efficiency? Liu Bin Q&A 4 05-21-2008 07:56 AM
Operators moving backwards Nico Zahn Tips and Tricks 0 05-19-2008 04:51 AM
Setting the number of operators Sung Kim Q&A 4 02-05-2008 12:31 PM
Repair Operator David Chan Q&A 1 01-22-2008 11:37 PM
Operators on Multiple Networks Nico Zahn Q&A 0 10-10-2007 03:02 AM


All times are GMT -6.
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Copyright 1993-2018 FlexSim Software Products, Inc.