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

[stayhometown]

Thank you for your response! I think elevatorbank closely resembles the actual operating mechanism of the elevator I’m trying to simulate. However (and I feel a bit sorry for asking so many questions😢), I realized that the stay time collected in my previous model was not reasonable. It seems that my location (floorspot) allows multiple people to arrive simultaneously, which causes the acquire action to happen very quickly. As a result, it looks like the operator is waiting at the elevator door, but in reality, they may have already left the waiting line.

I’ve modified the model into a new form, but now I’m not quite sure how the stay time is actually being collected. From my observation, as shown in the first image, at time 20.48, a stay time record appears. This stay time (5.91 seconds) seems to represent the time difference between the operator arriving at waiting line 1 and the elevator door opening.However, I don’t understand why, as shown in the second image, when the operator arrives at the second floor (and should have already left waiting line 1), the stay time data still gets updated.

How should I configure the model so that I can collect accurate stay time data?

What I want to collect is the time between entering the waiting line and the elevator door opening😓

By the way, may I ask why the operator's movement sometimes looks like it's gliding? Did I set something wrong?

[stayhometown]

Aside from the issues mentioned above, I encountered an new error while using the Statistic Collector, and I’m not sure how to fix it. The table contains the data I need (I want to collect the cumulative number of users for each queue), but an exception warning was thrown, and I don’t really understand what it means...

[moehlmann_fe]

The Waiting Line object is part of the People module and designed to work with activities from that module. A travel task will not cause the operator to be moved out of the waiting line object. In is moved into the elevator during the travel but then back into the waiting line (its previous parent object) when leaving the elevator. That is also the reason the animation is not working correctly. You'd need to use a "Walk" activity. It moves the operator back into the model as part of its logic.

With that said, a decent way to measure the wait time is to take measure how long it takes between the "traveler arrival" and "entry" event of the elevator bank. That value will include the time it takes the elevator to reach the floor, the door open time and the entry time. The latter two are fixed parameters of the elevator though, so you could adjust for them if needed.

[stayhometown]

Hi @moehlmann_fe ,

Hi, I expanded my small model (“elevator_7”) into the main model that I actually need to simulate. However, the behavior is not working as expected. My questions are:

1. In my scenario, when someone is waiting in front of the elevator and the elevator is already full, I still want the elevator to stop at that floor and open its doors. The person should then realize they cannot board and be reassigned to a new elevator (as shown in video1). This works correctly in my small model, but it does not work in the main model (as shown in video2). The process flow logic is essentially the same in both models, so I don’t understand why the behavior is different.

2. In my small model, there is also a situation where an operator does not enter the elevator even though the elevator is available (as shown in video3). I don’t understand why this happens?

[stayhometown]

Here's my models😢

[moehlmann_fe]

The elevator in video 2 is not stopping because it is going up while the waiting person wants to go down. This is generally how real elevators would behave as well. If you want to stop regardless of direction, use a 0 for the direction in the "canStop" method in the request query.

In the third video you can see that the operators travel to the other elevator bank instead because that is the overall shortest route to their destination. You can force them to use the elevator in front of them by surrounding the area with one-way dividers, so the elevator is the only way to leave the area.

[stayhometown]

Thank you for your response. I didn’t realize they were supposed to move in different directions.😂

I also noticed that because the operators are standing in a waiting line, it seems like only one elevator gets called at a time. But in real situations, two elevators might be called simultaneously—for example, when the first person in line wants to go up and the next person wants to go down. I’m not sure whether my current model supports this scenario, or if I need to add additional logic.

I considered putting the elevators into a list and having the operators pull an available one, but I’m not sure what happens when an elevator can serve two people. Would it cause an issue where only one operator can use the elevator at a time, leading to wasted resources?

I’m worried that I might end up needing two elevatorbank instead. I’d really prefer not to write a custom elevator-selection logic, especially since the two elevators are placed very close to each other, and I’m afraid operators might walk to the wrong one. So I’m trying to avoid doing that if possible... 

[moehlmann_fe]

That's what the "Wait In Line" activity does. It holds the token until the respective person reaches the front of the queue. The queue only moves forward when a person leaves (exits) the line. Because the people are not doing so until they enter an elevator (which I mentioned a while ago when you asked why the people appear to be "sliding" sometimes), the activity prevents more than one elevator request existing at the same level.

The simplest solution would be to just not use the Wait In Line activity and use Walk instead.