Batching Combiner items by order and length range: 3D model logic or Process Flow?

[borja_lorenzo]

Hello,

I would like to ask about an evolution of the model I have been developing with Combiners to form pallets. In the following link you will find more context about the model, and I am also attaching the latest version of it.
Best practice for combiner output logic and incomplete pallets at end of production 

At this point, I have already solved two previous issues:

1.  In the FloorStorage before the Combiners, I modified the Send To Port logic to send the pieces in blocks of the batch size. This way, the operator finishes completing one batch in a Combiner before switching to the next one.
2. In the Combiner On Entry trigger, I added logic to handle the last partial pallet when the total number of pieces is not a multiple of the configured batch size. In that case, when the last piece enters, I dynamically modify the Combiner `Target Quantity` so that the partial pallet can be released.

Now I would like to add two new criteria to the pallet formation logic.

The pieces can belong to different orders. In my current model I have three orders, but in the real model there could be more or fewer. Also, the pieces do not necessarily arrive grouped by order; they may arrive at the previous FloorStorage in a mixed sequence. Therefore, the logic should be dynamic and should not depend on a fixed number of orders or specific order reference values.

The new logic would be that a pallet can only contain compatible pieces according to these two criteria:

• same order
• same length range.

At the moment, I have defined three length ranges:

• up to 3000 mm
• from 3000 to 6000 mm
• from 6000 to 12000 mm.

Therefore, if a pallet is being formed for a specific order and length range, pieces from another order or another length range should not be mixed into that pallet.

My main question is how to structure the control strategy for this grouping logic. Until now, the batching logic was relatively simple, because I only needed to group by quantity. But after adding order and length range as criteria, I understand that I first need to identify which pieces are compatible with each other before sending them to the Combiner.

Also, the logic for the last partial pallet would need to evolve. It would no longer be enough to detect the last global piece of the production run. Instead, I would need to detect the last piece of each order and length-range combination. That piece would then be the one that informs the Combiner that it should modify the `Target Quantity` to close the last partial pallet for that group.

The logic I imagine would be something like this:

• identify pieces by order and length range
• form batches only with compatible pieces
• do not switch to another Combiner until the assigned batch is completed
• detect the last partial batch for each order/length range combination
• dynamically modify the Combiner `Target Quantity` when the last piece of that group enters.

My question is whether this level of control is still reasonable to solve inside the 3D model, using labels, triggers, Send To Port, Pull Requirements, etc., even if it requires more code, or whether this type of batch formation logic would be more suitable for Process Flow.

I am not necessarily looking for the simplest solution, but rather trying to understand whether it is technically viable and maintainable to keep evolving this logic inside the 3D model, or whether it would be more appropriate to separate the batch formation logic and manage it through Process Flow.

Thanks in advance for any guidance.

[borja_lorenzo]

I wanted to add a brief update to this question, since I have continued working on this approach.

The solution I finally used is a hybrid approach. I moved the batch decision logic to Process Flow, where I group the items by order and length range, detect whether a full batch or a final partial batch is available, and select an available palletizing Combiner.

For the physical output from the FloorStorage, I still reuse the standard 3D logic, but with more control: Process Flow selects the candidate items and then releases them sequentially, after marking the items that should leave.

I discussed this part in more detail in this other thread related to the use of releaseitem():

Does releaseitem(item, port) release that exact item from a FloorStorage? 

My conclusion after testing it is that, for dynamic grouping logic by order, length range, and partial batch closing, Process Flow is more suitable for the decision-making part. The 3D logic is still useful for executing the physical movement, but trying to handle the whole batch selection only with triggers and Send To Port becomes less clear and harder to maintain.

I would be happy to discuss any other suggestions or interpretations.

[joerg_vogel_HsH]

A combiner is simple object counting items, which enter through a port number larger than one. As you have described, you can interrupt a collecting process, if your target quantity is larger than actually providing items for it. Typically you would update the target quantity before starting collecting rather than to depend on an interrupt.

Because of the simple nature of a combiner your logic depends on what you are sending to a combiner in amount and attributes. My personal approach would be exactly depending on this simple behavior. I send only items to a combiner I want to get counted to fulfill a target quantity.

Update a component list is a default template. You do this during the entry of your container item through input port number one. If you know at this stage of simulation, what you want to collect, you won’t need to interrupt a collecting process later. After that you send only items to your combiner that match your criteria. 
Adding a filtering process is selecting items from lists. So simple as this is expressed, it contains exactly what you do. You work with lists and queries. You have a demand and you seek for items that match this demand. 
Your question about what suits best, depends on how well you organize your logic code. Process flow can be used to visualize a logic, but you must replace code lines by activities to achieve this. If you still write custom codes instead of adding activities you are not better off than adding source code lines to triggers.