question

General remarks:

• If you batch items and such a batch is not split up again later, then you are better of with a combiner in join mode. You have only item then. You can keep data in labels. Then you are still able to build statistics just from those values.
• if you need items later as single items then you use pack mode. It results in container structure. A container with subnodes of items. The container is your reference that gets a reference of item in triggers or events in process flow.
• If you want to collect items and process them in a batch mode, then this is completely collectIng them in combiner. The processed items are processed together and ready ready to exit simultaneously, but they are still single items then.
  
  

In 3D Model a Transport of items is a supporting Process. It moves items by spending time on travel to different objects. Primarily it is a transport of one item at a time. An involved object is called in general a taskexecuter. A taskexecuter can transport more items at once. BUT each loaded item has got its own transport job called a tasksequence.
If you combine items in join mode this makes it simpler to transport such a batch because it is just one item. A packed item behaves equally.
A batch of 12 single items gets complicated, because of 12 individual transport jobs executed simultaneously in a taskexecuter. Loading and Unloading is LIFO mode by default.

Please repeat tutorials of transports for basic 3D modeling. You will see that you build a material flow by object connections. Then you add an operator to your model, which gets a center port connection to an 3D object. This is just a simple reference connection. You activate in properties of the sending object the option Use Transport in Output pane. There is set by default a reference to first center port connected object to do this transport job. If you let run your model, the transport is done. FlexSim creates in background automatically tasksequences to transfer each item. FlexSim dispatches those tasksequences to referenced objects. The referenced object executes the tasksequences. All this is done by setting an option of Use Transport and a center port connection to a Taskexecuter which can be an operator, a transporter, an agv, or any other member of Taskexecuter class.

You can do the same in Process Flow. You do this by telling a referenced Taskexecuter every single step of an involved transport job:

1. travel to load station,
2. load item at load station,
3. travel to unload station,
4. unload at destination the transported item.

An automatically created tasksequence has got an additional task between point 2 and 3. It is an interrupt, which gets executed if the Taskexecuter has got capacity to load more than currently loaded items left. Then the default function “Break To” gets executed in the Taskexecuter, which normally searches for additional available transport jobs to execute as a next one simultaneously.

A taskexecuter can load more items, if there is enough capacity. And by default a taskexecuter loads as much as possible even from different load stations. This can be a wanted behavior, but if you want to restrict load stations then this can get complicated. And if this happens, then a process flow logic is a better choice.

Runtime and Sequence of executing tasksequences can result in strange behaviors. There is not an intelligence inside of FlexSim. Everything works with the paradigm of FIFO. If something is happening in a model and there is a sequence is involved, then this sequence of action is done to the end and then starts a next sequence. This means even if everything happens at the same time point there are many sequences of actions happening after another, and if inside of a sequence changes a value or a state, then this won’t changes an already waiting sequence nor push waiting sequences back to a later rank in the list of waiting sequences. This changed value or state is pushed to the last rank of waiting sequences. This seems complicated but it follows strict basic rules. And then it seems for a watching person that a model behaves strange.
In such a Case a Process Flow logic might be a better choice, too.