The AGV Network helps you to create travel paths while simulating automatic guided vehicles (AGVs) and other task executers.
The AGV module does not add its own AGV object type to the library. Instead you attach task executers to control points on an AGV network, and those task executers will travel using AGV-defined logic.
Task executers who have been attached to an AGV network will have additional events that can be subscribed to with a process flow Wait For Event or Event-Triggered Source activity.
AGVs can track the following statistics:
The AGV Types tab has the following properties:
You can get to the AGV Types page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
Here you can add, remove, re-order and rename the set of Path Classes for the model. Path Classes are specifically used for breaking out AGV speeds by path. When you add a Path Class, a new speed row associated with that Path Class will be added to each AGV Type table for both forward and reverse speed.
Here you can add, remove, re-order and rename the set of Load Types for the model. Load Types are a user-defined list defining categories for what an AGV is carrying. This allows you to break out AGV speeds by the AGV's current load.
This is a trigger that is fired at the beginning of each travel operation. The primary objective of this trigger is to set the AGV's current Load Type.
Here you can add, remove, re-order and rename the list of AGV Types for the model.
In the AGV Type Spec Table you define max speeds by Path Class, Load Type and AGV direction, as well as acceleration, deceleration and non-idle battery usage.
Each AGV Type has a defined Battery Capacity (in Amp Hours), Idle Battery Usage (in Amps), and Recharge Rate (in Amps). Additionally, each AGV Type has a non-idle Battery Usage (in Amps) broken out by Load Type. Each AGV starts the simulation at its maximum battery capacity, and then will track its battery usage over the course of the simulation. Whenever it is idle, its Idle Battery Usage applies. Whenever it is doing a travel operation, its battery usage is based on its current Load Type. If you set the AGV to recharge, it will recharge at its recharge rate until it is full or it starts its next travel operation, whichever comes first. To query battery level, start a recharge, or manually set the battery level, etc., see the documentation for the agvinfo() command.
You can also make the AGV attach loaded items as trailers to the AGV. This will make the loaded items trail behind the AGV on its path, instead of being carried on the AGV. Check the box Attach Loads as Trailer, and then define the Trailer Gap, which is the distance of the gap between the back of the AGV and the front of the trailing item.
Usually when you give an AGV a task to travel to a destination, you will want the AGV to end that travel task fully decelerated to a stop. However, in some cases you may want to end a travel task while still moving, for example if you want to make dispatching decisions on-the-fly. In this case you can define a non-zero end speed for the travel task. Doing this will actually shift earlier the end time of the travel task, as well as the position of the AGV at the time it finishes. In other words, instead of ending on the destination control point while still moving, the travel task will end while the AGV is still approaching the control point, at the defined end speed. If you don't immediately give the AGV any subsequent travel tasks, then the AGV will decelerate down to stopped, arriving at the control point AFTER the travel task has finished. If, however, you immediately give the AGV a new travel task, it will continue to the new task, starting at the end speed of the previous task, traveling through the original destination control point.
The Way Points tab has the following properties:
Way Points are used to define AGV control logic that will happen when an AGV passes over a control point. However, going forward we advise you to use process flow instead of Way Points for AGV control. FlexSim provides a template AGV control process flow, which can be used as a starting point for defining AGV control logic..
You can get to the Way Points page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
Here you can add, remove, re-order, and rename each Way Point.
This defines when to fire the Way Point Logic. Options are:
A field that should return 1 if the Way Point should be fired, 0 if not.
The code for the Way Point.
The list of Control Points that are part of this Way Point. Here you can add, remove and re-order the members list.
See Way Point Trigger Actions for more information.
The Control Point Connections tab has the following properties:
You can get to the Control Point Connections page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
For each Control Point Connection, you can define whether or not its visible in the 3D view, and its color. You can also add, remove, and rename connections as needed.
If you check the List box for a connection, all of those connections in the model will be added to a global partitioned list. This allows you to easily define AGV control logic with a process flow. When an AGV arrives at a given destination, you can decide what to do by pulling from various list partitions associated with the AGV's current control point, such as, find a control point near here that has work that the AGV can do, or find a parking spot to go to, or continue to the next point to look for work. These operations can be done by pulling from the current control point's partition of the global list.
A Control Point Connection has one of three possible connection types:
You can use Control Point connections through various trigger actions, such as Way Point trigger actions, or by manually accessing them with the cpconnection() command.
The Accumulation Types tab has the following properties:
Accumulation Types let you define parameters for accumulating paths, i.e. paths on which AGVs will detect proximity and avoid collisions with each other.
You can get to the AGV Types page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
Add, remove, rename and re-order Accumulation Types through the combobox and buttons at the top of the page.
To assign a path an Accumulation Type, click on the path, and in its Quick Properties on the right, choose the desired type from the Accumulation Type drop-down.
These properties define how two AGVs will detect proximity with each other while on a common accumulating path.
When you define an Accumulation Type for a path, the AGV network will treat intersections on that path as allocations. Similar to the way AGVs must allocate Control Points and Control Areas, AGVs must allocate the intersection points on an accumulating path before proceeding past those intersection points. In the Accumulation Types page you define stop distances, which are distances before the intersection where the AGV must stop before an intersection point if the AGV cannot allocate it, as well as clear distances, which are distances after passing the intersection point where AGVs will release the intersection and allow other AGVs to claim it. Each of these distances are split out by whether the AGV is entering, exiting, or on the path. If already on a path or staying on a path, the distances are split out by the path geometry, i.e. whether or not the intersection branches out away from the AGV or toward it.
Here you define the stop distances for an intersection. For each distance, you define the distance itself as well as an AGV edge, which determine what part of the AGV should stop at the stop distance. Usually stop distances will be based on the leading edge of the AGV. When you click in a given field, the diagram on the right will display the distance / edge that you are defining, to help you figure out what exactly the field defines.
Here you define the clear distances for an intersection. Like with stop distance, you define the distance itself as well as an AGV edge. Usually clear distances will be based on the trailing edge of the AGV. When you click in a given field, the diagram on the right will display the distance / edge that you are defining, to help you figure out what exactly the field defines.
There are a few special rules that apply to allocating intersection points.
Many users will see the option for accumulation and think this is the perfect solution for what they want to do. The truth, however, is that using accumulation, while making many simulation scenarios easier, can also introduce new complexities and potential problems. This doesn't mean you shouldn't use accumulation. Most encountered problems are easily fixed with the right know-how. Rather, you should just make sure you have a good understanding of how accumulation works before deciding to use accumulation.
The primary complexity with using accumulation is that it creates a new allocation scheme, one that is different than, but will operate in tandem with, the standard allocation scheme used for control points and control areas. Consequently, in some situations the two allocations schemes will "fight" with each other, and cause deadlock in the system. This is especially more probable in close-quarter intersection areas that use control areas to mutually exclude traffic.
An example problem situation is shown in the following figure.
In this situation, AGV_7 has allocated the intersection after the control area, but has yet to allocate the control area itself. This creates a serious problem because AGV_9, the other AGV at the bottom center of the screen, will allocate the control area first. Then the two AGVs will get into a deadlock because AGV_7 can't allocate the control area owned by AGV_9, and AGV_9 can't allocate the intersection owned by AGV_7.
As mentioned before, this is caused because two different allocation schemes are in play here, namely the allocation of control areas vs. the allocation of intersections on accumulating paths. When allocating control areas, the AGV allocates when it pre-arrives at the previous control point. It will drive up to the closest control point, then allocate (in an all-or-nothing fashion) the next control point on its path, as well as all control areas on its path to that next control point. Thus the timing of when the AGV allocates the control area is based on the position of the control point leading up to the control area.
Accumulating intersection allocation, on the other hand, is determined based on the position of the intersection and the settings of the associated Accumulation Type, defined in AGV network properties. In the situation shown above, AGV_7 would use the "On Path Long" setting, whose default says the AGV should be able to stop with its leading edge at least one meter short of the intersection if it can't allocate that intersection. This determines the point at which the AGV will attempt to allocate the intersection.
In the example situation, AGV_7 allocates the intersection first because the control point is pretty close to the control area, so it reaches the point where it needs to allocate the intersection before it reaches the point where it needs to allocate the control area. On the other hand, AGV_9's control point is situated a little farther away from the control area, so it will allocate the control area before it allocates the intersection. This causes the deadlock.
When encountering issues like this, there are two primary solutions you can try. First, you can create a special accumulation type that is specifically designed for close-quarter intersections. This accumulation type would ensure that control areas are always allocated before intersections. Here you would simply create a new accumulation type in the AGV network properties. Then for each intersection stop point, base it on the center of the AGV, with a distance of 0, meaning the AGV's center must stop 0 meters short of the intersection if the AGV can't allocate it. Once you've done that, make all the paths in that small area use that accumulation type.
The second solution to try is to simply not use accumulation in those close-quarter areas. Just go to each path in the intersection and make its accumulation setting "No Accumulation." This will make it so the control area is the sole mutually excluding element in the area. Then you don't have to worry about the right order of allocation. Here you'll want to make sure that the deallocation of the control area is not too early. You want the AGV to at least allocate the first intersection on an accumulating path ahead of it before it deallocates the control area. That shouldn't be too difficult. If it doesn't do it already, you can either lengthen the deallocation distance for that control area's deallocation type, or you can put down a control point at the beginning of the next accumulating path, then make the control area's deallocation type "Deallocate at Next Control Point."
As a general rule of thumb, accumulation works very well in areas of a model where there are long sections of path with relatively few intersections. On the other hand, in areas where there are lots of close-quarter intersections, it can be easier and less problematic to turn off accumulation, bound the areas with control points, and then limit traffic inside them with control areas.
The Deallocation Types tab has the following properties:
You can get to the Deallocation Types page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
Here you can add, remove, re-order and rename each Deallocation Type.
This defines which "edge" of the AGV will determine the deallocation time. Options are:
Defines the associated point on the path that determines deallocation time. Options are:
This is an additional distance that will be added onto travel before deallocating the object.
This is an additional time to delay deallocation, after the defined edge has reached the travel point plus the distance.
The Visual tab has the following properties:
You can get to the Visual page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
Defines the color by which Paths will be drawn in the 3D view. This is especially useful if you are overlaying your model with a CAD drawing, and want to delineate between AGV Network paths built in the model and CAD lines.
Defines the color by which Control Points will be drawn in the 3D view.
Defines a baseline width, in pixels, by which Paths and Control Points will be drawn in the model.
Defines a baseline size by which to scale drawing of Control Points and Path direction arrows.
Defines how the respective objects can be manipulated in the model. As you finish certain parts of your model you may want to restrict what you can change about the objects in it. Options are:
The General tab has the following properties:
You can get to the General page by right-clicking on a Path or Control Point and choosing AGV Network Properties.
A trigger that will fire for each AGV at the beginning of the model. Usually you will use this to fire the AGV's OnResourceAvailable, in order to start the AGV polling for work.
If checked, the Control Point/Control Area allocation logic will continuously check for deadlock cycles. If it finds one, it will stop the model and notify you of the issue. Note that deadlock detection does require additional calculations and may slow your simulation down. You should hence turn it on while debugging, and once all deadlock issues are resolved, turn it back off.
If checked, AGV's will interpret travel tasks with end speed of 0 to mean: end at the AGV's max speed. This behavior is the default with other FlexSim travel mechanisms, such as standard travel networks that use network nodes. However, with AGVs this is not always the desired behavior, so it is an explicit setting that you define here.
The following sections explain the different way point trigger actions.
Redirect via Search will redirect the AGV by search through the Control Point Connections of the Control Point the AGV is arriving at.
This action will search for work to do and take up work when found.
This action will redirect the AGV to another Control Point by a direct reference.
This action will wait for one of a set of Control Points to become available. When availability happens, all actions for the Way Point trigger will be refired. Usually you will place this action after a Redirect Via Search action, such that if nothing is found to redirect to, i.e. all Control Points are unavailable, you can wait for a Control Point to become available.
This action will wait for work to arrive at a defined set of Control Points. This should be used in conjunction with the Use Transport > Move Item Via AGV action. When that action is used, flow items will be placed in the Control Points for pick up. This Wait For Work action will listen for when items enter those Control Points, and then will refire all actions for the Way Point again. Usually you will add the Wait For Work after a Look For Work action, such that if no work is found, you can then wait for work to arrive.
This action will wait for a defined delay time and then refire the Way Point trigger's actions again. Usually you put this at the start of a Way Point trigger. This can implement some delay associated with the real-life decision making process, i.e. if it takes the real-life system 5 seconds to process a dispatching decision, you first wait for 5 seconds, then fire the decision logic.