In the attached model a turquoise item arrives at the rack at time 143.60 (Type 10), dwells for 1 sec, then is pushed to a list partitioned by Type. A turquoise token in the process flow pulls the item and then releases it using releaseitem(item,1), the item is selected red in the same code. Unfortunately the ASRS transports a purple item next, which is still on the list. How can this be?
I replaced the Rack with a Queue in the attached model, and was surprised to see that the issue still persisted (the unreleased purple item was transported instead of the turquoise released via command). However this told me that the Rack is likely not the problem. So then I tried increasing the "Max Transports in Transit" to 2 on the EntryTransfer of the downstream conveyor and found that items were transported in the sequence they were released (fixed)... UNTIL time 432.57 when the quantity of outstanding released items reached 3, the third being lime Type 7. At time 540 when it was time to transport the lime item, the ASRS loaded the purple item instead (rank 1 in the Queue), an item what had still not been released. Broken.
So I guess the question now is: How does exceeding the "Max Transports in Transit" quantity cause upstream items to be released (or at least transported) before other items that I assume have outstanding move requests?
I changed the return value of the Send to Port "Push to Item List" pick option to -1, now the model works as expected. Only items that have been released are transported. WHEN and HOW a given item is transported is governed by the availability of resources and default port connection logic. Which is great, because it saves the user a lot of work involving some more challenging concepts. This is a common system of pulling inventory based on orders.
Now I ask: How does the FlexSim interpret these return values differently? (-1 vs a non-valid port) Should this pick option be changed to return -1?
If you are returning an invalid port, then the item is still being released, just not immediately released to a specific downstream object through a specific port.
That picklist is designed to be used in conjunction with the downstream object's Pull From List in the Pull Strategy field. That doesn't call releaseitem(), it calls pullitem() or pushitem().
The item has already been released. You shouldn't call releaseitem() again.
You should only call releaseitem() again on items that returned -1 (do not release item) in the Send To Port.
So what was happening is that there was a mismatch of the "Type" label between your tokens and your items being pushed to the list. So when it pulled from the list, the token wouldn't match the item you wanted to pull, so it would wait till there was an item of that Type available. In the file I uploaded I have a token created when your item is created with a matching Type label, so you will see it begins pulling in order of what was placed in the rack. Tokens are also now colored coded to match the item. See if the modified model is what you are looking for.
I am not sure what mismatch you are referring to. In the original model the yellow item and token are both Type 4, and the turquoise item and token are both Type 10. Purple is Type 6.
I do not wish to pull the items in the sequence they arrive. I believe you created a new model that avoided the issue I presented.
11 People are following this question.
FlexSim can help you understand and improve any system or process. Transform your existing data into accurate predictions.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
