question

C avatar image
0 Likes"
C asked Felix Möhlmann commented

Why are Task Executers travelling empty?

Hi there. There are two stations, lots of boxes, task executers(TEs), and timetables for TEs to leave these stations loaded with 1 box. Timetables are arranged so that if the runtime is less than14 hours there should be 4 TEs should carry boxes, and if it is more than 14 hours there should be 3TEs carrying boxes.

TEs should never travel empty. However, they seem to carry two boxes sometimes and always travel empty.

I would be so happy if you could state what is wrong with my model.


FlexSim İzmir Deneme_3_Virtual_Distances_autosave.fsm

FlexSim 19.0.0
travel empty#travel
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 Felix Möhlmann commented

The "Acquire" activities in your model can currently acquire any of the TEs, regardless of their current location. If they get pulled by the wrong token, they travel empty to load the item at the other queue.

I added a label "Loc" to the TEs. After they unload an item, this label gets set to their current location ("UCK" or "BOS"). The added query in the "Acquire" activities, makes sure only TEs that are currently at the location can be assigned.

flexsim-izmir-deneme-3-virtual-distances-fm.fsm


· 3
5 |100000

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

C avatar image C commented ·

Thank you. It seems to work until I introduce "Load" and "Unload" times to TEs. Unload times are shown but Loading seems to be instant.

flexsim-izmir-deneme-3-virtual-distances-fm.fsm

0 Likes 0 ·
C avatar image C commented ·

I tried to duplicate the General Process Flow that you modified to make TEs carry boxes between other queues and sinks. However, after the sim time hits 07:45, it simply crashes the sim. Please find it attached. flexsim-izmir-deneme-3-virtual-distances-fm.fsm

I tried to make different lists but it didn't work.


Do you think it is logical to use different types of items so that their specific source and destination can be set? For example; "item.type = 1" means its destination is BOS to KSK. 2 means BOS to ALS, 3 means BOS to PAS, 9 means KSK to BOS and so on.

Or to use item.type 1 means that the destination of that item is BOS, regardless of the source?

0 Likes 0 ·
Felix Möhlmann avatar image Felix Möhlmann C commented ·

"Unload times are shown but Loading seems to be instant."

This is a bug with the setting "Use navigator for offset travel" in the version you are using (and some subsequent ones, I think). To get around it, you can either use set them to "Do not travel offsets for load/unload tasks", but you will need to add travel activities (at least in front of the unload, since they don't have to travel to the loading position). Alternatively, you could set the times on the task executers to 0 and instead use "task - delay" activities to keep them in the corresponding state for the needed time.

1633418350284.png

The other problem results from pushing the items to multiple lists. This means two TEs can pull the same item. The model stops and crashes because a TE is trying to unload an item which doesn't exist anymore, since it was already delivered by another TE.

The fix for this connects to your last question. I would suggest to only use one list per queue. The item type determines the destination by defining the partition the item is pushed to. The "Pull from List" activities are then set to only pull from the correct partition depending on the travel destination of the flow they belong to.

You other idea would of course also work but would be slightly more complicated to set up, since the partition to pull from would depend not just on the destination but also the source. If you want to store the source location for analysis, I'd simply create an extra label in the sources for this.

flexsim-izmir-deneme-3-virtual-distances-fm2.fsm

0 Likes 0 ·