Something broken in code-built AGV network

Question

question

Mischa Spelt asked Apr 2, '20 anthony.johnson commented Apr 2, '20

Something broken in code-built AGV network

I've built a simple AGV network from code (using createinstance to create some paths, setting their variables and then calling finalizeSpatialChanges). It looks OK, with the directions of the paths and the transfer points between them. I put two control points on the first section of the path and want to send an AGV from ControlPoint1 to ControlPoint2 to ControlPoint1, but for some reason the second leg cannot find a path.

Even when I put ControlPoint2 all the way at the end of the loop, right before ControlPoint1, it seems that the path from 2 to 1 is somehow broken.

It may be related to the fact that my paths and CPs are in a custom container, or I may have just forgotten to call a certain behavior function somewhere... but at the moment I cannot even figure out why the network seems broken, so I'd appreciate any help there.

agvnetworkexample.fsm

Software Version:

FlexSim 20.0.0

agv network

agvpathbroken.png (58.1 KiB)

agvnetworkexample.fsm (31.6 KiB)

Answer 1 · 2020-04-02T13:59:32Z

anthony.johnson answered Apr 2, '20 anthony.johnson commented Apr 2, '20

Whenever you place a control point EXACTLY on top of a transfer between paths, you are in muddy water as far as how the path will resolve routing, especially if the path is one way. The path must organize its path points into an ordered set of points. When it's a one way path, any points that are later in the set cannot reach points that are earlier in the ordered set, no matter how close they are together. When you place a control point EXACTLY on top of a transfer, you are essentially leaving it up the the path(s) to arbitrarily decide which path the control point is bound to, and where in the ordered set of points it should be placed. In your case the straight path decided to place the control point "before" the transfer point.

Thus, since the control point is earlier than the transfer point along the straight path, and the straight path is one way, there is nothing that can reach that control point. You need to force the control point to be after the transfer point by placing it some small distance along the path.

I can look into making different routing decisions for points that are exactly on top of each other, but I can't guarantee that such improvements will ultimately come to fruition, as the routing mechanism is pretty complicated already.

cppointbefore.png (38.5 KiB)

· 2

Phil BoBo ♦♦ commented · Apr 02, 2020 at 02:32 PM

In short, put your control points on a path, not a transfer between paths.

0 ·

anthony.johnson ♦♦ commented · Apr 02, 2020 at 10:20 PM

Mischa, I've added a small change for 20.1 that will "favor" control points being put on the "better" side of transfers if you place a control point at the very end of a path. This doesn't solve the issue if you place a control point on top of a transfer in the middle of a path, but it should solve it for your case, and hopefully the majority of other cases.

0 ·

question