question

Bryan Suharik avatar image
0 Likes"
Bryan Suharik asked Sam Stubbs commented

Process Time depends on number of Operators

Hello,

I'm trying to figure out the best way of varying process time by operator. I have flow items that enter a processor for X amount of time depending on what flowitem it is and it calls over Y amount of operators. However, i want the item to be able to continue to process the flowitem at a slower rate if less than Y amount of operators are available. Additionally, if any idle operators are in the model, have them assist priority flowitems to reduce the process time.

I'm looking for some solutions via code as my model is built from code on startup. Process flow would maybe be the best option, but i'm a bit new to developing process flows, so may need some help.

Thanks in advance!

bryan

FlexSim 16.2.2
operatorcodedependantcycletime
· 2
5 |100000

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

Bryan Suharik avatar image Bryan Suharik commented ·

@Sam Stubbs

Thanks Sam, That seems to be most of what i'm looking for. You've give me something to think about for the second question part...i will work toward that as that would provide the most detail to my model.

At some point, if extra operators are added, efficiency will go down for each operator working on the unit....is there a way to work that in to the process flow so that each operator is working at only 90% once the operator count gets to 4, for example? And then when the operators are released from the processor, they go back to 100% unless that scenario arises again...

thanks for the help!

bryan

0 Likes 0 ·
Sam Stubbs avatar image Sam Stubbs ♦ Bryan Suharik commented ·

I would imagine that you could work that into the process time equation in the custom code of the processor time. Add an if statement that checks the opNum label on the processor. If the opNum label is greater than 4, instead of just dividing by the number of operators have it instead divide by (number of operators * 0.90) that should work.

0 Likes 0 ·

1 Answer

Sam Stubbs avatar image
2 Likes"
Sam Stubbs answered Sam Stubbs commented

So I think that Process Flow really will be the best way to approach this situation. What you can do is use Process Flow in conjunction with lists, to create a dynamic process time / number of operators.

I've created an example model for you to look at. How I approached this was as follows:

  • First I have a Process Flow Block initialize a list of Operators I'm going to use in the model.
  • Then I have items pushed to a list and pulled to be sent onto the processors.
  • Then I have a Global List which says the requested amount of Operators and the total Time needed of process time per itemtype.
  • As the item is pulled from the list, it checks the table to pull the requested operators for that itemtype if they are available. And pull up to that many operators from the operator list.
  • Then the model acquires a Processor from the resource group. It assigns a label onto that processor detailing the number of operators pulled from the list to help with the task.
  • In the processor's properties. I have the Process time return a value equal to the lookup value on the table of total time per item type, divided by the number of operators able to be acquired.
  • The item is moved and processed, A subflow directs each of the operators to the processor. Then operators are pushed back onto the list, and the processor is released back to the available resources.

Here is the example below:

example1.fsm


example1.fsm (34.0 KiB)
· 2
5 |100000

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

Bryan Suharik avatar image Bryan Suharik commented ·
@Sam Stubbs

Hi Sam, Thanks for the reply. On your model, it's only letting one flowitem through for each processor and then it stops.

Can this process flow pull a free operator halfway through a process time and in turn speed up the remaining process time on the flow item?

Thanks,

Bryan

0 Likes 0 ·
Sam Stubbs avatar image Sam Stubbs ♦ Bryan Suharik commented ·

There I fixed it. ON the Release activity I had forgotten to update the label of the resource to processor, so it was trying to return "resource" which didn't exist. Now the operators should continue to work past the first two items.

example1-1.fsm

As to your follow up question, that gets really tricky. The processor's processing time is determined beforehand in the code. So there's not really a way to change it in the middle of processing. The only thing you could do, is interrupt/stop the processor. Record how much time has already been processed. Subtract that from the total time needed. Then restart the processor, with that remaining time as the new "total" and then divide that by the number of workers working on it. So that would be doable, but messy. Also a tricky part would be figuring out how/when to acquire a newly freed operator, pull him from the list, append him to the array of currently acquired operators, and tell him to go to the processor upon which you'd do the above interrupt/stop/restart of the processor. I'm not quite sure how to set that all up, but you might be able to do that with some of the preemption activities in Process Flow.

0 Likes 0 ·
example1-1.fsm (34.0 KiB)