Why does AGV only claim the area when it continues?

Question

question

Patrick Zweekhorst asked Oct 15, '21 Ryan Clark commented Nov 1, '21

Why does AGV only claim the area when it continues?

Hi,

Attached is an example model where AGV1 needs to wait on AGV3 before it can continue to the final destination. Before AGV1 needs to wait is passes a control area. The AGV does not claim this area when traveling through it (I guess because of off set travel). The strange thing is that when the AGV can continue to travel (at time 18.25) it does claim the area. In this model that is fine, but in a model, I posted as a private question this creates a deadlock because another AGV claims the area before AGV1 does. The other AGV is not able to continue because AGV1 is in the way.

Thank you for explaining the AGV behavior,

Patrick

AgvTest.fsm

Software Version:

FlexSim 21.2.3

agv control area deadlock

1634299601374.png (172.0 KiB)

agvtest.fsm (42.1 KiB)

Answer 1 · 2021-10-29T20:24:38Z

Ryan Clark answered Oct 29, '21 Ryan Clark commented Nov 1, '21

Hi @Patrick Zweekhorst,

I made a few modified versions of your model to test out a few different things.

In your original model, I did observe that AGV1 did not acquire the Control Area until it was continuing from there. It appears that AGV1 didn't acquire the Control Area until it became unblocked by AGV3. But there was no deadlock in your original model that I noticed: agvtest_original.fsm

When letting only AGV1 run, the same situation occurs, which indicates that it doesn't have to do with being blocked/unblocked. AGV1 only acquires the Control Area once it has acquired its next location. In this case, that's the path connection just ahead of the Control Area: agvtest_onlyAGV1-rc.fsm

However, if I add a Control Point anywhere in between the Control Area and the destination (Control Point 4), then AGV1 acquires the Control Area at the same time it acquires the new Control Point. But this doesn't work when the next Control Point is the destination for the AGV Travel activity. You can try changing the destination to the closer Control Point or moving the new control point after the destination, but then the same issue occurs that was happening before I added the new control point. The same rule applies if you re-include AGV3; AGV1 acquires the Control Area whenever it is able to acquire its next control point and/or path point: agvtest-rc-plusCP.fsm

I also made a modified version of your model that incorporates the logic that I assume you're trying to get. It involves Control Points before and after the Control Area for all AGVs. It seems like that shouldn't be necessary considering what the Control Area is meant to do, but I'm not sure. agvtest-rc-final.fsm

It definitely seems like this is some sort of bug or unimplemented feature on the Control Area. I'll submit a case to the dev list, so they can take a look at it.

I hope this helps! Best of luck!

agvtest-original.fsm (42.1 KiB)

agvtest-onlyagv1-rc.fsm (42.3 KiB)

agvtest-rc-pluscp.fsm (42.5 KiB)

agvtest-rc-final.fsm (42.5 KiB)

· 3

Patrick Zweekhorst commented · Nov 01, 2021 at 01:26 PM

Hi @Ryan Clark ,

Thank you looking into this and writing such an extensive answer. The control points before the area are needed in the model, because those are possible waiting positions. The control points after the area are indeed not needed, they were only there to try and create the correct situation.

Setting this on the bug lists sound good. Hopefully someone is able to fix this for future versions.

Thanks again.
Patrick

0 ·

Ryan Clark Patrick Zweekhorst commented · Nov 01, 2021 at 07:23 PM

Hi @Patrick Zweekhorst,

Some aspects of what I mentioned are not actually bugs. According to https://docs.flexsim.com/en/21.2/WorkingWithTasks/AGVNetworks/BuildingAGVLogic/#settings, the AGV doesn't acquire the Control Area by itself. It attempts to acquire the next control point and only does so if it can acquire all control areas along the path to that control point. So, the control areas are secondary controls on AGV movement.

That said, your model does still demonstrate an apparent bug since TaskExecuter1 and TaskExecuter2 do not attempt to acquire the next control point along their path and therefore fail to acquire the control area also: agvtest_original-bug.fsm (I submitted this as a separate bug report).

Oddly enough, removing the intermediate control points actually fixes the problem since the TaskExecuters attempt to acquire the control area but are unable to do so until it is deallocated by a previous TaskExecuter. agvtest-rc-bugfix.fsm

As a note to you, you can often work around problems like these by adding more intermediate control points in addition to control areas. As the documentation shows, control areas don't really provide any control on their own. You have to use them in conjunction with control points for them to be useful as a supplementary control tool.

I hope this helps and makes sense. Let us know if you have more questions!

Thanks to @Phil BoBo for pointing out my errant assumptions about the correct behavior of control areas.

1 ·

agvtest-original-bug.fsm (42.1 KiB)

agvtest-rc-bugfix.fsm (42.1 KiB)

Ryan Clark Patrick Zweekhorst commented · Nov 01, 2021 at 04:32 PM

You're welcome @Patrick Zweekhorst! I'm glad to help!

0 ·

question