Location Acquiring Issue

[stayhometown]

Hi, I have two questions regarding location aquirement in my model.

My model includes two elevators, and I want the operator to choose which elevator to use based on a probability, deliver the item to an upper floor, and then return to the ground floor using the same elevator.I also want to use a single subflow for both upward and downward trips.

My current approach is: the operator walks to the waiting line in front of the elevator, acquires the floor spot of the current floor, takes the elevator, and then moves to the floor spot of the target floor.

Here are my problems:

1.Things works fine when going up. However, when going down, something seems to go wrong. As shown in the video, the operator correctly enters the waiting line on the second floor. I expect it to acquire Floorspor2 (which is the current floor), but instead it acquires floorspot1which is the target floor).I have no idea what may cause the problem.

2.I want to count how many people have passed through a  floorspot, but I can't directly get the throughput of the floorspot by the dashboard. Is there a way I can achieve a similar result?

Could anyone help me fix the problem?

[moehlmann_fe]

1) You need to uncheck "Same As Last Acquired". The tokens all use the labels of their parent/grand-parent token, so its the same label that gets assigned the location each time.

2) You could do this with a simple Process Flow that counts how many tokens enter the Delay activity, split by their "Locations" label value.

[stayhometown]

Thank you for your reply, yet I still have one more question😢. When I tried moving Floorspot2 back to the front of the elevator, there seemed to be a synchronization issue between the operator and the token. The operator is supposed to start the delay only after reaching Floorspot2, but the delay action begins while they are still physically at Floorspot1. Do you know why this happens? (I moved Floorspot2 from the position in Image 1 to the position in Image 2, and that’s when the synchronization issue appeared.)

[moehlmann_fe · Accepted solution]

This seems to be a quirk of the A* routing. I built a small test model in which there are three "Bridge" paths connecting the ground floor to an A* grid higher up. All three paths end at the same position on the upper floor. Three operators are placed in such a way that each will use a different path to reach Queue2.

  

When we run the model, only Operator2 actually traverses the path up to the higher floor. My assumption is that this is connected to the travel threshold of the queue. From a top down perspective we can see that the start points of the two paths that are not traversed lie within the travel threshold area of the queue (in the x-y-plane). It seems that the navigator deems it unnecessary to traverse the bridge path if the travel threshold is already reached, regardless of height difference.

To solve this you can use a "Travel to Location" activity and specify the coordinates the operator is supposed to travel to (or use the "Walk" activity which internally does the same). Then the travel threshold of the queue is not used.

[stayhometown]

Thank you for your detailed explanation, it really helped me a lot!

[stayhometown]

Hi @moehlmann_fe , I’d like to ask an additional question about the ElevatorBank😅

If, like in my model, one ElevatorBank contains two elevators, does that mean they share a single control system? (Or in real-world terms, does it mean these two elevators share the same call button panel?)

The real situation I want to simulate is that each of my two elevators has its own control buttons, so I’m not sure whether using a single ElevatorBank would cause inaccuracies.

Should I instead use two separate ElevatorBanks?

P.S. With my current setup, I’m also not sure whether two ElevatorBanks placed so close together would still allow for efficient idle elevator control.

[moehlmann_fe]

Elevators in the same elevator bank object work independently if you don't modify the logic. The behaviour is governed by the Request Pull Query. By default an elevator will pull the closest request that is not assigned to itself and no other elevator as the next target location. You should be fine using banks with multiple elevators. As you say, placing multiple elevator banks close to each other can make it tricky to get the people to use the one you want them to.

See the linked post for an example of how this logic can be modified.

https://forums.autodesk.com/t5/flexsim-forum/elevator-bank-logics/m-p/13488014