question

Hey Jim,

Yeah, you're right. I added the fields Type, age, distance, and queueSize to the main AGVWork list, but those are actually useless because the items in AGVWork get immediately pulled off and then sent to an internal partitioned list. We need to fix that so the fields are available on Local Partitioned Load List. Yes, you are encouraged to add whatever fields you feel are useful to Local Partitioned Load List. Then you can define the pull query in Is There and Item to Load Here?.

If you add a field like distance, you'll probably want to adjust the puller so that it's the AGV, not the process flow token. To do that, in Is There and Item to Load Here? change the Puller field to "token.agv" instead of just "token."

Note that in the latest version there's a bug that doesn't let you view list entries/back orders on Local Partitioned Load List, so it might be harder to debug because you can't see what's on the list. To get around this you can call the following for the entries:

createview("VIEW:/pages/tools/ListViewer", "MODEL:/Tools/ProcessFlow/AGV/Local Partitioned Load List>stats/globalInstance/list", "");

Unfortunately we don't have examples that use complex queries and prioritization, but the intent is to encourage users to implement custom queries as needed. This means adding any necessary fields to the various lists, including Local Partitioned Load List, Available AGVs (the list of agvs who have parked and are waiting to be activated), Parking Spots, Loaded Items, DropoffPoints, and NextLookForWork. Then once those fields are added, you can define sophisticated pull queries in any of the pull from list activities. This is the intent of the process flow, namely to give the user a lot of flexibility in configuring the rules, without having to add or remove activities or refactor the process flow.

That said, some of the things that I think might need customization more than just implementing pull queries:

1. The mechanism for activating parked AGVs is a simplistic heuristic. Right now, when a new load is added to the work list, it will first check if there's a parked AGV at the same LFW location as the load. If so, an AGV will be activated from that location. This logic is in the two Try Activating a Parked AGV activities. If, on the other hand, it doesn't find a parked AGV at the same location, then it will check if the number of active AGVs is less than the number of needed loads, and will activate an AGV if it is less. This logic is in the Do I Need Another AGV and Should I park? activities. This is somewhat simplistic. First, depending on the relative costs of having sitting loads vs active AGVs, you may want to have more sophisticated rules to balance active work vs AGVs. Second, the heuristic breaks down when AGVs can carry more than one load at a time. More AGVs will be active than are needed for the current work load. Additionally, the Should I park? decision could be smarter and try to spread parked AGVs out across the model, so that there's a better chance of an AGV being close when new work arrives.

2. Battery recharging is trivial and likely not true to real life. In the process it assumes that every park location is a recharge location, so the AGV recharges every time it's parked. I assume in real life situations there are specific recharge locations they need to go to for recharge. This would require some changes to the process for it to work right. Probably either a new RechargePoint connection type, or labels on the park points that says it's a valid recharge location, and then logic in either Should I park? or a whole separate section of logic to handle that decision.

3. AGV routing is very simplistic when there are branches in the NextLookForWork loop. When an AGV decides to go to a next look for work point, if there are multiple possibilities, it will simply do round robin. In other words, the first AGV to get there will go to the first NLFW option, the second will go to the second option, etc. Since this is yet another pull from list (Get Next Look for Work Point), you can prioritize which branch is best to go down with an ORDER BY in the pull query. However, in order to get the information you would need to make a good decision, there would likely need to be more data collection regarding how much work can be found down each branch. I'm not sure exactly how that would be done. I'll let users be creative :-). The other option is to avoid branches in the NLFW loop altogether. Here you could just use the LookForWork connection to connect the load locations back to the LFW point that the AGV would pass over. The AGV's NextLookForWork loop could thus be pretty simplistic, and the AGVs would look further ahead to find work so they don't have to branch on the NLFW loop.

This gets at a good question of balance of how aggressive you are in assigning AGVs early. Do you assign AGVs to loads very early, and risk the problem where the AGV is assigned to a load when it is still very far away, and another, closer AGV might become available after the assignment is made? Or do you wait until the last moment to assign AGVs, so that you can always assign the AGVs that are already in the area, with the risk that AGVs spend a lot of time wandering around not knowing what they will do next? An early-assignment strategy would use a lot of LookForWork connections, and very few NextLookForWork connections, meaning there are relatively few stops on the "I'm wandering around" loop, but each stop the AGV would look at a large swath of possible locations to pick up from. In a late-assignment strategy, there would be a lot of NextLookForWork connections, and few, or no, LookForWork connections.

I'm still waiting for the awesome user who will implement an alternative to this template's looping-looking-for-work mechanism. This would be a kind of look-ahead scheduling mechanism, where AGV work can be scheduled multiple operations ahead. There would be some heuristic to calculate how long it takes an AGV to travel to a location, and it would optimize for empty travel distance vs load wait time. But that gets into sequencing, which can be its own beast of a problem :-).

In the end, I hope that users who use this process flow will over time become confident enough in their knowledge of the process flow to be able to make the changes they need for their specific process. I know it's kind of a daunting beast to grasp at first, but hopefully the more people use it the more you'll feel comfortable with changing it.