In my attached model.
My machine's will breakdown according to a distribution and call an operator to fix it.
My other machines will need to keep running and therefore will preempt the operator to do hourly adjustments after Blue operator inspects the batched parts.
However i think am noticing that my brokendown machine keeps fixing itself even though the operator is away. is there anyway to pause the breakdown fix and call to operator back to continue to fix it.
There exists a special interlocked method of several tasks which does what you want in classic 3D logic by default created tasksequences. If an operator leaves a machine during repairs, then the operator tasksequence must ensure that the processor is stopped again. And if he returns, the stop must be canceled again.
Is this a custom logic that needs to be added to the MTTF function?
Hi @Emmanuel D,
Is this the behavior you're hoping for? I apologize it's rather sloppy, but if you watch the model around time 3900, the machine goes down and then the Decide Activity in the PF checks to see if the machine is stopped using a label on the processor. If it is stopped, the token must wait for the machine to resume before creating a new task sequence for the operator. You could possibly implement some type of similar logic for your needs.
@tanner.p I like the idea of using a label to hold off on creating a new task sequence. However, this isn't the behavior i a looking for. I would like to preeempt operator1 to go do more important tasks but come back to fix the machine when he is free. (Unfortunately in the above project all that is happening is that the more important task sequence is being delayed which is not what i Want). in this case it is mroe important to keep production flowing rather than focusing on fixing a broken down machine.
I am looking to save the progress the operator made on fixing for eg. "B4" when he is preempted away and to return to that saved progress when he is free.
Any ideas?
Thank you for the clarification. I don't know of a way to do this using the standard MTBF-MTTR functions. Perhaps @Jörg Vogel could provide more insight based on his previous comment. The problem is that when the object goes down, the downtime is calculated and FlexSim already knows when the object is going to go back up, so you can't really change that value dynamically as the operator is pulled away. At least not very easily. Here's a screenshot of the code that is fired when the object goes down to give you a sense of what's going on in the background. Maybe this can help us identify possibilities for a solution.
The only other alternative I can think of would be to use Process Flow for the MTBF-MTTR functionality. This way, if the operator gets called away for whatever reason, the Process Flow token can be stopped or diverted until the operator returns. You can have an Inter-Arrival Source generate the randomized breakdowns and then the Delay Activity can generate the randomized down times. Just an idea.
The default MTTR MTTR call for operators is just a simple delay task for repairs. If you call operators for setup or processing the mechanism is different. The processors goes down, waits for an operator, on arrival of an operator a stoprequestfinish task lets start the setup. The operator will be freed after setup had elapsed. An setting up operator can be preempted to another tasksequence. Then the processor is stopped again. The setup tasksequence is transferred to the tasksequence queue. This tasksequence has got a milestone task. This milestone task is responsible for repeating some tasks again after an preempting event had occurred.
If you want to get a similar behavior for MTBF MTTR tasksequences you must implement the mechanism for setup or processing on these types tasksequences, too. You need additionally a timer in the processor, that starts when the operator arrives once. You can use a send delayed message task for that. The delay is the time for repair. Unfortunately of the milestone task the send delayed message task might be repeated several times. The free operator command is allowed to be executed only for the first receiving message. Later receiving messages initiated by repeated milestone task must be ignored. Because of this condition each send delayed message task is identified by a unique id, which you check in the OnMessage trigger. The first received message frees the operator. This all works, because a stopped object suspends delayed events until the object resumes.
12 People are following this question.
© 1993- FlexSim Software Products, Inc. All Rights Reserved.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
