I have a model where I load entities into containers using transfer stations. These containers rotate in the flow, so they never enter a drain and disappear.
I have a problem where the transfer station is sending away an empty container when it should load the container. Upon further debugging, I am seeing that the transfer station's internal exit controls are treating the empty container as one that should not be loaded again (hence it exists in the "ReadyTargets" list).
I am wondering what the purpose of this ReadyTargets list is so I can see if this behavior is a modeling mistake on my side or if I am misunderstanding how the Transfer station works according to my needs.
My transfer station is set up to Load all blocks from a buffer (containing entities) onto a container. The transfer station is set to always stop the container on the target station, and is also set to "Homogenous Loading".
See the attached images for clarification.
Solved! Go to Solution.
when the target at the targetStation is loaded and cannot leave the targetStation, it is inserted in the ReadyTargets list to avoid trying a second load. When it leaves the targetStation it will be removed from this list again.
How can the target be empty on the targetStation and in this list? The only possibility is that the target was moved from the targetStation without informing the transferStation. When the transferStation will be configured then a targetExitControl will be inserted at the targetStation. Exists this control at the object LoadLargeBin? What is the content of the method "ExitCtrl"?
Hello, thank you for the reply.
I am suspecting the same thing you are - that the container is moved without telling the TransferStation of this move. I had a similar issue like this earlier but thought I managed to solve it but maybe it is still present.
The method with the breakpoint active is the "LoadLargeBin" targetExitControl like you mentioned, this is the one the Transferstation has created itself. When clicking "Continue" in the debugger where the breakpoint is active in the screenshot, I am brought to the user defined "ExitCtrl".
The bottom method "ExitCtrl" is the user defined exit control method for "LoadLargeBin", which is also defined in the TransferStation. This field was automatically populated in the TransferStation.
Maybe it is relevant - the singleproc "LoadLargeBin" has an exit strategy "Carry Part Away". Line 12 in the user defined "ExitCtrl" will trigger an operator to come pick up the container on "LoadLargeBin" via an external workplace.
attached you will find a little model with a transferStation with exitCtrl and carry part away the loaded container. Perhaps you can modify this model to show the problem. Without a model it is impossible to find what goes wrong.
Anyway, when the full container leaves the targetStation, so when the operator arrives at the LoadLargeBin and picks the container, then the method TransferStation.exitTargetStation must be called to remove the container from the ReadyTargetsList.
I think the difference between our models is that your SingleProc has "Exit Control only once" unchecked, while my model requires the same attribute on "LoadLargeBin" to be checked. When the worker comes to pick the container up in my model, the exit control should only run once but perhaps the TransferStation requires it to be run more than once in order to remove the MU from the ReadyTargetsList? In this case I have to re-think my logic for exit controls in this model when using TransferStations.
When i put a check in the checkbox for "Exit Control Only Once" in "LoadLargeBin", the worker is called to the station but does not move the part to the worker, he is instead immediately released (due to my waituntil-statement preventing the "@.move" on line 12). This part needs re-thinking since i "book" transports to other stations so several workers don't risk wanting to go to the same workplaces at the same times, and I always wait until no one else is on their way to a station I want my worker to go to (pseudocode: waituntil [...] not booked).
A question for a workaround: Is there a way in SimTalk to check if a specific method has called the method that is currently being executed? In this case I could skip the waituntil-statement on line 10 if i detect that the Transferstation executed my user defined "ExitCtrl" method, and therefore successfully move the container to the worker, which should finally let the TransferStation continue its code to remove the container from its "ReadyTargets" list.
By the way -- checking "Exit Control Only Once" in your example model gives the same symptoms of an empty container leaving the station.
Thank you for the help.
yes, you are right; it is essential for a working TransferStation, that the "exit control once" is unchecked.
perhaps you can use the ? for your exit control. It should be the caller of the method.
? does not work, it is set to the SingleProc "LoadLargeBin" and not the TransferStation unfortunately.
However I managed to solve it in a simple way, by just adding a new dummy SingleProc for picking the filled container. "LoadLargeBin" is now exclusive to the TransferStation, and the user-defined ExitCtrl + Carry Part Away exit strategy are now placed on the dummy.