I have two forks controlled with A* and I want to keep the distance of the forks in 3 meters if it gets close. I plan to use the Agent, however when I do that, the fork keeps going around the target slot and never arrives at target position. How do I set in this case? Do I use proximity?
Hi @Ryosuke S, was Jeanette F's answer helpful? If so, please click the red "Accept" button at the bottom of their answer. Or if you still have questions, add a comment and we'll continue the conversation.
If we haven't heard back from you within 3 business days we'll auto-accept an answer, but you can always unaccept and comment back to reopen your question.
Yes, I would use proximity.
Here is a video that goes over Agent systems well. Minute 12:02 goes over what you might be specifically looking for with the Agent Proximity Behavior, but that example model starts on minute 7:49.
Here is the post with the example models shown in the video for you to reference if needed.
@Jeanette F I did go though the video and the samples you raised for me, but I don't know which should I use to get to the goal. Why would you say you would use proximity? I set proximity, but forks gets closer than 3m which I set to avoid.
You used the code from the broad phase of the example model. The broad phase only was meant to slow the AGV's. The narrow phase will stop the AGV's.
Here is your model with the narrow phase code modified so the transporter furthest from the queue is the one that stops.
I notice that when a transporter is stopped it does not have an allocated node on the A* grid until it resumes its previous task. This makes it possible for the moving transporter to drive over the other. I am still looking for solutions but decided to go ahead and share what I had intended you to use from the example model.
floorstorage-oneway-agent2_1.fsm
@Jeanette F Thank you for your support. Yes, I have noticed that transporter drive over the other. I hope there is a solution to prevent this. Also, I noticed that the divider is being ignored in certain situation. I'm a little puzzled with this behavior.
I think this would be better done by listing the bays as a shared resource to limit access and using kinematics / custom offset travel.
Hello @Ryosuke S,
There was a simple solution to the stopped traveler becoming inactive on the AStar grid. If you open the AStar Navigator Properties, go to the Behavior tab and deselect "Ignore Inactive Members". I also changed the code so that the transporter closest to the queue was the one that stopped. This prevented most blocks.
As for the Transporters ignoring the barriers, I think this was being caused by the preferred paths. Once I got rid of the preferred paths, the nodes in the model showed that they would not allow travel through the barriers.
The model is still not perfect. A rerouting code needs to be written for the cases when a transporter is blocked. Here is a post that might be helpful with that.
16 People are following this question.
© 1993- FlexSim Software Products, Inc. All Rights Reserved.
FlexSim is a fully 3D simulation software environment. FlexSim can be used to simulate any process in any industry.
FlexSim®, FlexSim Healthcare™, Problem Solved.®, the FlexSim logo, the FlexSim X-mark, and the FlexSim Healthcare logo with stylized Caduceus mark are trademarks of FlexSim Software Products, Inc. All rights reserved.
