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.