TaskSequence in ProcessFlow

[SimFlex_support]

[ FlexSim 16.0.1 ]

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.

[JordanLJohnson · Accepted solution]

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:

1. An item finishes, so the processor calls the sub flow, creating a token
2. That token gives a load task to the operator. Note that the token does not immediately move on. The operator begins walking towards the processor.
3. Another item finishes, so the processor calls the sub flow again, creating another token.
4. The newest token creates another load task and gives it to the operator.
5. The operator arrives at the processor, and loads the first item. The operator then moves to the next task in the sequence, which happens to be another load task, so the operator loads the item.
6. Both tokens move to the unload task as soon as their respective load tasks are complete, and both generate an unload task for the operator.
7. The operator goes to the unload destination, and unloads the first item. The operator then begins the next task in the sequence, which is to unload the second item.

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.

[JordanLJohnson]

Note: there is a bug in the zone's max content field. To use this method in 16.0 or the current 16.1 beta, you should use getvarnum(zone, "maxcontent").

[SimFlex_support]

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.

[anthony_johnsonT83CM]

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.

[Brandon_Peterson]

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.