article

The Area Restriction behavior allows you to build logic for conveyor merging and flow control. When you have multiple merging conveyor lines that should only merge one at a time, you could possibly use Area Restriction to control access to the receiving conveyor line.

See the end of this topic for examples on how to use Area Restriction.

In order to understand how Area Restriction works, you should understand a few key terms, as they are used within FlexSim:

• Restricted Area - An area within the conveyor system that is restricted, meaning items can only pass through the Area under certain conditions. The physical boundaries of the Restricted Area can be defined by the logic you build into Decision Points or Photo Eyes and by where you place the Decision Points or Photo Eyes on the conveyor (e.g. you could use Decision Points or Photo Eyes as entry/acquire points, and as exit/release points). You can restrict access to the Area by limiting the number of items (or slugs if you are using Photo Eyes) that can be inside the Area at a time, or by allowing only one Area Claimer to acquire the Area at a time.
• Area Claimer - If you are using the Acquire Area behavior, you need to define the object that is claiming the Area. The Claimer can be an item, a Decision Point or Photo Eye, or a conveyor. The Claimer defines how other items will be excluded from the Area. If the Claimer is an item, then only the item that has acquired the Area can continue into the Area. If the Claimer is a Decision Point or Photo Eye, then once it acquires the Area, any item passing over that Decision Point or Photo Eye can continue into the Area. If it is a conveyor, then once it aquires the Area, any item on the same conveyor can continue into the Area. In the following image, we show an example of a scenario in which Decision Points are acting as Area Claimer, but keep in mind that there are many other possible types of Claimers.
• Area Owner - A Decision Point or Photo Eye that can determine whether to allow access to an Area Claimer so that the accumulated items can pass through. Typically an Area Owner is downstream on the conveyor object.
• Acquire Area - When the items being held by the Area Claimer are granted exclusive access to pass through an Area.
• Release Area - When all items have finished passing through the restricted Area and the Area returns to the control of the Area Owner.

Area Restriction requires interaction between two or more Decision Points or Photo Eyes. Typically you will associate these objects with each other by creating input/output port connections ('A' connect). The following image illustrates an example of Area Restriction system which merges three different conveyor lines into one. Each merging line has an Area Claimer (in this case, a Decision Point), each of which has output ports connected to a single downstream Area Owner.

In a Restricted Area, each Area Claimer would need to have Area Restriction behaviors that can coordinate with the corresponding Area Restriction behavior on the Area Owner. There are two possible Area Restriction combinations:

• Enter/Exit Area - Use this combination when you want to give multiple items or groups of items access to a Restricted Area at a time. The items will attempt to enter the Area until the item limit is reached. At that point, any subsequent items must wait at the entry point until an item exits the area. When you build this kind of Area Restriction system, use the Enter Area behavior on the Area Claimers and the Exit Area behavior on the Area Owner.
• Acquire/Release Area - Use this combination when you only want one item to be in the Restricted Area at a time. The Area Claimer will request permission to get exclusive access to pass through a Restricted Area.Only one Area Claimer can acquire the area at a time. Once released, another Claimer may acquire the area. When you build this kind of Area Restriction system, use the Acquire Area behavior on the Area Claimers and the Release Area behavior on the Area Owner.

Each of the four available behaviors has one field in common: the Area Owner field. The Area Owner field allows you to determine which object will be the Area Owner for the Restricted Area. For entering/acquiring, the default is outobject(current, 1), whereas for exiting/releasing, the default is current. If you use these default values, you should connect the entry/acquire points' first output port to the exit/release point (the Area Owner).

The following sections will discuss each of the Area Restriction behavior settings.

Enter Area

Select Enter Area from the Restricted Area submenu if you want to limit the number of items that are allowed into the Area at a single time.

When selected, the following dialog will pop up:

The Condition field allows you to customize the criteria that the Decision Point or Photo Eye will use to determine whether to start the behavior when a particular Trigger fires. For more information about the options available in the Condition field, see The Condition Field.

The Area Owner field allows you to determine which object will be the Area Owner for the Restricted Area. See the description of the menu options in the introductory section for this topic for more information.

You can type in a specific number in the Max Content box. The number will specify how many items can have access to the Restricted Area at a given time.

All Objects Should Use the Same Max Content
If there are multiple Decision Points or Photo Eyes that are using the Enter Area behavior, they should all have the same Max Content number.

Exit Area

Select Exit Area from the Restricted Area submenu if you want an item to exit the restricted area at the Decision Point or Photo Eye.

When selected, the following dialog box will pop up:

The Condition field allows you to customize the criteria that the Decision Point or Photo Eye will use to determine whether to start the behavior when a particular Trigger fires. For more information about the options available in the Condition field, see The Condition Field.

The Area Owner field allows you to determine which object will be the Area Owner for the Restricted Area. See the description of the menu options in the introductory section for this topic for more information.

If you don't check the Prioritize Entry Requests check box, by default the Decision Point or Photo Eye will accept incoming Area Requests on a first in, first out (FIFO) basis. However, if you check this box, the Decision Point or Photo Eye will prioritize certain Area Requests over others. Once this box is checked, the Priority menu will become available.

The Priority field defines the priority value associated with a specific item trying to enter the area. Use the drop-down on the right for suggestions. Possible values might include:

• up(item) == conveyor: Gives priority to requesting items already on the release point's conveyor, i.e. if the item's current conveyor (up(item)) is the same as the release point conveyor (conveyor), the == comparison returns true (1), which is a higher priority value than false (0).
• getlabel(item, "priority"): Use the value of the requesting item's "priority" label for the priority.
• getitemtype(item): Use the value of the requesting item's itemtype for the priority.

The Delay Time field lets you define an optional delay time to wait before actually executing the behavior to exit the area.

Acquire Area

Select Acquire Area from the Restricted Area submenu if you want the Decision Point or Photo Eye to request permission to get exclusive access to pass through a Restricted Area when the Trigger fires.

When selected, the following dialog box will pop up:

The Condition field allows you to customize the criteria that the Decision Point or Photo Eye will use to determine whether to start the behavior when a particular Trigger fires. For more information about the options available in the Condition field, see The Condition Field.

The Area Owner field allows you to determine which object will be the Area Owner for the Restricted Area. See the description of the menu options in the introductory section for this topic.

The Area Claimer menu allows you to determine which object will be the Area Claimer for the Restricted Area. Typically this will be one of the following values:

• item - The current item on the Decision Point or Photo Eye will be the Area Claimer.
• current - The current Decision Point or Photo Eye will be the Area Claimer.
• conveyor - The conveyor will be the Area Claimer.

Release Area

Select Release Area from the RestrictedArea submenu if you want the Area Owner to release the Area, meaning it will resume control of the Area after an item that has been given access passes through the Area.

When selected, the following dialog box will pop up:

The Condition field allows you to customize the criteria that the Decision Point or Photo Eye will use to determine whether to start the behavior when a particular Trigger fires. For more information about the options available in the Condition field, see The Condition Field.

The Area Owner field allows you to determine which object will be the Area Owner for the Restricted Area. See the description of the field options in the introductory section for this topic for more information.

If you don't check the Prioritize Acquire Requests check box, by default the Decision Point or Photo Eye will accept incoming Area Requests on a first in, first out (FIFO) basis. However, if you check this box, the Decision Point or Photo Eye will prioritize certain Area Requests over others. Once this box is checked, the Priority field will become available.

The Priority field defines the priority value associated with a specific item trying to enter the area. Use the drop-down on the right for suggestions. Possible values might include:

• up(item) == conveyor: Gives priority to requesting items already on the release point's conveyor, i.e. if the item's current conveyor (up(item)) is the same as the release point conveyor (conveyor), the == comparison returns true (1), which is a higher priority value than false (0).
• getlabel(item, "priority"): Use the value of the requesting item's "priority" label for the priority.
• getitemtype(item): Use the value of the requesting item's itemtype for the priority.

The Delay Time field lets you define an optional delay time to wait before actually executing the behavior to releasing the area.

Examples

Below are several examples of using Area Restriction.

One-at-a-Time Merging

The following diagram shows an example of a simple one-at-a-time merge.

To build this model:

1. Create and connect the sources, sink, and two conveyors as shown.
2. Drop three Decision Points onto the conveyors at the positions shown.
3. Connect the two upstream Decision Points to the single downstream Decision Point using the 'A' connection tool.
4. Double click on each of the upstream Decision Points, and in the On Arrival trigger, choose Area Restriction > Acquire Area. Make sure the behavior properties are the same as in the diagram shown above.
5. Double click on the downstream Decision Point, and in its On Arrival trigger, choose Area Restriction > Release Area. Make sure the behavior properties match those in the diagram above.
6. Reset and run the simulation.

The merge should only let one item into the area at a time. Once an item passes the release point, the next item will be allowed in. By default, the items will enter in fifo order, i.e. the first item that hits the acquire point will be the first one to enter the area.

Now let's change a setting and see how it affects the functionality. On the upstream acquire points, change the Area Claimer, from item to current. Then run the simulation again.

In this case, the Decision Point, not the item itself, will "claim" the area. The effect is that as long as items acquire through the same Decision Point that has claimed the area, they will be allowed in. Only once they've all exited the area will it allow the next batch in from a different "claimer". Note here that the mechanism will keep a counter of how many items have entered. Only when the counter goes to zero will the area be released. This can have subtle and sometimes unintended consequences especially if you are using Photo Eyes, where blocking/clearing is dependent on a gap between the items. If gaps are introduced or removed while items are in the area, the counter may get off and break the merging mechanism. Hence you should be careful when using a non-item claimer in conjunction with Photo Eyes.

Slug-Based Merging

Slug-based merging is very similar to the One-at-a-Time example, but here we instead use Photo Eyes. The difference is that if multiple items are backed up against each other, by default the Photo Eye will block/clear only once for the entire slug, meaning a whole slug can pass through for a single acquire. The diagram below shows an example of a simple slug-based merge.

To build this model you can refactor the one-at-a-time example, or build from scratch:

1. Create and connect the sources, sink, and two straight conveyors as shown.
2. Using the Join Conveyors tool, create a curved conveyor from the merging conveyor to the main line conveyor.
3. Drop three Photo Eyes onto the conveyors at the positions shown.
4. Connect the two upstream Photo Eyes to the single downstream Photo Eyes using the 'A' connection tool.
5. Double click on each of the upstream Photo Eyes, and in the On Block trigger, choose Area Restriction > Acquire Area. Make sure the behavior properties are the same as in the diagram shown above.
6. Double click on the downstream Photo Eye, and in its On Clear trigger, choose Area Restriction > Release Area. Make sure the behavior properties match those in the diagram above.
7. Reset and run the simulation.

Now entire slugs should pass through the area.

Gapping

You can also use Area Restriction to define gapping. The following diagram shows an example gapping model.

To build this model:

1. Create and connect the sources, sink, and conveyor as shown.
2. Drop two Photo Eyes onto the conveyor at the positions shown.
3. Connect the upstream Photo Eye to the downstream Photo Eye using the 'A' connection tool.
4. Double-click on the upstream Photo Eye, and uncheck the box Require Gap to Clear.
5. In the Photo Eye's On Block trigger, choose Area Restriction > Acquire Area. Make sure the behavior properties are the same as in the diagram shown above.
6. Double click on the downstream Photo Eye, and in its On Clear trigger, choose Area Restriction > Release Area. Make sure the behavior properties match those in the diagram above.
7. Reset and run the simulation.

This will enforce a gap between items that pass over the photo eyes. The gap from back-to-front will be the distance between the Photo Eyes.

Variable Gapping

You can also use Area Restriction to simulate variable gapping. The diagram below shows a model that implements variable gaps between items, based on the item size.

To build this model, you can refactor the previous gapping model, or build from scratch:

1. Create and connect the sources, sink, and conveyor as shown.
2. Drop a Photo Eye onto the conveyor at the position shown.
3. Double-click on the Photo Eye, and uncheck the box Require Gap to Clear.
4. In the Photo Eye's On Block trigger, choose Area Restriction > Acquire Area. Set the behavior properties to match the diagram shown above. Make sure you change the Area Owner to current.
5. In the Photo Eye's On Clear trigger, choose Area Restriction > Release Area. Set the behavior properties to match those in the diagram above. Make sure you change Delay Time by choosing Time to Convey Item X Size from its drop-down.
6. Reset and run the simulation.

This will enforce a variable gap between items, equal to the x size of the ahead item.