MTBF with preempt not working when using Network Nodes

Question

question

Yunjukuo asked Jun 15, '22 Jeanette F commented Jun 23, '22

MTBF with preempt not working when using Network Nodes

Attached models’ setting are the same, the only difference is one named ”… NoNetwork” do not use Network Nodes.

I’m using FlexSim 2016.1.2. However, I also attached same question using FlexSim 2022 just in case only few people can solve problem using 2016.

[Question]

When Network Nodes are not used, "preempt only" task(when breakdown) of the MultiProcessor can run sucessfully, but when using Network Nodes , the "preempt only" task of MultiProcessor fails, and the dispatcher dispatches operator according to FIFO and Priority.

What is the reason? How to fix it?

[Model Setting]

▪ Breakdown may occur in two Multiprocessors in the model, and when the breakdown occurs, operator are required to repair the machine ( "preempt only" task).

▪ Breakdown logic of a machine named MultiProcessorMTBF follows the MTBF setting.

▪ Breakdown logic of machine named MultiProcessorBreakByCode is written in the “Process Time” setting of “Process2”. If breakdown occurs, machine will be stopped and call operator in its OnMessage trigger (the code is copied and modified from MTBF).

▪ Opretor2 have rest time according to TimeTable setting. (state: Shedule down)

Eventually I want to achieve the following setting, if all could be solved at once will be perfect.

(1) Preempt only can be successfully executed in the situation with Network Nodes and self-define breakdown logic (e.g. code in MultiProcessorBreakByCode).

(2) When multiple machines have “preempt only” tasksequence at the same time (e.g. 2 machines), dispatcher can simultaneously call the number of operator required that are doing “no preempt” tasksequence to do “preempt only” tasksequence (in this case will be call 2 different operators at same time).

Current model might call the same operator for two machine with “preempt only” tasksequences, which is not the case I want.

(3) Prevent operator from doing “preempt only” tasks during the rest time set by TimeTable. (I didn’t set “preempt only”in TimeTable due to operator can start to rest only after completing tasksequence on hand)

preempt_BreakdownCode_F2016_NoNetwork.fsm

preempt_BreakdownCode_F2016.fsm

preempt_BreakdownCode_F2022.fsm

preempt_BreakdownCode_F2022_NoNetwork.fsm

Software Version:

FlexSim 16.1.2

network nodes mtbf mttr preemption

preempt-breakdowncode-f2016-nonetwork.fsm (30.8 KiB)

preempt-breakdowncode-f2016.fsm (34.5 KiB)

preempt-breakdowncode-f2022.fsm (47.9 KiB)

preempt-breakdowncode-f2022-nonetwork.fsm (45.6 KiB)

· 2

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.

Joerg Vogel commented · Jun 15, 2022 at 07:59 PM

I haven’t looked into a model so far.

Preempting in general executes upon priority. If a preempting tasksequence has got a lower priority than currently active tasksequence it will just placed into tasksequence queue and does nothing right away.
There is a mechanism involved if you are preempting taskexecuters on a network node system. If a preempting tasksequence is executing successfully, a taskexecuter leaves the network node system right away and is in offset travel state.
Both procedures MTBF MTTR and timetable are using the same command to stop an object. There is a parameter to distinguish which couple of stop and resume object belongs together. It is the stop ID.
A taskexecuter, on which a stop object command is called, creates automatically in background a tasksequence with a high static priority value and preempts currently active tasksequence. BUT if he is already in such an automatical created tasksequence any newer stop object creates only a tasksequence of the same high priority which is only placed into tasksequence queue node.
If you want to preempt an already stopped Taskexecuter you have to set an higher priority value in your preempting tasksequence. As far as I remember, an automatically stopped gets a static priority value of 10000.

If you have set the same stop ID value in stop object command, The resume event cannot distinguish which halted event will be resumed. The system only keeps track how often an object has been stopped. You must call as often a resume command as often you have called a stop.
As I said you can preempt an stopped taskexecuter and set him active again. But the FlexSim engine still keeps a record how often an object is stopped AND the engine event list still executes already timed resume events even if a taskexecuter is reactivated by a higher priority preempting tasksequence.

In situations like yours, I prefer to create my own tasksequences which are based on utilization task rather than a simple stop object command. I still have priorities but I have more keys to keep track which stopping event I am going to end be freeing a taskexecuter from an utilization task. And I can decide to preempt NOT a currently active task and just queue the stop mechanism to be executed as next tasksequence.

0 ·

Jeanette F ♦♦ commented · Jun 23, 2022 at 04:12 PM

Hi @Yunjukuo, was Felix Möhlmann's answer helpful? If so, please click the "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.

If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.

0 ·

Answer 1 · 2022-06-16T06:52:16Z

Felix Möhlmann answered Jun 16, '22 Felix Möhlmann commented Jun 18, '22

This is from the 22.0 version of the model, so I can't guarantee that it works the same in the 2016 version.

When the dispatcher receives the coordinated task sequence it creates smaller sub sequences that then get dispatched to the operators.

So the 'Pass To' code is run for that sequence (ts5). That code checks if the taks sequence includes a travel task to determine the target object. Because ts5 doesn't, the 'travelDest' stays as the default value and points to the dispatcher itself.

The dispatcher is not connected to the travel network, so 'distancetotravel()', which is used to find the nearest object to the target, returns *a very large number*. This then causes 'findmin()' to 0, possibly because the minimum expression value is initialized as a smaller value then what is returned as the distance. So no operator is deemed to be valid and the code returns 0, meaning 'First Available'.

This also influences the model without network: The operator closest to the dispatcher is send to repair the processor, not the one closest to the target.

To circumvent this, you could first check if the dispatched task is of the 'TE_Allocate' type, belonging to a coordinated task sequence. In that case, the code to check for travel tasks is run for the coordinated task sequence, so it returns the correct target.

To ignore operators that are currently on break, I'd suggest to set a label on them in the time table down function (reset it when resuming). This can then be used in the 'Pass To' code to ignore such operators.

Similarly, you could also check if the operator is already doing a preempting task sequence at the time and ignore it in that case as well to distribute the repair tasks better.

preempt-breakdowncode-f2022-fm.fsm

1655359919653.png (22.5 KiB)

1655360068919.png (11.1 KiB)

1655360442401.png (12.5 KiB)

1655361262363.png (31.9 KiB)

1655362298895.png (22.1 KiB)

preempt-breakdowncode-f2022-fm.fsm (47.5 KiB)

· 3

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.

Jason Lightfoot ♦♦ commented · Jun 16, 2022 at 01:31 PM

Thanks @Felix Möhlmann - I've sent in a request to consider adding your improved script to the picklist option.

0 ·

Yunjukuo commented · Jun 18, 2022 at 02:27 PM

Thanks Felix Möhlmann , that is close to what I'm looking for.

However, I found some exception in proposed coding logic. I only changed the TimeTable shedule down time from 1 hour to 60sec for observation in the attached model.

At 144.66 sec, both operator1 and operator2 were dispatched to repair "MultiProcessorMTBF" (which should only need one operator in MTBF setting). After that they go back to do no preempt task sequence (while at the same time exist preempt only task sequence ).

preempt-breakdowncode-f2022-fm_60secRest.fsm

0 ·

preempt-breakdowncode-f2022-fm-60secrest.fsm (48.2 KiB)

Felix Möhlmann Yunjukuo commented · Jun 18, 2022 at 03:38 PM

1) Two operators being called

This is sort of a bug, but really more of an unintended side effect. The setting 'Break down members individually' is not active. This causes an 'End Down Time' event to be scheduled to happen 15s (down time) after the members go down, regardless of the operator requirement. This event afterwards happens a second time, when the machine gets repaired by the operator.

Both of these events will schedule a new breakdown. As a result, an extra breakdown is added in each cycle. These will quickly start to overlap, starting a second breakdown while the machine isn't repaired yet. This extra breakdown might then call the second operator.

2) Task order

This is normal behaviour. 'Preempting' just means that an active task can be interrupted by a newly received task sequence. When choosing a task from the queue only the priority value is used to order the available sequences. To have repair tasks always happen first, increase their priority.

preempt-breakdowncode-f2022-fm-60secrest_1.fsm

0 ·

1655566460698.png (21.1 KiB)

1655566476390.png (7.4 KiB)

preempt-breakdowncode-f2022-fm-60secrest-1.fsm (46.8 KiB)

question