AGV task logic with several decisions

Question

question

Fred E asked Jul 7, '22 Felix Möhlmann commented Jul 11, '22

AGV task logic with several decisions

Hello!

I need some help or a solution for simulating the next problem.

Assembly line "LINIJA1" works much slower than processor KM001.

"LINIJA1" needs items from KM001 for production. We need to drive items from KM001 to "LINIJA1" but at queue SE1 there is space just for two items.

I want to implement the following logic in my model.

First, we drive items directly from KM001 to SE1.

When the queue SE1 is full then we need to drive items to warehouse WH. If in queue SE1 is less than one item, then we need to drive items from WH to SE1. Empty totes from SE1 are stored at warehouse WE.

Thank you in advance for your answers and advice.

Best regards!

My model: test50.fsm

Software Version:

FlexSim 21.2.4

agv decide flow logic

1657226278221.png (473.2 KiB)

test50.fsm (63.6 KiB)

5 |100000

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

Answer 1 · 2022-07-08T07:31:35Z

Felix Möhlmann answered Jul 8, '22 Felix Möhlmann commented Jul 11, '22

I believe in a situation like this it is better to have SE1 actively pull new items, so it can regulate its own content level.

To achieve this I introduced a new label 'Stored' on the items. It starts at 0 and is set to 1 when they enter WH. This allows to push the items of LoadType1 back onto the item list but prevent the transport tokens from pulling them by filtering by that label. The Transport Task Flow now only has the job to move processed items into WH. I also moved the Pull Item activity to the front, so they only load a tote, if they already pulled the respective item.

A second flow next to it represents SE1. While the number of items in the queue plus the number of pending transports is less than 2, tokens are created to pull items to that queue. Creating a new token for each pull allows for two things: simultaneous pulling/transport of multiple items, and the number of pending transport tasks correlates directly to the number of child tokens of the main token.

In the query I filter for items of LoadType 1 and order them by the stored label, so items at the processor are pulled first.

Depending on the value of the stored label, the tokens then take one of two paths, either first loading a tote and then the item inside it, or loading the tote directly from WH.

Finally, it makes sense that SE1 should have priority over the transport task tokens when pulling items from the list. To implement this, the tokens are given a 'PullPriority' value which is then used in the 'Back Order Queue Strategy' of the list to allow the SE1 tokens to pull first.

test50_fm.fsm

1657265330032.png (5.8 KiB)

1657265378674.png (15.4 KiB)

1657265396714.png (14.9 KiB)

test50-fm.fsm (69.8 KiB)

· 2

5 |100000

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

Fred E commented · Jul 11, 2022 at 08:58 AM

I am really grateful for your answer. Your solution works perfectly.

I have another option where I need to store items in the warehouse first. In that case assembly line starts to combine items later on so I need to drive all items from the warehouse in FIFO order. I still want that capacity in queue SE1 is not less than one.

I tried to model this but I don't know which kind of list I need to create to unload items at the SE1. Also, I don't know how to provide stock in SE1 for at least one item all the time.

My model where I try to apply those logic looks like this: test110.fsm

0 ·

test110.fsm (66.9 KiB)

Felix Möhlmann Fred E commented · Jul 11, 2022 at 10:26 AM

I'm not sure if I understand you correctly: All items should first be transported to the warehouse and only once an item enters L1 should type 1 items be brought to the combiner like before?

For that you could have the token that pulls items for L1 wait until the production starts before it pulls anything. If you want to simulate multiple days you would then maybe also want to add some abort criteria, so the token goes back to waiting for more input.

test50_fm2.fsm

Alternatively, you could also use your approach. One issue I see there is that you try to move the item by using 'token.item' which doesn't exist in that flow. Either add this label or use 'token.tote.first' or 'token.tote.subnodes[1]' to refer to the item directly in the 'Move Object' activity.

To transport an item for each incoming type 5 item, it would be better to use an event-triggered source and create a token for each item. Otherwise the looping token might 'miss' an item if it is not currently in the wait for event activity when the item arrives.

To move items ahead of the time they are actually needed, you could introduce an offset between a token being created and it spawning an item. This way, the event triggered source can react to the token being created and move an item over immediately, so it (hopefully) arrives before it is needed.

test110_fm.fsm

0 ·

1657534478694.png (30.5 KiB)

1657534654385.png (11.3 KiB)

1657535113929.png (36.4 KiB)

1657535128429.png (15.9 KiB)

test50-fm2.fsm (70.2 KiB)

test110-fm.fsm (67.0 KiB)

question