Arena allows you to define conveyor operation as a fixed path for material movement with pre-defined entry and exit points using the modules on the Advanced Transfer panel. Each entity to be conveyed must wait for sufficient space on the conveyor in order to gain entry and start transferring. When the entity reaches the end of the conveyor, the conveyor is disengaged until the entity is removed from the conveyor or conveyed to another station.
In the case of accumulating conveyors, downstream conditions may cause entities to accumulate, or back up, on the conveyor. So what happens if you want to prevent more entities from getting on the conveyor and continuing to back up? Allowing a conveyor to back up with accumulated entities to its full length can have dire consequences for downstream operations.
An example of this might be a conveyor feeding a machine where too much back-pressure causes the machine to jam. In the real world, we would control the movement of product with photoeyes or other types of sensors on the conveyor. This Tips & Tricks article demonstrates a method of modeling sensors to control the discrete movement of entities.
Building Blocks
There are some SIMAN Blocks and Elements which can help us control the movement of entities. The BLOCKAGES Element, BLOCK block, UNBLOCK block, and PROCEED block can all help us in controlling whether entities are allowed to gain entry to a downstream conveyor. Let’s start with a brief definition of each of these modules.
- The BLOCKAGES element defines all blockages used in your model. There are two mechanisms for setting and clearing block points. The BLOCK and UNBLOCK blocks may be used to change the number of block points for a blockage directly.
- The BLOCK block adds blockage points to the blockage ID defined in the BLOCKAGES element. If the total block points for the blockage ID is greater than zero, any entities entering PROCEED blocks using this blockage ID are not allowed to pass.
- The UNBLOCK block removes block points from the blockage ID. If the resulting number of block points for the blockage ID is greater than zero, any entities entering PROCEED blocks using this blockage ID are not allowed to pass.
- The PROCEED block suspends entity movement through the model until all specified blockage ID blockages are clear. If the blockage ID has a positive number of block points, arriving entities are held in the PROCEED block queue until all blockages are cleared.
Description of Example System
Our example contains three conveyors: an entry conveyor, a conveyor feeding a machine, and a machine conveyor where product is tested or transformed as it conveys through the machine. Each conveyor has a single entry point and exit point. For purposes of the example, entities arrive to the entry conveyor at a constant rate of one every 0.04 minutes.
The entry conveyor, called Entry Conv, is an accumulating type conveyor, 170 cells in length, and running at 25 inches per minute. The feed conveyor, called Conv 1, is also an accumulating conveyor, 55 cells in length, and running at 1015 inches per minute. The machine conveyor, called Machine Conv, is a non-accumulating conveyor, 9 cells in length, and running at 25 inches per minute. Entities require 5 cells as they move along Entry Conv and Conv 1 and their accumulation length is 5 cells. However, entities require only 1 cell to move along the Machine Conv and there is no accumulation length since this is a non-accumulating conveyor.
There are back-pressure limitations on the machine represented by Machine Conv. When the accumulation of entities on the feed conveyor, Conv 1, reaches 85% of its length as measured from the discharge end, the flow of entities from Entry Conv must be stopped.
Implementing the Sensor Logic
In order to control the conditions under which we allow entities to get onto Conv 1, we first define a blockage called Conv 1 Blockage.
Next, we use a logic loop to check the status of the conveyor. We create a single control entity to execute the logic loop. This control entity goes into a Hold module with the Scan for Condition option. The condition checks the length of accumulated entities on Conv 1 with the Arena system variable CLA. The length of the Conv 1 conveyor is 55 cells, so 85% of that length works out to about 47 cells. So when CLA(Conv 1) >= 47, the control entity executes the Block module, where one block point is added to the Conv 1 Blockage, and then goes into another Hold module scanning for the condition where the length decreases below 47 cells. In order to prevent continually cycling between holding and allowing these entities onto the conveyor with the addition of each entity accumulated, the control entity executes a small, 2 second delay before removing the blockage point with the Unblock module. Note that in your application, you may want to use Arena’s LEC (length of conveying cells) variable in addition to the CLA variable shown above. This would allow you to check the total length of cells conveying plus the total length of cells occupied by accumulated entities.
The Block and Unblock in the logic loop will essentially raise or lower a gate for entities trying to get onto the Conv 1 conveyor. So what is this gate? It’s the Proceed block specifying the Conv 1 Blockage.
When using the Proceed block with the other logic modules in your model, it would look something like the following:
Note that entities convey on the Entry Conv until they reach the station s Conv 1 Entry. However, an entity cannot access cells on Conv 1 unless it can pass through the Proceed block, and the ability to pass through the Proceed block is based upon the value of the Conv 1 Blockage. The value of Conv 1 Blockage is controlled by the Block and Unblock modules in the previous logic loop and based upon checking Conv 1 conditions.
Seeing Sensors in Action
So it’s all well and good to put in the above logic to mimic a sensor on our conveyor, but we need to test it and see it in action. To do this, we need to cause Conv 1 to back up to the point that we see entities prevented from entering Conv 1 from the Entry Conv. A quick way to do this is to cause Machine Conv to experience failures. We put in another logic loop creating a single control entity to loop through some simple failure logic. Is this case, the Mean Time Between Failures is 10 minutes and the Mean Time To Repair is 3 minutes. We put a module break on the Stop module and the Start module so we can observe the conveyor behavior in the animation.
After running the model to the break on the Stop module and then stepping forward a bit, we see the following:
The Machine Conv is still stopped and Conv 1 has an accumulated length of 50 cells. Since each entity requires 5 cells on this conveyor and our sensor position is at 47 cells, this is correct and what we would expect to see.
Now running until Machine Conv is started again and stepping forward just a bit, we see that Conv 1 is starting to work off its accumulation and new entities are being allowed onto Conv 1 from the Entry Conv.
Continuing to run forward a bit, we see the accumulation on Conv 1 has been worked off entirely and entities are flowing from the Entry Conv through Conv 1 and onto Machine Conv.
This example of modeling sensors was used to limit the amount of accumulation on a conveyor feeding a machine, however this methodology could be used for other types of sensor applications.
Would you like to get your hands on this model and use it as a springboard for your own applications? We would be more than happy to share it with you.
