Order the list in ascending order by Rank Value

Question

question

Raashid Mohammed asked May 19, '16 Ben Wilson edited May 20, '16

Order the list in ascending order by Rank Value

I have a 3 Racks R1, R2 and R3.

I am creating boxes using process flow with random rank from 1 to 3, then pushing it to the list.

Now I want the list to be in an ascending order by Rank value before its pulled.

Then process flow pulls only the top 20 items from the list, which should have Ranks in sequence, to be stored by a transporter on a rack.

But the pull item list does not sort it in ascending order and token pulls first 20 items from the list which have random ranks.

The reason I am doing this is the transporter with multiple items can only stow on racks only in one direction.

Please help.

I attached the mode.

Software Version:

FlexSim 16.0.1

process flow query lists list sorting

pitmodel05-19-2016.fsm (54.3 KiB)

Answer 1 · 2016-05-20T13:56:35Z

Matthew Gillespie answered May 20, '16 Ben Wilson commented May 20, '16

The way to do this is to use an ORDER BY in the Query field of the Pull From List activity. Looking at your model I can see that you're already doing this with ORDER BY Rank ASC as your query.

Why it's not working

The Pull from List activity tries to pull before there are any items on the list and so it creates a back order on the list and will wait until it is fulfilled. As each item arrives at the Start queue it is pushed on the list and immediately grabbed by the back order. If you look at the back orders for the list (the View Back Orders... button on the List properties) you'll see that as each item arrives the fulfilled column increments. Thus, you're getting the first 20 items in the order they arrived.

Solutions

All or Nothing

Checking the All or Nothing checkbox on the Pull from List will stop the backorder from pulling each item as it arrives and instead will wait until there are at least 20 before sorting and pulling. If you look at the entries and back orders on the list you'll see that as each item arrives it is now added as an entry on the list instead of incrementing the fulfill column of the backorder. Now you're getting the first 20 items ordered by rank.

Pull after items arrive

If you, for example, change the arrival time on your 2 Schedule Sources to be 1 instead of 0 then those tokens won't try to pull from the list until the list contains all the items to choose from. You'll see that the transporters now get a sorted list. Now you're getting the 20 lowest ranked items ordered by rank.

· 2

Matthew Gillespie ♦♦ commented · May 20, 2016 at 03:49 PM

Note: with these solutions you'll no longer need your Sort queue since the Pull from List and its ORDER BY query do all the sorting required.

1 ·

Raashid Mohammed commented · May 20, 2016 at 04:21 PM

Thank you Ben and Mathew

This is very helpful

1 ·

Answer 2 · 2016-05-20T13:52:13Z

Ben Wilson answered May 20, '16 Ben Wilson edited May 20, '16

What's going wrong

Your queue named Sort is pulling items in the order of creation, because it pulls each item from the Start queue individually the moment that item is created. In this manner it isn't able to take advantage of any sorting, since there is never more than a single item to sort.

For the pull to be able to take advantage of ranking all of the items after the items have all been added to the model, you would need to create some custom logic that prevented the Sort queue from pulling until all the items had been added to the list.

There isn't really a good reason to dive into doing all that custom code when there is a much easier way to sort built right into the queue itself.

An easier way

The easiest option is to add an On Entry trigger to your Sort queue to sort the incoming items. This option is found by pressing the green "add trigger" button next to the queue's On Entry trigger, then choose Control > Sort By Expression. Choose ascending order based on the Rank label.

Visualize it

In order to visualize what is going on, I've also added a set color option to the On Entry trigger that colors the items red, with the brightness related to the value of the Rank label. This will allow you to visually see the sorting based on a color gradient. Just for fun.

Simplify the model

Doing the sorting in the On Entry trigger makes the Sort queue and its pull completely redundant, assuming you were just using it to pull in ascending rank order. Now that the sorting is being done instead with an On Entry trigger, you could probably add this On Entry behavior to the Start queue and completely remove the Sort queue.

See a sample in action

Attached is your sample model modified by putting the On Entry logic described above into the Sort queue. I also broke apart your process flow Sources from the next Acquires so that the model would stop just after all the items make it into the Sort queue, so you can see the On Entry behavior in action.

triggeraddbutton.png (587 B)

pitmodel05-20-2016.fsm (54.6 KiB)

· 1

Ben Wilson ♦♦ commented · May 20, 2016 at 02:26 PM

The above explains the sorting not working between the Start and Sort queues. See Matthew's answer for loading the transporters in the correct order from the process flow, which upon further examination is probably what you were looking to do in the first place :)

1 ·

Answer 3 · 2016-05-20T16:34:58Z

anthony.johnson answered May 20, '16 anthony.johnson edited May 20, '16

My vote is for Matthew's answer (sorry Ben, you already have enough badges :-)), although I would add one thing. In some cases it doesn't work to pull all or nothing, e.g. if you want to get whatever's there, whether or not it's the full requested 20 items. In this case, the way to do it would be, instead of just pulling from the list, you first use a wait for event to wait for something to be pushed onto the list, and then delay for 0 seconds to allow all the remaining items to be pushed onto the list (I usually call this "breathing"), then pull from the list.

I implemented this in your model (pitmodel-breathe.fsm). The tricky thing is that when you have multiple tokens pulling from the list, you get a problem where each token listens for the push, then one gets fulfilled, and the other gets into the pull from list but doesn't get fulfilled, so you are back where you started. To get around this, I put a mutex resource around the wait-breathe-pull sequence, so that only one token gets to wait-breathe-pull at a time.

We have an item on our development request list that will make all this easier: it is a checkbox in the list's properties that would be something like Fulfill back orders independent from pushes. This will make it so when something is pushed onto the list, the list itself will "breathe" before fulfilling any back orders. This will allow multiple values to be pushed onto the list BEFORE fulfilling back orders, as long as they are all pushed at the same simulation time.

pitmodel-breathe.fsm (59.3 KiB)

question