question

Alessio Merlo avatar image
0 Likes"
Alessio Merlo asked anthony.johnson edited

AGV network: bug or process flow error?

Hi,

while developing a model, today I run into an issue.

I isolated the issue in the attached model (bug.fsm). Simply:

1. a process flow controls a TE;

2. TE loads two boxes from the model;

3. when the TE ends the second loading, AGV network returns an exception.

I found a workaround extending the agv network (no_bug.fsm), but I am not sure if it is a bug or my error.

Could you help me?

Thanks in advance!

bug.fsm

no_bug.fsm

FlexSim 20.1.0
agvflexsim 20.1.0trailer
bug.fsm (34.0 KiB)
no-bug.fsm (34.0 KiB)
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

2 Answers

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

This is by design. It is, in essence, the same issue as the one shown below.

When the AGV network resolves travel paths for agvs with trailers, it tries two options. First, navigate from the front of the AGV (the center of the AGV's front trailer, which in this case is the AGV object itself). Second, navigate from the back of the AGV (the center of the back trailer). In order for a given option to be valid, the navigation must proceed away from the body of the AGV. In other words, the "back" navigation option must proceed backward to be valid, and the "front" navigation option must proceed forward to be valid. If neither the front nor the back navigation option is valid, then this is a navigation error, because all possible options would force the train to travel in on itself.

When your train pulls into the spur, then attaches a trailer onto its back, its back now runs onto path 1, or at least it runs past the end of the path that would connect onto path 1. From this standpoint, all navigation options going to control point 2 would force the train to travel in on itself. Therefore, it is an error. It is the user's responsibility to make sure that these situations do not happen, by pulling fully into spurs, including any distance necessary for attaching new trailers.


1588872810373.png (65.2 KiB)
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Phil BoBo avatar image
2 Likes"
Phil BoBo answered Phil BoBo commented

@Alessio Merlo

In bug.fsm, when the TE loads the second box, the back box is on the one-way Path1. The TE needs to go backwards onto that path in order to get to ControlPoint2, so it is trying to calculate its route from there, which it can't go backwards on that path because it is one-way.

In no_bug.fsm, when the TE loads the second box, the back box in on the two-way Path7. The TE then calculates its path from that point and successfully finds a route to ControlPoint2.

While it looks like the TE is going backwards on Path1 in no_bug.fsm, it is actually just pushing its trailers towards oblivion, ignoring the length, direction, and accumulation of Path1. In the first case, it is actually trying to go backwards on Path1 because the last trailer is on Path1.

This is quirky, but by design.

The attached model shows what I mean by "pushing its trailers towards oblivion."

no-bug-oblivion.fsm


no-bug-oblivion.fsm (34.7 KiB)
· 3
5 |100000
Toggle Comment visibility. Current Visibility: Viewable by all users

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

Phil BoBo avatar image Phil BoBo ♦♦ commented ·

Looking closer at this, my first explanation might only be partially correct. Even if you change Path1 to be two-way, it still can't calculate a route to ControlPoint2.

@anthony.johnson, you might want to look at this to determine whether we should do anything about it.

0 Likes 0 ·
Alessio Merlo avatar image Alessio Merlo Phil BoBo ♦♦ commented ·

Thanks @phil.bobo!

One more information: I noted in my original model that the transporter lost the control point allocation when he reached the destination.

Before loading (allocation is active):

After loading (allocation is lost):

In the model, where I was able to reproduce the issue, the behavior doesn't happen. I don't know if they are related or could help you to debug the problem.

I will wait @anthony.johnson support!

Thanks!

0 Likes 0 ·
before-loading.png (105.8 KiB)
after-loading.png (80.5 KiB)
Phil BoBo avatar image Phil BoBo ♦♦ Alessio Merlo commented ·

@Alessio Merlo, that sounds like a separate issue. We would need a sample model demonstrating that behavior to debug why it is happening.

Because this issue has a reasonable workaround (and might be by design), I'll add a case to the dev list to look into this later. I'm not sure how soon Anthony will be available to look into this in detail.

0 Likes 0 ·