question

Jim Counts avatar image
1 Like"
Jim Counts asked Joerg Vogel edited

TE process flow template list sorting?

Hello all,

I'm looking for some direction regarding the use of the Flexsim provided Task Executer process flow for AGV's. I love the elegance of the architecture, and the broad use application, but I'm struggling to control the work on the AGVWork global list appropriately.

Basically, I have several TE's subscribed to the logic, with the looking for work, etc. all set up and everything works fine....but I'd like to influence what job an AGV gets based on age, proximity to the instance TE, etc. which are all default dynamic attributes on the entries of the before mentioned AGVWork list....but the plumbing of what happens with the internal partitioned global list is where I'm getting lost. It appears as though the moment a job hits the list it is instantly pulled from the list and assigned to a partitioned internal Global list based on criteria....but when I try to do a SQL sort by age query, it doesn't seem to affect how the jobs are handled.

Anyway, I'm sure I could hack around in the template and get something to work, but I'd rather work with how the template was designed if possible as to not compromise other logic that I may not be using yet. Any thoughts or demo models of controlling work by attributes on the list with multiple AGV's at play would be greatly appreciated. Thanks!

FlexSim 18.2.0
agv process flowlist sortinginternal listsagv process flow prioritylook for work
· 2
5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Jim Counts avatar image Jim Counts commented ·

Thanks for the reply.

As is usually the case, I was able to find a kludge to get things to do what I want… but I wanted to understand how @anthony.johnson (I think he wrote the AGV PF template) intended the structure to be used… so firing up a new FlexSim environment and looking at the TE process flow for AGV’s is the starter model.

The question is: Where or how with that structure would I put the SQL sort for the job list in order to influence the priority of various jobs?

I could do a call later this week if someone has some time… let me know!

1 Like 1 ·
Ben Wilson avatar image Ben Wilson ♦♦ commented ·

Hi @Jim Counts,

So sorry, looks like we dropped the ball on your question. Are you still looking for some guidance?

Please reply back to let us know how we can help. A sample model we can help edit might be the best way for us to directly comment on your questions.

Or a call to our office might be the way to go to discuss in person what you've tried and where you're stuck.

Sorry again for the late response.

0 Likes 0 ·

1 Answer

·
anthony.johnson avatar image
2 Likes"
anthony.johnson answered anthony.johnson edited

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.

5 |100000

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 12 attachments (including images) can be used with a maximum of 23.8 MiB each and 47.7 MiB total.