question

The thing that can be challenging about wanting to do a "first available" style routing on branching conveyors is figuring out what makes a conveyor segment "unavailable" for your particular problem. Take a look at the attached model for an example of how you might use a List to manage this kind of routing problem.

first-available-segment.fsm

This model uses a List an event listener activity and a Synchronize activity to manage the "first available" logic for the Red(1), Green(2) and Blue(3) decision points.

The first thing this model does to manage this is implement a List. There are going to be two sets of tokens interacting with the list; one set that represents the destination Decision Points and another that represents the Flowitems in the conveyor system. The Decision Point tokens will be Pushed to the list when they are ready to receive something, and the item tokens will be the Pullers from the list.

The Decision points tokens are created at the very start of the run with references to a Decision Point object in the model and a Rank label that serves as a way of deciding which should be treated as first, second or third choice. They are then Pushed to a list to wait for a Flowitem to arrive and attempt to Pull it. When Decision Point tokens are Pulled, they will Assign a Label to themselves that references the item referenced from the token that Pulled it. This will be used for the Synchronizing step later in the activity flow.

Flowitem tokens are created as they arrive to the Black Decision Point object and are assigned an 'item' label to reference the item in the model. They then have an activity that says to stop their item on the conveyor, but this will only appear to happen when all 3 segments are unavailable. After the stop activity, the items attempt to Pull from the List, using an Ascending ORDER BY query, using the Decision Point tokens' 'Rank' label. This will allow to the first available Decision Point token to be pulled; which ever Decision Points has the lowest numbered rank on the list, will be pulled first.

Once a Flowitem token successfully pulls a Decision Point token, it will restart its item on the conveyor, and send the item to the Decision Point that was pulled from the list. The Flowitem token does a Wait for Event activity that holds the token until the item exits its conveyor segment. This is the event I chose to signify that a segment is in use; as long as something is on the segment it can't receive a new flowitem.

Once the item exits the Conveyor there is a Synchronize activity where the Decision Point token is held while it waits for the item to convey out of its segment. When the Flowitem is released by the segment, the Decision Point token is Pushed onto the List again and the Flowitem token goes to the sink because it is no longer needed.