Hi, I'm having trouble applying the information from the tutorial to "real" cases.
I tried to implement the "Water Break" in the model I'm making, trying to integrate the information from the tutorial.
In my model I used lists instead of resources, but currently I can't make it start "Water Break" based on the distance traveled.
In the process flow I loaded, the logic I tried to implement is in the Water Breaks container.
Hi @Pietro Turrin, was my answer helpful? If so, please click the "Accept" button at the bottom of the answer. Or if you still have questions, add a comment and we'll continue the conversation.
If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always comment back to reopen your question.
Hey @Pietro Turrin, in the first part of the tutorial, the Process Flow is set up to acquire an Operator and then release it after all the Task Sequence activities. In your model, the Operators are pulled from the list, but they are never pushed back to the list, so the Water Breaks section never has a chance to pull the Operators when they fulfill the query with the travel distance.
The solution is to push the Operators back onto the list when you want them to check for if they are supposed to go on a water break or not. You could add a Push to List activity after the "Run Sub Flow: Unloading" activity. If you decide to do it there, you'll want to use the Max Wait Timer and the "Keep On List On Early Release" option. And the tokens will need to be looped back to the "Pull Operator" activity. It would look something like this:
Thank you for the answer. I understood the logic and my error, but i did not understand why i need too "Use Max Wait Timer Fired". Using it it cause an error and the "OperatorGrey" stop working.
@Pietro Turrin, you need to use the Max Wait Timer so the token will advance/loop back to the top of the block of activities and try to pull an Operator and continue the work. If you didn't use it, the token would stay on the Push to List activity indefinitely and the work would stop.
The reason there is an error is because the Push Value in the Push Operator activity needs to be token.Operator, not just token. Also, the OperatorGrey Operators need to have the lastDrinkTotalTravel label added to them (and the Automatically Reset option used) in order for the logic in Water Breaks to work.
I also realized when the Pull from List activity in Water Breaks does pull an Operator, there is nothing in the Operator Tasks logic to prevent that Operator from being pulled again. So I adjusted the model a little to fix this, along with the other fixes, and I am including the modified model here (tu0-comb-v4-break_FS1.fsm).
The biggest change was to have an initial Pull Operator activity that pulls the Operators when the model first starts. Then, in the big block of activities in Operator Tasks, there is another Pull Operator activity that only pulls a specific Operator (as part of the Query/Object/Array field). This way, when an Operator is pulled out because of the Water Breaks logic, it won't be accessible in the Operator Tasks logic until it finishes the water break.
12 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.
