AGV REDIRECT AFTER STOP-RESUME COMMAND

[fapicella]

[ FlexSim 22.0.1 ]

Hi,

I noticed this behavior in a model.

There is an AGV that allocates a CP (in the picture the CP2). While it is travelling, it breaks down.

At the same time another AGV allocates the same CP. It will wait for the first AGV to reasume and it will allocate the CP2 first.

I expected that the first to allocate the CP2 would be the first AGV not the second.

I notice that on reasume the allocations of CP2 change.

As workaround, also reading the forum question Control area is released with AGV still inside - FlexSim Community , I have insert a control area in the intersection.

Could the problem be that the control area is considered a piece of path differently from the CP?

In the first case is the redirect command executed in the background?
Could it be a bug?

I attach the example.

TestModelAGV.fsm

[joerg_vogel_HsH]

If you call a stop on a taskexecuter, then internally a preempting tasksequence is created for him. The preempted Tasksequence gets back into the tasksequencequeue node.You assume there exists an mechanism of an suspended linear process. That is not the case. When a tasksequence finishes then a new cycle of code execution starts. Then there is a chance that a later process jumps in front of former earlier process, just because the sequence has been changed by ending a tasksequence.

[philboboADSK · Accepted solution]

This isn't executing the redirect() command in the background. This is calling stop() and resume() on the agv.

When you stop() the agv, it preempts him away from his current travel task. When you resume(), he starts a new travel task.

When you redirect(), it does a similar thing: it preempts his current path and calculates a new path.

The major difference between stop/resume and redirect is that there is a larger gap of time between the stop and the resume. When redirecting, the preemption and new travel path are calculated almost immediately.

This looks like a bug. There's code in the AGV module to delay deallocation until the AGV is resumed, and there's code when resuming that attempts to not deallocate if the allocation point is still on the new travel path, but this code seems to be incorrectly deallocating the control point and reallocating it in this particular configuration despite the new travel path including the control point. I'll add a case to the dev list.

In the meantime, as you discovered, you can work around this bug by adding a control area to the intersection, which is properly not being deallocated when the AGV is resumed.

[Matthew_Gillespie]

@Fiorenzo A This issue is fixed in 23.0.6 released today.

[fapicella]

Thank you!