Table of Contents

Table of Contents

Troubleshooting AGVs

Troubleshooting AGVs

This topic provides suggestions for troubleshooting common AGV problems.

Showing AGV Routing Accessibility

When you get navigations errors, you can use show the routing accessibility for control points in the AGV system. This lets you easily troubleshoot navigation errors. To do this:

  1. Find the destination control point that the task executer cannot find a path to. In the example screenshot above, this would be the control point connected to Source1.
  2. Right-Click on that control point and choose Show AGV Routing Accessibility.

Various path transfers will be highlighted in blue. These are points on the network that CAN reach the target control point.

If a task executer cannot reach the control point, then the path transfers around him will not be blue. You can then follow the assumed path from that task executer to the destination. At the point where transfers change from black to blue, that is the point where there is some break in the path links such that the task executer cannot reach the destination.

Refreshing Path Links

In the course of building your model, sometimes AGV paths will lose, or not properly create, links to their neighbors. This can cause the navigation errors mentioned above. You can manually refresh these links through a path's right-click menu. Once you've found the point where navigation is blocked, you can right click on the path and refresh its path links.

This will make the network re-analyze the geometry of that, and potentially other, paths, and will re-link the path with its neighbor paths, allowing the AGV system to properly routing AGVs to their destinations.

Troubleshooting AGV Accumulation Behavior

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 logic 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.

Solutions

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.