I am working through the tutorials for Process Flow.
While studying them, I found a problem in the TaskSequence tutorial.
When changing the capacity to '2' in the second processor, the second operator transports two items at same time, though the operator's capacity is '1'.
What's the problem? Is it a bug?
I am using 16.1.0 beta.
This is expected behavior. The processor is requesting an operator for every flowitem. With standard 3D objects, the processor generates the complete task sequence (including load and unload tasks) for the operator, and then gives it to the operator. The operator, in turn, completes each task sequence in order.
Because this example uses a subflow to manage transport, the processor does not do any of that logic. Instead, it assumes that the subflow will handle everything. The processor does nothing more than call the subflow when the item finishes.
In this case, the following sequence of events sometimes occurs:
A simple way to use the operator's max capacity would be to surround the load and unload tasks with a Zone. Have the Zone use a max content of getvarnum(current, "maxcontent"). That way, the operator will only receive as many load tasks as its max content allows.
getvarnum(zone, "maxcontent").
I wonder the differences between TaskSequence of 3D model and one of ProcessFlow. I changed only the processor's max capacity not operator's capacity.
In 3D model without Processflow, the operator transports two times about two items.
It means the tasksequence is move>load>delay>unload>move>load>delay>unload via two tasksequences.
But in the case with ProcessFlow, the subflow tasksequence is move>load>load>delay>unload>unload.
The operator's capacity is only ONE in a time. But in the case of ProcessFlow, the operator transports TWO items at a time.
I want to know why it happens.
David,
In the 3D example you are creating two unique task sequences that get executed separately. It is likely that both tasksequences include a break task that would allow the operator to load more than 1 item but this does not happen because the operator's max content is 1.
When you use a Process Flow to give commands to the operator they can override the default logic of the operator. In your example this is what your are doing and it is why the operator is picking up more than one item.
The max content setting on the operator is more a "suggestion" than a hard set rule. In the end, task sequences are king, both in the standard 3D world and in the Process Flow world. In other words, if a task sequence tells an operator to load more than one item, it will load more than one item, no matter what its max content is.
The way that the standard 3D modeling logic integrates the max content setting into the mix is via the break task. Actually, the break task is the only place in the internal task executer logic where max content is considered. The standard transport task sequence is: travel - load - break - travel - unload. The break task allows the operator to break away from his current, single-item-focused task sequence, and go to a different task sequence, essentially allowing the operator to multi-task. However, when the operator gets to the break task, he will first check his max content, and if his current content has reached his max content, he will not break to a new task sequence, but will instead finish the task sequence he is on, unloading the item he just loaded.
The break task's exclusive use of the max content setting is the reason why I say the max content setting is a "suggestion" more than a hard rule. If you don't use the break task, then the internal task executer logic will never look at the max content setting at all.
While the standard break task based logic works for many cases, for some problems, such as doing proper unload sequencing, it's not very well suited. In these problems, Process Flow allows for much more customized control over the task executer. However, you would need to take max content into account explicitly. Usually this would just be a decide activity that uses some expression like content(object) < getvarnum(object, "maxcontent"), and then does one thing if the object still has capacity, and another if it doesn't.
In the upcoming 16.1 release, we've added an AGV template process flow that does high level AGV dispatching, and it does just that, looking at the max content setting and dispatching based on it. I mention that just to point you to a (future) example of how you might do it.
5 People are following this question.
FlexSim can help you understand and improve any system or process. Transform your existing data into accurate predictions.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
