I have a problem in the attached model; a token stuck in "Push to List" activity (may be because the push value is not correct) resulting on the stuck tokens in the "Acquire OPMP" activity (figure).
Would you please help me to fix this?
Answer by tannerp ·
I understand your logic, but there are some events that we need to change. The biggest issue is that no matter what you push to the list in the Process Flow activity, that token still has the acquired resource. This means that the other tokens cannot acquire a resource.
If the tokens at the Acquire activity can't acquire a resource, they can't pull from the list. If they can't pull from the list, then the token at the Push to List activity can't progress. If the token at the Push to List activity can't progress, it can't release the resource. If the resource isn't released, the tokens at the Acquire resource can't progress.
Essentially, the model is in deadlock. We need to change three things:
1) The Release resource activity needs to happen before the Push to List.
2) The Push to List value should be token.EmptyCUTotes or token.CUTote (it shouldn't matter too much because it points to the same item).
3) The Partition ID needs to be the same for all tokens. Some have "None" and some have "0" in the model. You'll have to decide what you'd like to do for a Partition ID. If you can't sort this out, I recommend changing the logic to move the items out of Rack15 and then back in. This way, the items are re-evaluated properly according to their SC values. I've included a second version that you can try out.
I also just realized that the "CUtote arrives to rack" activity already has a reference to the CUTote, so pulling one of the CUtotes from the list with a token that already references one of the CUtotes seems really redundant to me. I'm not sure I would set up the Process Flow just like this, but rather use a single token that handles all the logic.
Hope this helps! Let me know if this model works.
First version: trying1 (6)_1.fsm
Second version: trying1 (6)_2.fsm