question

Monte123 avatar image
0 Likes"
Monte123 asked Monte123 edited

Partial Batch Release: Move Some Products Forward, Keep Producing the Rest

new-innision-simulering-2_autosave - Copy - Copy.fsm
Hi FlexSim Community,

I’m developing a model that produces different product types along various routes. In my Process Flow, OFM1 that produces 10 units of a product, but I’d like 3 of those units to move on once they’re finished, while the remaining units continue to be produced at OFM1. I’ve defined this as “Overlapsantall” in the Schedule Source.

Right now, however, the system waits until all 10 units are completed before sending them onward, seemingly governed by the “Antall” (quantity) setting. This behavior needs to change so the three finished units can continue downstream while the rest remain in production.
1744041892310.png

Does anyone know how to configure Process Flow to handle this partial batch movement? This is critical because I plan to use the same approach for the rest of my process flow.


Does anyone have advice or best practices on how to configure Process Flow to achieve this?
Thank you in advance for your help!
new-innision-simulering-2_autosave - Copy - Copy.fsm

FlexSim 24.2.1
processs flowbatchmoveobjectwaitforevent
1744041892310.png (18.7 KiB)
new-innision-simulering-2-autosave-copy-copy.fsm (141.5 KiB)
new-innision-simulering-2-autosave-copy-copy.fsm (141.5 KiB)
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Felix Möhlmann avatar image
1 Like"
Felix Möhlmann answered Monte123 edited Best Answer

Based on the example I provided in your most recent post I build an example of how this could function. Essentially each batch token is split up into multiple sub-batches, each represented by a token. Only the first of the sub-batch tokens enters the respective zone. Others wait until this has happened before they are also allowed to move to the next station.

To sync the sub-batches I use lists. The first token puts itself onto a list (partition defined by batchID and area) as many times as there are other sub-batches once it enters the zone. Similarly, the first token has to wait until all other sub-batches have arrived in the current area (so a batch nevers spans more than two areas at a time). I don't know if this is actually a requirement, but wanted to showcase how this could be done.

The last sub-batch token then exits the zone and thus frees up the area for the next batch. Note the values I use in the "Enter For" and "Exit For" fields in the Enter and Exit Zone activities. The token that enters the zone is the 'main' token of the first sub-batch, not the one that enters the activity. Because only that token is persistent. The sub-flow token will likely not exist anymore by the time it would need to exit the zone.

batch-processing-3.fsm


batch-processing-3.fsm (44.8 KiB)
· 4
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Monte123 avatar image Monte123 commented ·

Hello @Felix Möhlmann
In your example, the number of sub-batches stays the same throughout each processor because it’s determined by the CreateTokens function. Within CreateTokens, three tokens are created: the first two tokens are each assigned the same number of sub-batches (which is 3 in your example), and the third token represents the remaining batch size (which is 4). Thus, the total quantity is 2×3+4=10. This setup leads to the same logic being applied in all the Run Sub Flow (1–4).

However, I forgot to mention that in my scenario, a product can pass through multiple processors, and each processor may use a different number of sub-batches. For instance, Processor 1 might use 3 sub-batches, Processor 2 might use 4, and so on. In my system, there are three possible cases:

  1. Sub-batch count = 0: The processor must process the product in its entirety before moving on.

  2. Sub-batch count = 1: The processor sends one item at a time to the next processor.

  3. Any other specific sub-batch count: The product should follow the logic you demonstrated in your example.

I tried to adapt your logic so it could accommodate these scenarios. I’m envisioning a setup as shown in the picture.

1744455105819.png

Where CreateTokens is separate from the Run Sub Flow (1–4). When a product enters RunSubFlow 1, it would create the necessary number of sub-tokens in a “Sub Flow Decision” that manages a specific number of sub-batches. When the first sub-batch finishes and moves to the next processor, the main decision flow could create an additional token and continue from there. Meanwhile, the remaining sub-batches would still be running in the first processor. Once those sub-batches finish, they would somehow merge back into a single token. I’m not entirely sure if this approach is feasible, or if an alternative logic would be better.

I’ve also updated the source to show which processors use specific sub-batch sizes as an example.


Thank you again for your help, and please let me know your thoughts!

batch-processing-3.fsm

0 Likes 0 ·
batch-processing-3.fsm (106.2 KiB)
Felix Möhlmann avatar image Felix Möhlmann Monte123 commented ·

I think going back to one token per item makes sense for this. In hindsight it probably would have been the better choice even for fixed sub batch sizes to begin with.

That way you can simply batch the required amount after each sub flow. There is still one main token per batch though, that is entered into the zones as a proxy.

I am currently not a PC with an active license for the 24.2 version, so I had to remove the fourth processor from the Process Flow to stay under the limit of 35 activities. The concept should be clear nonetheless, I think.

batch-processing-4.fsm

1 Like 1 ·
batch-processing-4.fsm (49.1 KiB)
Monte123 avatar image Monte123 Felix Möhlmann commented ·

@Felix Möhlmann

Thank you for your help! I really appreciate it, and I think the solution is very impressive!


0 Likes 0 ·
Show more comments