Process Time depends on number of Operators

Question

question

Bryan Suharik asked Feb 09 2017 at 1:26 PM Sam Stubbs commented Feb 10 2017 at 5:22 PM

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

Software Version:

FlexSim 16.2.2

operator code dependant cycletime

· 2

Bryan Suharik commented · Feb 10 2017 at 4:30 PM

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

Sam Stubbs ♦ Bryan Suharik commented · Feb 10 2017 at 5:22 PM

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 ·

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

Answer 1 · 2017-02-09T16:31:40Z

Sam Stubbs answered Feb 09 2017 at 4:31 PM Sam Stubbs commented Feb 10 2017 at 2:19 PM

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

Bryan Suharik commented · Feb 10 2017 at 4:02 AM

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

Sam Stubbs ♦ Bryan Suharik commented · Feb 10 2017 at 2:19 PM

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 ·

example1-1.fsm (34.0 KiB)

question