question

Swarup Anna avatar image
1 Like"
Swarup Anna asked Swarup Anna commented

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.

FlexSim 16.0.1
operatormtbf mttrconnectionsrepair
· 1
5 |100000

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

Adrian Haws avatar image Adrian Haws commented ·

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

2 Likes 2 ·
Swarup Anna avatar image
1 Like"
Swarup Anna answered Swarup Anna commented

@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

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

Jeff Nordgren avatar image Jeff Nordgren commented ·

@Swarup Anna

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

0 Likes 0 ·
Swarup Anna avatar image Swarup Anna commented ·

@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 Likes 0 ·
Swarup Anna avatar image Swarup Anna commented ·

Sorry @jeff.nordgren

Please check this model too

samplemodel1.fsm

0 Likes 0 ·
samplemodel1.fsm (22.9 KiB)
Sam Stubbs avatar image Sam Stubbs ♦ Swarup Anna commented ·

Thank you for sharing with everyone. Looks great.

0 Likes 0 ·
Swarup Anna avatar image Swarup Anna Sam Stubbs ♦ commented ·
@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 Like 1 ·
Jeff Nordgren avatar image
4 Likes"
Jeff Nordgren answered

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


5 |100000

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

Sam Stubbs avatar image
3 Likes"
Sam Stubbs answered Sam Stubbs edited

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)
5 |100000

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

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

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