question

A simple solution to just activate an AGV that can reach the destination is to add a dynamic expression field to the Available AGVs list named something like canReachPullerItem, with the code of:

distancetotravel(getlabel(value, "agv"), up(getlabel(puller, "item"))) < 1000000000

You would also need to change the Wait for New Item on Load List activity. Right now it waits for the Local Partitioned Load List's content to increase. Instead you'll probably want it to listen to the OnPush so you can get exactly which item was pushed on and assign it to the token's "item" label.

Then in the Get a Parked AGV activity, you can add a WHERE clause of:

WHERE canReachPullerItem

The problem with this is that it just solves a single facet of the overall problem. The bigger problem is proper load balancing. The decision that an AGV makes to park is based on the overall number of active work tasks vs the number of active AGVs. If you do not properly group the AGVs and the work into their proper reachable areas, then that load balancing heuristic will not work because some AGVs will park because they think other AGVs are going to do the work in their areas, while other AGVs keep going around in loops trying to find work that they will never find because the active work is not in their area.

You could provide a similar mechanism for the parking decision. You would need to add and manage a global list of all work (Local Partitioned Load List is partitioned by the LFW point, so you can't search that entire list). Right now, when an AGV gets to the point where it might want to park, it checks the content of the Active AGVs zone vs the content of the Active Items zone. To get more control of that you'd need to change both of those zones into lists (where you enter a zone, you would instead push to the list, and where you exit you would pull the specific token from the list). Then when you need to decide if you should park, you query the Active Items list without pulling anything off of it (request and require numbers are both 0), and in your pull query you have a WHERE clause of something like WHERE canPullerReachItem, similar to the field above except with value and puller swapped. That will query the list and assign to a token label an array of all the items that are reachable by that AGV. Then you would query the Active AGVs list with a WHERE clause of WHERE canReachPullerItem, similar to the Available AGVs field, and you pass as the puller the first item in the result of the Active Items query. This will get you back an array of all the active AGVs who can reach the first item in the array of items that you can reach.

Of course, this "see which AGVs can reach the first item I can reach" strategy makes the assumption that, if another AGV can reach the first item that I can reach, that AGV can also reach all of the items that I can reach. I would assume that that statement is true for all useable networks, i.e. networks are partitioned into discretely separated areas, and every AGV can reach every point in its assigned area. But I bet if someone tried they could create some network configuration where that isn't true :-). The other thing is that these fields test whether a given location is reachable, not whether the location is in the AGVs NextLookForWork loop. If you have separate NextLookForWork loops that are nevertheless reachable to each other, this solution would not work. So in order for this to work, the networks have to be completely separate from each other, not just separated into different NLFW loops.

Once you have those two arrays, namely an array of active items that you can reach, and an array of active agvs that can also reach those items, you can decide whether to park based on the size of the active items array vs the size of the active AGVs array. You'll need to do this everywhere where you are doing load balancing heuristics, namely in both the parking and in the activation logic, and each area might have subtle differences.

So, I guess you can do that, but it is a more complicated solution. If you feel you have the chops to tackle it, go ahead. In the end, though, my suggestion is to just use Phil's solution, namely that you require that the user who builds the model properly defines those "partitioned areas", by having multiple AGV process flows, each with its own work list. It keeps the logic of process flow more manageable in my opinion.