Incorrect processor state when both processor and operator are stopped by TimeTable

Question

question

Allister Wilson asked Oct 10, '16 Kari Payton commented Oct 10, '16

Incorrect processor state when both processor and operator are stopped by TimeTable

In the attached 16.2.0 model, a processor uses an operator for its process.

The processor is stopped during its process, its state is breakdown as expected.

Then the operator is also stopped (t=4500), the processor goes into the waiting for operator state, it should still be in breakdown.

Am I doing something wrong with the time tables, or is this a bug?

schedule-down-machine-operator.fsm

Software Version:

FlexSim 16.2.0

operator processor time table scheduled down

schedule-down-machine-operator.fsm (19.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.

Answer 1 · 2016-10-10T16:26:37Z

Phil BoBo answered Oct 10, '16 Allister Wilson commented Oct 10, '16

When you break the operator down, it is currently in a Utilize task where the involved station is the Processor.

Because the operator is being utilized by the processor, the operator calls stopobject() on the processor when the operator goes down, setting the processor for waiting for operator until the operator is resumed.

This is all working as designed. The processor has been stopped twice, once for a scheduled down and once because it was being utilized by an operator and the operator went down.

If you want the processor to remain in the scheduled down state when it goes down waiting for operator, you can increase the priority value on the stopobject() call on your processor's Time Table Down Function from 0 to 1.

· 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.

Allister Wilson commented · Oct 10, 2016 at 04:43 PM

Thanks for clearing that up!

0 ·

Answer 2 · 2016-10-10T13:54:20Z

Kari Payton answered Oct 10, '16 Kari Payton commented Oct 10, '16

Hi @Allister Wilson. As I understand, a processor cannot have multiple states at one time. So in reality, it is broken down but waiting for an operator to come fix it. The reason the operator never comes is because in the time table the operator goes off shift before the processor is repaired. See the model attached for details. I included a dashboard to show the status of machine and operator. I also changed the operator to be on shift longer. 2940-schedule-down-machine-operator-result.fsm

2940-schedule-down-machine-operator-result.fsm (22.4 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.

Allister Wilson commented · Oct 10, 2016 at 02:21 PM

Thanks for your answer, however in this case the processor is not waiting for the operator to fix it, the stops are simply calls to stop / resumeobject, no operator is called for repairs.

I think the processor should remain in its broken down state until it is resumed by the time table.

0 ·

Kari Payton Allister Wilson commented · Oct 10, 2016 at 04:49 PM

Oh I see. Sorry I misunderstood.

0 ·

question