A queue takes in material and holds it until it can be dispatched for processing, typically to an oven or a capacity limited conveyor. The behavior of the queue is controlled from the Equation Tabsection of the properties panel, and also from the settings and connection priorities of inflows and outflows.
The basic unit of operation for queue is a batch. This consists of the amount of material delivered by a flow in a single DT. For example, if DT is 1/4 and the flow has a value of 8, then a batch of 2 units will be delivered into the queue (this need not be a whole number; for example, batches of 0.25 units are also possible). If there are multiple inflows into a queue, each nonzero inflow will deliver a batch. The highest priority inflow (normally the one connected first) will deliver the first batch, the next one the second batch and so on during the single DT.
In the normal mode of operation the batches are released in the order they are added as described below. The downstream stocks determine how the material is dispatched. Specifically, for Ovens and Conveyors you can specify whether you want to allow batches to be split so that part of a batch can be accepted, and whether you want to allow multiple batches to be accepted so that more material can be taken in a single DT.
A queue is never inflow constrained, so it will always take whatever material the flows provide. Normally the material is first come first served, based on time and, within a single DT, the order in which the flows have been connected.
You can override this default acceptance of material by indicating on the queue that you want to prioritize inflows based on their attribute values, where a lower attribute value means a higher priority (1st, 2nd and so on though the numbers need not be integers).
In this case any batch with an attribute value will be placed on the queue just behind last batch with an attribute value less than or equal to that of the incoming batch (and always in front of any batches with no attribute values). The attribute values are set on inflows either directly going into the queue, or earlier upstream (for example, a flow going into a conveyor that then has a flow going into the queue). See Flow options for the mechanics of setting attribute values.
Even though queues does not mix quantities from different inflows, because they can accept material from other stocks, a single batch might include material originating at different times and with different attribute values. When the attribute value is used to put a batch earlier in the queue, only the portion of the batch with the higher priority will be moved ahead. In this case the batch will be split into more than one part based on the attribute values of the different parts in the batch. Again, this can only happen if the inflow has an upstream stock and the attribute values were set prior to the material reaching that stock. If the attribute value is set directly before the queue, the entire batch will have that attribute value.
Once a batch is in the queue, its attribute values will not change. Additional batches may be placed ahead of it when they are placed into the queue based on their attribute values, but there will never be any reordering of material already in the queue.
A queue releases batches through its outflows. The process for releasing material looks at the outflows in sequence determining how much, if any, material can be released through that outflow. For example, if the outflows goes to an oven, the oven can accept material only if it is not cooking and not paused. There may also be restrictions on how much material the oven can accept.
Within a DT, outflows are checked in turn. The sequence in which they are checked depends on whether the priority and round robin option for a queue has been set as described below. The determination of a flow is based on the material in the queue and the downstream stock the flow is connected to:
It is possible to restrict outflows to only process material with specific attributes using the Restrict by Attribute option in Equation Tab. In this case when an outflow is processed only batches (or parts of batches as described below) matching the list of attributes specified will be dispatched. For example, If material is coming in with attributes 1, 2, and 3 then we might have an outflow that will take only attributes 1,2. Nothing in the queue with attribute 3 will be processed be the outflow.
In the about example, if there were only 1 outflow, then everything with attribute 3 would simply pile up in the queue. If there were another outflow that could process say 2,3 then the first outflow would get all the 1 attribute material, the second all the 3 attribute material and they would share the 2 attribute material.
If you add an outflow that does not have Restrict by Attribute specified (that is an empty equation) it will process material that won't be processed by any outflow with Restrict by Attribute specified. In the above example it would process material that does not have attribute value 1,2, or 3. It would, for example, process anything with an attribute of 4 or 5, or anything that does not have an attribute value set. If only attributes 1,2, and 3 are used, and everything always has an attribute, this added outflow would always be 0.
Note If you set an outflow to be purging it will purge material with any attribute value.
Controlling queue outflows by attribute allows you to use common processing flows at early phases, but then place them into specific paths for other activities. For example, suppose you used 1,2,3 for red, green, blue. Then you might have separate paint stations for each of the colors, but the rest of the assembly and distribution chain might be identical. Material could be queued after early assembly, sent off for the appropriate painting, released back into final assembly.
Normally, batches of material are accepted and dispatched intact. Hoverer, there are things that will cause batches to be either split apart or combined.
A queue will split a batch of material if:
A queue will combine multiple batches of material is:
If the queue outflow goes to a stock, non-negative stock, or cloud the batch concept is discarded as only the total amount of the outflow is tracked.
By default, the sequence for the outflows from a queue is determined by the order in which they were attached to the queue, and is reported in the Options section for the flow:
The first outflow attached will show outflow priority 1 and will be processed first , the second outflow priority 2, and so on. The only exception to this is for flows into ovens that have already started filling, but not yet started cooking. Flows into these ovens will be processed first, so that ovens do not start filling, then pause while other ovens are filling.
If you check the Use dispatch priorities and round robin selection option on the queue (or any of its outflows) the dispatch priorities speechified for the outflows will determine the order the flows are processed.
The flow with the smallest dispatch priority will be processed first, then the next highest second and so on. If two flows have the same dispatch priority then the order they are processed will first be determined by the order in which they were connected to the queue. Once a flow has been positive, it will be moved to the bottom of the sequence, so that the flows with the same dispatch priority will rotate (round robin) the dispatching of material.
If all flows have the same dispatch priority checking this option will simply set up round robin dispatching.
The dispatch priorities can be expression and can change over time so that you can set up the sequencing for flows directly in the model (with the caveat that ovens that have begun to fill will continue to fill). Unlike changes to attributes which only effect batch management on entry to the queue, dispatch priorities have an immediate effect on the distribution of material coming out of a queue.
An overflow is a flow that will only be processed if none of the flows preceding it have removed material from the queue because the batch is too big to be processed, or the downstream stock is arrested. Overflows, thus, prevent deadlock. For example is a queue had an outflow into two ovens one with capacity 5 and one with capacity 10, and the capacity 10 oven was arrested, then a batch of size 10 would block the queue until the larger oven was no longer arrested, even though the smaller oven is idle. The overflow would take the batch of size 10, allowing processing to continue with later batches.
You can set the second and subsequent outflows attached to a queue to be an overflow. As long as at least one of the prior flows processes material (or if connected to an oven that is currently processing a batch of material), an overflow will always be 0.
If you want to combine an overflow with dispatch priorities the dispatch priority for the overflow should be set high, so it is always the last flow to be processed.
If you are restricting outflow from a queue based on the attribute, the overflow will only act on attributes it is specified as processing, or on the complement of all specified attributes if this is left empty for the overflow. Generally, if you want to use an overflow in with restriction by attribute you should include all possible attribute values in the overflow restriction.
An overflow will normally flow to a queue or other stock that is not capacity constrained.
If the quantity of material in a queue builds up the residence time of the material may grow. It is often useful to pull out material that has been in the queue too long whether it be to deal with spoilage of perishable items or redirection to alternative support processes for service demands. This is done by selecting the Purge old entries option on a queue outflow.
Material must be stamped at the inflow or further upstream so that the age of the material is known:
Purging of material is based on the maximum age of material in a batch (again batches may have been combined in upstream stocks). If the maximum age of material in a batch exceeds the specified age for purging the entire batch will be processed by the flow.
A purging flow should normally connect to a queue or other stock that is not capacity constrained (or a cloud). There would also normally be only one flow marked as purging. When a flow marked as purging connects to another queue, multiple batches of material may be processed. This is different from the normal queue to queue connections in which a single batch of material is passed across.
Attribute and age information on batches is maintained in queues, conveyors and ovens. When material passes to a non negative stock this information is discarded.
If you want to track information passing through non-negative stocks select Cycle Time as the simulation method on the Model Settings Properties Panel. When you select this all non-negative stocks will be computed the same way that queues are computed as far as accepting batches and maintaining information about them. This allows attribute and time stamp information to be retained throughout the chain of activities in your model. Since outflows from non-negative stocks are based on computations splitting and combining batches of material is assumed to be allowed.
When determining how much material can be dispatched from the queue, it is normal to allow anything that is flowing into the queue to be dispatched immediately. Such a queue is called a pass-thru queue. Clearly, this means that the value of the outflows may depend on the value of the inflows. This is only possible if the values of the inflows do not depend, directly or indirectly, on the values of the outflows.
If the inflows depend on the outflows, a queue will be treated as non-pass-thru. Visually, you can recognize a non-passthru queue because the last gate displayed will be closed as in:
Material will not pass completely through the queue within a DT. The outflows will be processed assuming that all the inflows are 0, and then the inflows will be processed. A consequence of this is that the queue may have material in it, even though there is capacity to process that material. This effectively builds a 1 DT delay into the queue.
Note that the same thing happens with non-negative stocks. In this case the lack of pass-thru is denoted by a double bar ||.
