Connecting two operators to a single processor for repair

Question

question

Swarup Anna asked Jun 18, '16 Swarup Anna commented Jun 23, '16

Connecting two operators to a single processor for repair

We have built a simulation with a source, a queue, a processor, a conveyor and a sink. There are totally two operators in which the first operator fetches the flowitems from the queue and puts it into the processor and at the same time repairs a scheduled breakdown. The task of another operator is to repair an infrequent breakdown. We can’t figure out how to connect these two operators to the same process without colliding them as well to identify if they perform only their respective assigned tasks...Expecting your valuable suggestions.

Software Version:

FlexSim 16.0.1

operator mtbf mttr connections repair

· 1

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Adrian Haws commented · Jun 18, 2016 at 09:32 PM

Would you be able to send a model for us to look at?

2 ·

Answer 1 · 2016-06-21T05:38:42Z

Swarup Anna answered Jun 21, '16 Swarup Anna commented Jun 23, '16

@Adrian Haws, @Sam Stubbs, @jeff.nordgren Thank you for your replies !

We have found a different solution for the problem.

What we did was to go to the "General' tab of the processor in properties and note down the rank of the operators in the 'Central ports' option of the ports section. Then by assigning the particular operator to the downtime by editing the code.

· 5

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Jeff Nordgren commented · Jun 21, 2016 at 07:58 AM

@Swarup Anna

Would you mind sending your model so we (and others) can look at the solution you came up with?

0 ·

Swarup Anna commented · Jun 21, 2016 at 11:54 AM

@jeff.nordgren Sure

samplemodel-autosave.fsm

Here, the mechanic is responsible for repairing the infrequent breakdowns and the operator is responsible for repairing the scheduled breakdowns. Please have a look at the screenshots

0 ·

screenshot-2.png (32.9 KiB)

screenshot-1.png (49.0 KiB)

samplemodel-autosave.fsm (21.8 KiB)

Swarup Anna commented · Jun 21, 2016 at 12:01 PM

Sorry @jeff.nordgren

Please check this model too

samplemodel1.fsm

0 ·

samplemodel1.fsm (22.9 KiB)

Sam Stubbs ♦ Swarup Anna commented · Jun 21, 2016 at 02:39 PM

Thank you for sharing with everyone. Looks great.

0 ·

Swarup Anna Sam Stubbs ♦ commented · Jun 23, 2016 at 07:54 AM

@Sam Stubbs

We know you'd have done the same for us !

Warm Regards,

Steadfast Technology Services Pvt Ltd,

Chennai.

http://www.steadfastglobal.com/

1 ·

Answer 2 · 2016-06-20T21:35:18Z

Jeff Nordgren answered Jun 20, '16

Your problem is not as simple as it first seems. To have a single operator carry the boxes from the queue to the processor and then be the one to handle a normal scheduled down, isn't that easy. This is because if you stop the processor (normal for a breakdown) the operator can not finish putting the flowitem into the processor. Because the operator can not now complete its task, it can not be allocated to the scheduled breakdown task and you get "grid lock".

So this is how I handle that situation in the attached model. In the Down Function of the "normal" MTBFMTTR, I just stop the input of the processor so it can't receive more flowitems. And in the On Break Down option, I set the color of the processor to yellow just so that it is visually clear that this is a "normal" breakdown. And I also set a label called "Down" on the processor to 1 (processor needs to break down). Then in the OnExit trigger of the processor, if the "Down" label is set to 1, I reset the label value, call for the normal repair operator (is now not busy because the processor input port has been closed and there is nothing to transport to the processor), and stop the processor with a status of Scheduled Down.

I modified the On Repair code of the MTBFMTTR so that after it sets the processor back to a green color, it will also free the operator from that repair task.

By doing it this way all of the objects will be set to the proper state that they should be in for any kind of dashboard or report.

Although not terribly difficult, it's not quite as easy as it first may appear.

I didn't cover the repair operator for the infrequent downs. That one is pretty straight forward. If you have any questions, please let me know.

Here is the attached model: operatorsfordowntimes-jn1.fsm

operatorsfordowntimes-jn1.fsm (81.1 KiB)

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Answer 3 · 2016-06-20T15:05:25Z

Sam Stubbs answered Jun 20, '16 Sam Stubbs edited Jun 20, '16

So you can have a processor use multiple operators in the MTBF/MTTR properties. If you open the MTBF/MTTR parameters window (either by double clicking it in the on the tools tab, or clicking Edit in the Processor's properties window in the Breakdowns tab.)

Then under the Down Function dropdown menu, select Stop Object and Call Operators. By default it will call on its center port connection (so you can just have a dispatcher with operators connected to its center port, or if you want to define your own logic here you can do so) And here in this window you can define the number of operators needed to repair the object.

editmtbf.png (12.6 KiB)

breakdownuseoperators.gif (120.6 KiB)

5 |100000

Attachments: Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

question