AGV task logic with several decisions

Question

question

Fred E asked Jul 07 2022 at 8:45 PM Felix Möhlmann commented Jul 11 2022 at 10:26 AM

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)

______

Cookie preferences

Your privacy is important to us and so is an optimal experience. To help us customize information and build applications, we collect data about your use of this site.

May we collect and use your data?

Learn more about the Third Party Services we use and our Privacy Statement.

Strictly necessary – required for our site to work and to provide services to you

These cookies allow us to record your preferences or login information, respond to your requests or fulfill items in your shopping cart.

YES

Improve your experience – allows us to show you what is relevant to you

These cookies enable us to provide enhanced functionality and personalization. They may be set by us or by third party providers whose services we use to deliver information and experiences tailored to you. If you do not allow these cookies, some or all of these services may not be available for you.

YES

NO

Customize your advertising – permits us to offer targeted advertising to you

These cookies collect data about you based on your activities and interests in order to show you relevant ads and to track effectiveness. By collecting this data, the ads you see will be more tailored to your interests. If you do not allow these cookies, you will experience less targeted advertising.

YES

NO

Are you sure you want a less customized experience?

We can access your data only if you select "yes" for the categories on the previous screen. This lets us tailor our marketing so that it's more relevant for you. You can change your settings at any time by visiting our privacy statement

Your experience. Your choice.

We care about your privacy. The data we collect helps us understand how you use our products, what information you might be interested in, and what we can improve to make your engagement with Autodesk more rewarding.

May we collect and use your data to tailor your experience?

Explore the benefits of a customized experience by managing your privacy settings for this site or visit our Privacy Statement to learn more about your options.

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

Felix Möhlmann answered Jul 08 2022 at 7:31 AM Felix Möhlmann commented Jul 11 2022 at 10:26 AM

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

Fred E commented · Jul 11 2022 at 8: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