Check if there are any unexpected errors
As long as all transport tasks can preempt the idle loop travel tasks, I don't see how those could cause issues.
In regards to achieving a higher throughput I can point out some possible general improvements. But since only you know the ins and outs of the model and process, you will have to judge whether they can be applied or not.
- Set the end speed in the idle loop travel tasks to "TaskExecuter.MaxEndSpeed". This means the task ends upon pre-arrival at the destination and the AGV does not need to come to a stop. This can improve the general flow of the vehicles.
- When more than one task is waiting for an AGV to pull, the oldest one gets to pull it. It might make sense to make this distance based, so that the AGV will do the closest task first. This can however lead to tasks at outer stations to wait longer for an AGV, so it's not necessarily a purely positive change.
- You could try to employ predictive logic. Don't wait until an item actually finishes processing. Instead calculate when it will and dispatch an AGV some time beforehand to decrease the delay between an AGV being requested and it arriving at the object. This does have its downsides though. If breakdowns can occur, an AGV might be dispatched but then the process doesn't finish due a failure. Something like that would have to be detected and handled.
I can also offer an example that showcases a different approach of how to model an "idle loop". It works very similar to the AGV Process Flow template. But instead of managing the entire transport, the AGV flow is only responsible for sending the AGVs along a NextWorkPoint loop and making them available to be pulled by tokens in another Process Flow depending on their location. This allows for more control over where an AGV needs to be in order to be eligible for a given task. Doesn't mean that it will work better than the current logic though.
