question

Ryusuke T avatar image
0 Likes"
Ryusuke T asked Ryusuke T commented

About Kiva system model sample

I'm studying by looking at the sample model below.

https://www.youtube.com/watch?v=3AQ-cjOS9tY


There is something I don't understand about "Dynamic Barrier Management" introduced in this video.

I think the custom code "SetBarriers" controls the barriers, but I don't know how to control them.

Specifically, I think that slotItems is set as a barrier target in "token.Barriers = items;". Is this perception correct? If so, where is this "token.Barriers" used?

43593-1630914161065.png


Please give me advice.

FlexSim 21.2.0
flexsim 21.2.0barrierskiva
43593-1630914161065.png (33.4 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.

1 Answer

Felix Möhlmann avatar image
1 Like"
Felix Möhlmann answered Ryusuke T commented

Here's how I understood how it works. (Based on the video, he talks about this at around the 25min mark)

The return value of the "On A Star Calculate Path" event apparently is an array of objects that block travel. This array is then seemingly used to determine which grid nodes the task executer can travel on when the actual path is calculated.

In the "Event-Triggered Source" the "Will Overwrite Return Value" is checked. Meaning instead of returning the default value, the value defined in the "Finish" activity will be used. (I don't know what the default value would be, the event is not listed under task executer events in the documentation)

1631105273428.png

In this case, that is the array token.Barriers. This contains, as you guessed, all items currently stored in the floor storage. This makes the AGV/Kiva robot avoid grid nodes blocked by other carts.

I tested it in this sample mode. I return the processor in the event and the task executer is indeed avoiding it. If you uncheck the overwrite option in the event-triggered source, the task executer will drive directly through the processor.

OnAStarCalculatePathTest.fsm

I'll leave a mention of @anthony.johnson here in case I got something wrong or there is more useful information to add.


1631105273428.png (7.8 KiB)
onastarcalculatepathtest.fsm (36.2 KiB)
· 2
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.

anthony.johnson avatar image anthony.johnson ♦♦ commented ·

Thanks Felix! You're spot on. Sorry there's no documentation on this as we still need to find a place to put the documentation for these A*-specific TE events.

The following pseudo-code represents the logic that is happening under the hood:

Variant returnVal = FIRE_EVENT(AStarOnCalculatePath, ...);
Variant userBarriers;
if (returnVal.type == VAR_TYPE_ARRAY || returnVal.type == VAR_TYPE_NODE)
    userBarriers = AStar.navigator.addDynamicBarrier(returnVal, 1);
AStar.navigator.calculatePath(...);
if (userBarriers.type != VAR_TYPE_NULL)
    AStar.navigator.removeDynamicBarrier(userBarriers, 1);

So it's essentially getting back the return value of the event, and if it's a non-trivial return value, it applies that return value as one or more temporary dynamic barriers, applied just for this instance of calculating the path.

Technically you could have done this on your own by listening to the event and calling addDynamicBarrier() yourself, then breathing and calling removeDynamicBarrier(), but I figured might as well let you have the A* navigator do it for you.

1 Like 1 ·
Ryusuke T avatar image Ryusuke T commented ·

@Felix Möhlmann

Thank you for the easy-to-understand explanations and samples. These have been very helpful.


@anthony.johnson

Thank you for explaining the internal logic. This was exactly what I wanted to know.


I'm very grateful to you two!

0 Likes 0 ·