question

Miguel Pereira avatar image
0 Likes"
Miguel Pereira asked Miguel Pereira commented

Problem in load and unload objects (Bags)

Hey everyone,

I'm having a issue in my project:

the problem is i unload 60 bags from a task executer in a Queue, and so far so good, then i do a cycle where another task executer can only load 15 at a time, so i need it to go there more than one time, this one has to unload the bags in another Queue. And when he do this one time is A ok.

But when he's doing the 2nd time he starts to load the bags that he unload. I mean, imagine Queue1 as the one he loads, and Queue2 the one he unloads, he do the first unload in Queue2, then he moves to Queue1 and he starts to load things that are on Queue2.


I'll leave my project here: Aeroporto.fsm


I do the unload from the Task Executer than unloads the 60 bags (Plane) in the container "Fluxo dos Aviões" then he creates token and push it to a list.

In the container "Fluxo dos AGV" i do the load and unload with the task executer that can only load 15 at a time.

I even tried to do the unload process inside of another sub flow with a new assign label but still not working.


Anyone has an idea how to solve this problem?


Thanks, Miguel Pereira.

FlexSim 21.0.5
processflowtask executersubflowloadunloadqueue load
aeroporto.fsm (2.5 MiB)
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

1 Answer

Eric M avatar image
2 Likes"
Eric M answered Miguel Pereira commented

Hi @Miguel Pereira there were some issues in your model that were causing some problems. The AGVs were loading the items they just unloaded because of the decide activities in the subflow. Rerunning the subflow with the same token meant it would load the same item it just dropped off. Because of the way the DestinoLoad was working, the AGVs were pulling 15 off the list and then pulling 15 more off the list again before ever working on the first 15. I'll explain how I corrected this below.

Instead of setting the DestinoLoad label to 0 and cycling through until you found the queue with the items, I used a trick to make it much easier. Because the items are subnodes of a queue (meaning they're in the queue), you can use the fact that item.up returns a reference to the container (the queue in our case). Now, instead of needing to loop through the queues, you can just use token.GrupodeBagagens[1].up for the travel destination. I needed to change the queue connection from an s-connection to a location reference with the decision point. Then the AGV runs a subflow to load its items. Then travels and uses a subflow to unload the items, and then looks for items to pull from the list again. I did notice that you may want to change the request number to 15 as well so that the last AGV will have items to load (what is happening now is both AGVs take 15 to begin with leaving 30 items on the list. The first AGV then takes 20 items leaving 10 on the list. Because the AGV require 15, the last 10 don't get transported).

One other thing I changed was instead of creating tokens to push to the list, I moved the push to list activity into the subflow and just changed the max wait timer to 0 and checked the "Keep On List..." box. That simplifies things quite a bit.

aeroporto_1.fsm


aeroporto-1.fsm (2.5 MiB)
· 8
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Miguel Pereira avatar image Miguel Pereira commented ·
Hey @Eric M, i understood everything unless the part of the decision point? Is it a A-connection?

And by the way, for future usage, can i use that item.up in a condicional decide? I mean, what does that return?

1 if the item is up and 0 if it's not? or it doesn't work like that?


Thanks a lot for the effort, job and explanation you did Eric!

0 Likes 0 ·
Eric M avatar image Eric M Miguel Pereira commented ·

Yes, the blue connection line is an a-connection. It basically ties the control point to the queue so the AGV can find the location of the queue.

item.up will return a pointer to the item's current container. So in the case of the travel activity, item.up returns the queue /Saida2. And because we connected Saida2 to ControlPoint53, the AGV will travel to the control point. When the item is loaded on the AGV item.up would return a reference to the AGV.

1 Like 1 ·
Miguel Pereira avatar image Miguel Pereira Eric M commented ·
Aight, Thanks!
0 Likes 0 ·
Miguel Pereira avatar image Miguel Pereira commented ·

Also, didn't understood how this loop is working, because the token.GrupodeBagagens[1].up is just on the first travel and in the last one it says travel to a control point... how does it jump the step pull from list on the 2nd "cycle"?

0 Likes 0 ·
Eric M avatar image Eric M Miguel Pereira commented ·

Yes, I only really changed the first Travel activity, the others are how you had them before. This just makes it so the AGV will travel to the queue that the pulled items are in without needing to check every single queue as you were doing before.

When the token is done with the last Travel activity, it will loop back up to the Pull From List activity and repeat the cycle. If there's nothing to pull, the AGV will just wait until there are items to pull.

0 Likes 0 ·
Miguel Pereira avatar image Miguel Pereira Eric M commented ·
Alright but in this case each AGV is going there 2 or 3 times so they're doing a cycle, and they're "ignoring" the step "Pull from list" until the Queue they're loading is empty, i just didn't understand very well how is that working...
0 Likes 0 ·
Show more comments