question

First, I would suggest only making the main line path accumulating. There's no point in making a spur path accumulating because you're only going to let one agv onto that spur at a time (either through a control area, or just by making the final destination control point have Max Allocations of 1). Thus there's no reason to do accumulation logic on those paths, because you'll never have two agvs on that path anyway.

Making everything accumulating in this scenario complicates the allocation "mapping". When you allocate a transfer between two accumulating paths, it's actually making two allocations. First it must allocate the transfer associated with the path it's already on. Second, it also has to allocate that same transfer, but associated with the path it's trying to get onto. These two allocations could technically happen at different times, depending on how you define distances in the accumulation settings. One uses the On Path Short distance, while another uses the Path Entry distance. Long story short, it's more complicated when both paths are accumulating, so avoid the complication if you don't need it. By making the spur path use no accumulation, you're now dealing with a single allocation at the transfer. For the AGV trying to get onto the spur, it uses the On Path Short distance. For the AGV already on the spur getting back onto the main line, it uses the Path Entry distance.

OK, now that that complication is mitigated, the real reason it's deadlocking is because the On Path Short distance is greater compared to the location of the control point. When you enable accumulation on a path, you're enabling, among other things, the stopping of AGVs at any point along that path. This triggers a different type of allocation logic. With control point allocation, AGVs only do their allocation logic at control points, making the control points the only "legal" points where AGVs will stop. However, with accumulating paths, since AGVs are now allowed to stop anywhere on the path, they will go as far as they can before they allocate transfers. By "as far as they can" I mean, they will go to the points defined by the distance settings in the Accumulation page of the AGV Network Properties. In this example the AGVs on the main path use the On Path Short distance to determine how far they can go before they have to allocate that transfer onto the spur. The On Path Short distance is 1 meter relative to the leading edge of the AGV. This means that the AGV will allocate the transfer at the point where, if it fails allocation, it will stop with its lead edge 1 meter short of the transfer. In your model's layout, this point is before the arrival of the agv at the control point that allocates the control area. This means that the AGV on the main line will first allocate the transfer, and then allocate the control area. This is the cause of the deadlock. To get rid of this, you can either move the control point back to at least 2 meters short of the transfer (1 meter half-size of the agv plus 1 meter for On Path Short distance), or change the On Path Short distance in the accumulation settings to be lower so the agv will arrive at the control point before allocating the transfer.

When I designed the accumulation mechanism, I wanted to make it easier to handle junctions without having to put control areas and control points all over the place to prevent collisions when moving on and off of accumulating paths. This was the idea behind allocating the transfers on accumulating paths. However, hind sight is 20-20, and I see now that enabling a different kind of allocation scheme (distance-based vs. control point-based) introduced its own set of complications, namely that if you don't place your control points correctly at the right distances, you can easily run into deadlock from the distance-based and control point-based logic not playing nice together. And the solution for this is not immediately apparent, as you have found out.

Perhaps a solution going forward would be to make the allocation distances be lower, or 0, by default, or to have an option where it doesn't do transfer allocation at all, and leaves it up to the user to manually put control points and control areas out at the junction points. This would better avoid deadlock, but it might force the user into more work in the end anyway. Alternately, we could just treat it more as a user-training/teaching issue, where we make it clear that the accumulation is not "the box you check to make all your AGV problems go away." Instead, we make it clear that AGV accumulation is complex, with it's own potential snags and hiccups, but we provide lots more pointers and guides, like this, in the user manual. Anyway, for now, it is what it is.