question

Hi @Travis P3,

I can think of two ways that could be effective. The first would be establishing priorities in the queues so that the operator receiving task sequences will be able to sort those tasks by a priority value. Higher priority values mean that the operator will attempt to perform those tasks first.

A second option (and how I would probably do it) is by using Process Flow. You have great control over the operator in Process Flow. There's a number of routes you could go. For example, using batches to collect items, decide loops to check availability of items in each queue, etc. The way I did it in this example was to have the queues push to an item list with different partitions depending on which queue it is.

Then in Process Flow, I have a token that Acquires Operator1 and then proceeds to check each partition of the list (in order) to see what items are available. For example, if an item in Partition 1 is available, the token will send Operator1 to load the item in Queue1 and unload it at ShovePress. If the Pull from List activity fails (meaning there is not an item there in that queue), then the token will go to the next Pull from List activity to check that partition. The Delay activity at the end is just a breathe for the model so it doesn't get caught in a loop.

You should be able to work with this and modify it to your needs, but it may depend on your model parameters. Let me know if you have further questions or concerns about this.

(Note: I updated your Network Nodes because it looked like you were trying to implement those as well.)

rotor-cell-updated.fsm