How to Prevent Collision Between Two Cranes While Handling Items in a Shared Central Area

[gjm504]

Hello everyone,

While configuring a model based on a file I downloaded from the forum, I ran into an issue that I hope you can help me with.

In my layout, I have racks on both sides and two cranes that are each responsible for their own side. However, items are generated at a central position between the two racks, and both cranes need to access this shared central zone to pick up items.

I would like to know how to configure the cranes so that they can each load items from the central area without colliding with one another. Is there a recommended way to implement this kind of coordination logic (e.g., based on position or task priority)?

Alternatively, if collision avoidance between the two cranes is too difficult or unreliable to implement, I am also considering dividing the central zone in half, assigning each crane to only operate on its respective side of the center point. If there's a good way to configure that logic in FlexSim, I’d love to hear suggestions or examples for that as well.

Any suggestions would be greatly appreciated.
Thank you!

[moehlmann_fe]

Check out the post linked below (plus the follow-up port dealing with an oversight in the original logic). It deals with the same topic. You would need to adapt the logic that assigns a bayID to the ASRS to also handle the station in the middle but the general structure of the flow should work well for your case.

https://forums.autodesk.com/t5/flexsim-forum/double-stacker-crane-problem/m-p/13710815#M96981

https://forums.autodesk.com/t5/flexsim-forum/double-stacker-crane-deadlock-problem/td-p/13728355

[gjm504]

I tried the suggested method, but when the port is located in the middle, the cranes collide with each other. At a certain point, tokens start to pile up excessively, and the system stops moving.
Is there a way to resolve this issue?
For reference, I’m using millimeters as the unit.

@moehlmann_fe 

[moehlmann_fe]

As I said, you need to update the upper part of the flow to assign a fitting "DestBay" to the token (and thus ASRS) when an item is loaded from or unloaded to a queue. The example uses 0 or 21, since the rack in that model has 20 bays and the queues are positioned at the edges. If the queue is in the middle, assign the middle bayID as the "DestBay" in those cases.

[gjm504]

Thank you again for your previous response.
I tested both situations using the example file you provided, but encountered the following issues:
In the central avoidance scenario, Crane with ID 2 picks up an item but does not return it, and both cranes tend to store items in only one of the two racks.
When items are picked from the ends (left/right), a similar issue occurs: items are stored and returned using only one rack, and over time, one of the cranes stops functioning due to an error.
I attempted to apply a Type value to the racks in order to resolve the issue, but it didn’t work as expected.
Could you please advise how to fix this?

@moehlmann_fe 

[moehlmann_fe · Accepted solution]

Where items are send to is controlled by the Send to Port field of the queues/racks and also by whether a rack accepts and item based on its Pull Requirement setting. The queues at the ends of the racks are currently set to "First Available". And the racks assign slots based on labels and pull an item that could be assigned to a slot. Since both racks have the same bayIDs and levelIDs, in theory both can receive the item. So they go to the first one.

The queue in the center uses a condition that sends items with a bayID smaller than 10 to the first rack (Rack4) and others to the second (Rack3). The same condition is also applied to Rack3 and 4, but they only have one output port, so items in bays > 10 simply stay in the racks.

What you wrote in the Pull Strategy of Rack1 and 2 is not valid (which is why you see a compiler error when the model is reset). The Pull Strategy decides from which port to receive an item next. There is no "item.Type" to base this decision on, since this decides where to check if there are any items to pull.

To have items go to different racks depending on type, use "Port By Case" in the Send to Port field of the queues.

The error that stops one of the ASRS at some point comes from having some of the slots at the edges of the racks be unstorable. But items can still receive labels that match them to those slots. When the code tries to assign the items to the slots, the error occurs and blocks the transport from resuming. (There is no check whether the slot is storable in the "By Bay, Level, Slot ID" option of the Slot Assignment Strategy. It assumes the user would only assign valid values.)

[gjm504]

Thank you very much! The issues I was experiencing have all been resolved.
Your response was extremely helpful and provided great insight. I really appreciate your support.