question

Mike Mayer avatar image
0 Likes"
Mike Mayer asked Mike Mayer commented

Force items to wait in a queue for a predetermined amount of time

I need to hold each flowitem inside a queue for at least 10 time units then be released after that (or be put next-in-line to be released if there’s other older items still waiting ahead of it).

This would be for simulating things that need time to dry, cure, cool down, or simply age for whatever reason before moving onto the next manufacturing step. There is no batching - each individual item accumulates its own "age" inside the queue and is independently released from the queue after reaching 10.

As the flowitems arrive into the queue, they can stack-up in rows and columns as usual while waiting until they reach 10 time units old. The default visual of them gathering in the queue as usual is desired since it easily shows how much of something is still waiting in the queue to finish drying, curing, cooling, etc.

This is why using a processor with process time 10 and capacity 999999 won't work because all the items will accumulate in one spot - you won't see them spread out like in a large queuing area.

I figured an easy way to do this would be via connectionless routing using an Item List as the handoff mechanism between queue and processor.

How to do this is described in Help > User Manual > Contents tab > Connecting 3D Object Flows > Lists > Working With Lists > then scroll down to Pushing and Pulling Flow Items to a List.

It describes in the Flow tab how to push an item to a list from one FR object (a queue in my case), then how to pull from the same list in the downstream FR object (like a processor).

The two attached small models are exactly the same except for the direction of the comparative operator in Processor1’s properties > Flow > Input > Pull Strategy > Query field.

In both, you can see the Item List’s entries as they show up in the list after they are pushed there from Queue1.

In “pull_from_list_age_less-than_10.fsm” the Processor1's Pull Strategy Query field uses the default FlexSim query “WHERE age < 10”. Thus only items less than age of 10 are pulled from the list. After you run it for a couple hundred time units, you can see that indeed items with age over 10 are left in the list never to be pulled (because of the 10 unit process time of the processor causing them to back-up inside the queue and age past 10 units). While “fresh” incoming items not yet 10 units old, are pulled from the list right away.

So all that seems to work as you would expect – only “younger” items under 10 are being pulled based on that query.

What I want pulled are only items over 10.

In “pull_from_list_age_greater-than_10.fsm” the only difference is that the Query has the comparative operator changed from < (less than) to > (greater than), which I was expecting would force any item over 10 units old to get pulled (or at least be put on-deck to be released). However, as it runs on my system, nothing gets pulled and all the brown boxes pile up in Queue1. Nothing goes into the processor.

Seems using lists and a WHERE query would be a straightforward way to force aging of items in a queue, but I must be doing something wrong. This is FlexSim 19.0.3.

Thanks.

Mike Mayer

FlexSim 19.0.3
queuelistdwell time
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

1 Answer

Matthew Gillespie avatar image
0 Likes"
Matthew Gillespie answered Mike Mayer commented

What you're running into is that it's a little more complicated to use lists with queries that involved dynamic fields. This is because the query is only run at certain times:

  1. When a value is pushed on the list (age = 0 in this case)
  2. When the puller tries to pull from the list

There are certain things you can do to increase the number of times the query is run:

  1. Check the Reevaluate All Values on Push checkbox on the Back Orders tab of the List Properties (this will cause the query to be evaluated every time something new is pushed to the list) this will give the back orders more chances to realize that there are older items on the list, but you'll still have some delay times.
  2. Add a Back Order Reevaluation event on the Back Orders tab of the List Properties. This lets you tell the list to reevaluate queries when some event happens. The simplest one (though worst for performance) is to use a Time Interval event to reevaluate the queries every so many time units.

However, I would recommend taking a different approach. Take a look at this answer. In that model I used an instance Process Flow to customize the behavior of a queue so that it holds items for a certain amount of time before releasing them.

· 3
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Mike Mayer avatar image Mike Mayer commented ·

Thank you Matt.

A colleague and I looked at Reevaluate All Values on Push too, and discovered items that need to "sit" in a queue arrive infrequently enough that they were not getting pulled soon enough after the wait time was met. In other words, things were sitting around in the queue ageing too long. Back Order Reevaluation with a time interval is interesting - we may give that a go.

We looked at your recommended Process Flow solution, and came up with a similar version using a bit of FlexScript in Queue1's On Entry trigger and a short Process Flow for the delay - see attached model "queue_delay_using_PF_tokens.fsm"

It seems to do the trick, similar to how your example does. Bear in mind that our wait time is "1440" to simulate 24 hours worth of minutes, however the model is in seconds so it's technically only 24 minutes of simulation time - but the idea still works (our actual larger model is in minutes).

Brown boxes will pile up in Queue1 until 1440 simulation time then they'll start moving along the conveyor. What's nice is that nothing sits in Queue1 for MORE than 1440 (everything's moved to Conveyor1 in 0 time as soon as it's ready) - unless Conveyor1 happens to be either full, or a box just happens to be entering the conveyor when another reaches 1440 and may have to wait a few more simulation "ticks" for the one ahead of it to move down the conveyor a bit to make room. For our purposes that's OK.

To get boxes to go to the Conveyor1 properly, in Queue1's Flow tab we have it set for "Do Not Release Item" but made an output connection anyway from Queue1 to Conveyor1 in order to force the little white "EntryTransfer1" to be created at that end of Conveyor1. This is what we used for the Destination inside the "Move Item To Conveyor" activity. If we just made that Destination to be Conveyor1 (with no entry transfer and no connections) we found that brown boxes would just pile-up at that end of the conveyor and not move.

It all works very nicely now.

May I please turn this into a "suggestion box" item for a future enhancement to the basic Queue? That is, a new check-box for a "Dwell" or "Wait" time option, perhaps between the Batching (or combined with it), and Visual dialogs. With a field for how long you want each item to sit in the queue. It would be set up very much like specifying a Process Time in a processor.

queue-delay-using-pf-tokens.fsm

0 Likes 0 ·
Matthew Gillespie avatar image Matthew Gillespie ♦♦ Mike Mayer commented ·

I would recommend updating your solution to use an instanced process flow that way you don't need any custom code, it simplifies the process flow, and it scales much better since you can just create copies of the queue or attach more queues to the flow.

restqueue.fsm

If you'd like to make a feature request please create an Idea on this site (like this one) laying out your idea and then send an email to [email protected] with a link to the idea page. Ideas let other users on this site vote on issues and are a good place to have discussion between members of the community and developers.

0 Likes 0 ·
restqueue.fsm (36.1 KiB)
Mike Mayer avatar image Mike Mayer commented ·

Thanks again Matt.

Will do on the suggestion box item.

Very clever isolating the logic to be 100% PF. We'll use that!

Mike

0 Likes 0 ·