How can I identify if an AGV is on a segregated path?

Question

question

BenJoaquin Gouverneur asked Nov 8, '16 anthony.johnson edited Nov 14, '16

How can I identify if an AGV is on a segregated path?

Hey guys,

We have a model with two completely segregated AGV paths. We've observed that when an item is put on the AGV work list there is no awareness in the activation process about wether or not the AGV can actually access the work. This creates incorrect waking and aimless wondering of an AGV in the beginning of a model run and ultimately causes the model to run without being productive because the wrong AGV is looking for work it can't access. We'd like to modify the AGV Activation process flow to identify if the AGV will be able to pickup the item possibly using the same or similar logic that is used to identify a travel path or used to throw and error when an AGV picks up an item it can't deliver.

Can you guys please share how we can improve the activation logic to resolve this?

Thanks!

Software Version:

FlexSim 16.2.1

agv agv network agv process flow

· 1

Joerg Vogel commented · Nov 11, 2016 at 05:30 AM

I am not familiar with ProcessFlow but that doesn't matter because the navigator contains all information of a network: objects to reach, Taskexecuters, PickOff and DropOff Points. When a tasksequence is created you can test if the coupling data contains the objects for the destination or load station and the taskexecuter belong to the subnetwork matching with the tasksequence. There are existing functions to look for nodes under other nodes and a matching structure. Both are well documented in the manual or discussed in the old community forum. That would work only if the network structure is static until the tasksequnce is done. If you change the structure dynamically by code or ProcessFlow then the test method has to test all existing tasksequences in the model each time the network structure changes.

What you want from the Flexsim engine isn't implemented neither for networks with network nodes. The error occurs when the task is executed and not while the tasksequence is created.

0 ·

Answer 1 · 2016-11-11T20:52:09Z

anthony.johnson answered Nov 11, '16 anthony.johnson edited Nov 11, '16

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.

Answer 2 · 2016-11-10T23:23:21Z

Phil BoBo answered Nov 10, '16 BenJoaquin Gouverneur commented Nov 11, '16

You could add 2 AGV process flows to your model. Then make a second AGVWork list, and make sure the Global Load List in the middle of the second AGV process flow points at the second work list.

Use the first AGV process flow and work list for the AGVs on one of the paths and the second AGV process flow and work list for the AGVs on the other path.

· 1

BenJoaquin Gouverneur commented · Nov 11, 2016 at 12:35 AM

@phil.bobo, thanks for the idea.

Since our work is focused on building libraries that solution doesn't solve. The two network condition described here was hypothetical to give concrete detail on the problem. In practice we don't know how many AGV networks a user will create or which AGVs will end up on which networks.

Again, when an AGV picks up a load that it can't deliver an error is thrown so it seems possible to run that logic elsewhere to prevent activation and other undesirable behavior.

Thanks.

0 ·

Answer 3 · 2016-11-10T17:30:26Z

BenJoaquin Gouverneur answered Nov 10, '16

@Brandon Peterson, this is a question I asked yesterday regarding separate AGV networks. I think it would provide a more elegant solution to the issues we just discussed than a table defining what AGVs are on what networks. Let's see what the rest of the team comes back with.

Thanks.

question