CenterPort choosing problem

Question

question

Joe L6 asked Nov 23, '22 Joe L6 commented Nov 23, '22

CenterPort choosing problem

Hi team,

I have a question about CenterPort choosing. In my previous question(the link is as below), the operators in my model have a shift schedule. And I use 'Shift' globaltable and timetable to make it work.

https://answers.flexsim.com/questions/131586/operator-dayoff-setting.html?childToView=131579#answer-131579

Now I want my operators have different ability(operators only process the specific machine). To do this, I give every operators one Dispatcher, and connect the specific machine with the Dispatcher that the operators can process.

My problem is if there is a machine that 2 operators can process it, but we need to consider the shift schedule first. In the end there are only the operator that the shift schedule says will process the machine, other operators will go to 'Dayoff' item.

To simulate the above situation, I make a simple model. The only work that the operators can do is carry the item. I just want to know how to make the queue or machine choose between different centerport.

I try to write the code in the 'Use Transport' of Queue 1 and Queue 2. But it seems like I only can control Operator1.

How can I make the Queue and Processor choose the correct operator? Can I do it with writing code? Or the 'List' function can do it? Thanks for your reading and helping!

CenterPort_Choosing_Problem.fsm

Software Version:

FlexSim 18.1.2

pickoperator centerport usetransport

op2-cant-control.png (432.5 KiB)

queue-code.png (71.6 KiB)

centerport-choosing-problem.fsm (29.0 KiB)

Answer 1 · 2022-11-23T07:39:39Z

Felix Möhlmann answered Nov 23, '22 Joe L6 commented Nov 23, '22

In your if-conditions (line 27 and 43) your are using the assignment operator "=" instead of the equals comparison "==". This means two things: The expression "result = 1" will always evaluate as true and the result variable is overwritten with the value 1. As such, the first centerport connection is always chosen.

As a side note, if the table value for operator 2 is 0 at the given time, your code would try to return the 0th center object, which would throw an error.

· 10

Joe L6 commented · Nov 23, 2022 at 08:57 AM

Thank you @Felix Möhlmann , I fix my code and the queue can choose the correct centerport according to the 'Shift' globaltable now.

Now I have another problem that when the time goes to the night shift, Operator1 will go to 'Dayoff' object as setting in the Timetable. But Operator2 won't leave the 'Dayoff' object and do the work.

It seems like the 'Use Transport' logic in the Flow didn't renew with the time. How can I make the Queue and Processor keep renew every 12 hours? Thanks!

And I upload my new model as follows, Thanks!

centerport-choosing-problem-v2.fsm

0 ·

fixed-code.png (1.1 MiB)

shift.png (2.9 KiB)

centerport-choosing-problem-v2.fsm (29.1 KiB)

Felix Möhlmann Joe L6 commented · Nov 23, 2022 at 09:41 AM

The code is run every time an item needs to be moved, there is no need to "renew"/"update" anything. But the condition in line 21 to determine if the day shift or night shift is active doesn't work like that. (Missed this on my first look at the model)

First, multiple comparisons in a line like that will evaluate in order from left to right, with the result of the previous being used for the next. For example, if hour is 12:

"7 < 12 < 19" -> "(7 < 12) < 19" -> "(1 (true)) < 19" -> "1 (true)"

You have to combine multiple conditions with logical operators (&& for AND and || for OR)

Also, since after 7AM the day shift should be active, the condition should check if hour is larger or equal to 7.

1 ·

1669196362749.png (1.9 KiB)

Joe L6 Felix Möhlmann commented · Nov 23, 2022 at 10:02 AM

Thank you @Felix Möhlmann for the explain. I fixed my code and the model works as I expected now. If I have another problem I'll come back here and ask. Thanks!

0 ·

Joe L6 Felix Möhlmann commented · Nov 23, 2022 at 01:36 PM

Hi @Felix Möhlmann ,

Now I face a problem with my Main model. It may be a little bit confused for you, but I try to focus on my problem so you don't need to understand my whole model.

I find out that when the units digit of the output quantity in GWC1_Source all comes with 0, the model works well. But when some units digit isn't 0(in the picture I set it all 41), Operator2 will stuck even there's a work need to do.

I only find out the number of the item that Source created will leads to the problem. I'm not sure is it a bug of FlexSim or maybe I did something wrong.

If you can find out the problem I'll be appreciate it. Or if you have any problem with my model setting I can explain to you. Thanks!

Main Model Problem_Operator Stuck.fsm

0 ·

units-digit-not-0.png (16.9 KiB)

main-model-problem-operator-stuck.fsm (122.9 KiB)

Felix Möhlmann Joe L6 commented · Nov 23, 2022 at 01:48 PM

It looks like your model didn't upload successfully. Could you try again?

(You can see if it was successful by checking if it appears as an attachment at the bottom of your post)

1 ·

Joe L6 Felix Möhlmann commented · Nov 23, 2022 at 02:39 PM

Hi @Felix Möhlmann ,

I edit my comment to upload my model called 'main-model-problem-operator-stuck.fsm'. Please take a look. Thank you!

0 ·

Felix Möhlmann Joe L6 commented · Nov 23, 2022 at 04:16 PM

The only "work" I see are the items in queue M10_QO. Those were put there during the day shift, before operator1 ended their shift and are thus assigned to the first dispatcher, which is waiting for operator1 to become available again.

One way to work around this would be to move all pending task sequences to the other dispatcher when the shift changes (this assumes of course that the active operator always alternates). This could be triggered by sending messages between the two dispatchers.

The initial message of the loop is send in the "On Model Reset" trigger.

main-model-problem-operator-stuck_1.fsm

Though I actually question why there are even two dispatchers per zone in the model to begin with? The time table already keeps the inactive operators occupied. You could just as well use a single dispatcher connected to both operators. This would also eliminate the need for the custom logic in the transport and operator reference fields.

1 ·

1669218395931.png (53.5 KiB)

1669219529507.png (42.3 KiB)

1669219592852.png (9.2 KiB)

main-model-problem-operator-stuck-1.fsm (190.0 KiB)

Joe L6 Felix Möhlmann commented · Nov 23, 2022 at 04:57 PM

Thank you @Felix Möhlmann

Let me answer the question you asked about why there are two dispatchers per zone. I want the operators have different ability. For example, OP1 can process machine 1, 2, 3, and OP2 can process machine 3,4,5. For machine 1,2,4,5, I can just connect them with corresponding operators. But for the special case like machine 3, I need to connect both OP1 and OP2 with it. And the timetable will decide which operator will do the work.

I was worried that if I use only one dispatcher per zone, it means all operators connected to the dispatcher have the same ability. I can't distinguish them. Or is there a way using only one dispatcher, but make operators have different ability(to make them process the specific machine)?

For example, I connect one dispatcher with machine 1,2,3,4,5, and connect the dispatcher with OP1 and OP2. When OP1 work, he only process the machine 1,2,3. When OP2 work, he only process the machine 3,4,5. Is it possible to make it happen? Thank you!

0 ·

Felix Möhlmann Joe L6 commented · Nov 23, 2022 at 05:51 PM

In that case, moving all pending task sequences might also be wrong, since they might contain tasks that the operator is not supposed to do.

You'd have to search the tasksequences for their involved objects and decide whether it should be moved or not.

You can use the same logic to decide who to pass a tasksequence to in the first place.

In the attached model some objects have the label "op" on them. If they do, then only the corresponding operator (by rank of dispatcher connection) is allowed to do tasks that involves the object. Objects without the label can be worked by any operator.

This is achieved by the following code in the "Pass To" field of the dispatcher.

/**Custom Code*/
treenode tasksequence = param(1);
Object current = ownerobject(c);

// Go through tasks and check labels
for(int i = 1; i <= getnroftasks(tasksequence); i++) {
    int taskType = gettasktype(tasksequence, i);
    // Is it a travel, load or unload task?
    if(taskType == TASKTYPE_LOAD || taskType == TASKTYPE_UNLOAD || taskType == TASKTYPE_UTILIZE) {
        // Does the involved object have the "op" label
        Object station = gettaskinvolved(tasksequence, i, 2);
        if(station.op?) {
            // Return the label value as connection rank
            return station.op;
        }
    }
}

// First available otherwise
return 0;

The operators in the model work in 12 hour shifts, similar to your model. You can see that operator1 services processor1 and 3 and operator2 services processor2 and 3.

dispatching_logic.fsm

1 ·

dispatching-logic.fsm (29.0 KiB)

Joe L6 Felix Möhlmann commented · Nov 23, 2022 at 06:21 PM

Thank you @Felix Möhlmann for your explaining, I think I have a better understanding of Dispatcher!

It's 2 AM now in my place and I need to go to bed now. I'll try to work on this when I wake up. And if I have any problem I'll come back here. Thank you for your kindly help! I appreciate it!

0 ·

Answer 2 · 2022-11-23T05:17:27Z

Lucas Antonio Risso answered Nov 23, '22 Joe L6 edited Nov 23, '22

Have you considered using the option "center port by case"?

· 1

Joe L6 commented · Nov 23, 2022 at 09:08 AM

Hi @Lucas Antonio Risso,

I solved my first problem and I think the 'center port by case' can solved it too.

Now I have another problem that I expect the Queue or Processor recheck the 'use transport' or 'pick operator' logic every 12 hours.

Is it possible to make it happen in the 'center port by case' option? Thanks!

PS: Here's my new model, it only works for the first 12 hours. Thanks!

centerport-choosing-problem-v2.fsm

0 ·

centerport-choosing-problem-v2.fsm (29.1 KiB)

question