3 ms·
> Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of requ
by sambellll 2mo ago
> Seems like the real reason it performed worse in this simulation is that when they implemented destination dispatch, they assigned an elevator at time of request, and had no system for reviewing and updated that assignment.
I don't think it's possible to have destination dispatch AND update assignment together, in the real world.
- If the user clicks floor 26 and you tell them to wait at elevator G, you can't really tell them to move to F if it's taking too long.
- But if you don't tell them an elevator to wait at, then you'd need them to run around what is possibly like 5-8 elevators to find which one is going to their floor? That's obviously not realistic.
So then you're going to just have them get in the first one that opens? But then that's just the same as an up/down button.
- richk449 2mo agoInteresting. I didn't realize that destination dispatch told the user what elevator to take at the time of request. (I've never used it.) Why not have active display above each elevator that says what floors it is going to when it opens?
- NetMageSCW 2mo agoBecause it doesn’t know that until after it has completed the trip?
- richk449 2mo agoThat explanation is entirely inconsistent with sambellll's statement that when the user clicks a floor, the display tells them what elevator to take, and that elevator is then locked into going to that floor. Also, I don't think that destination dispatch would work if the elevator didn't commit to going to the users's floor at the point the user got onboard. It may also stop at additional floors that weren't committed to when the user entered, and it may drop floors it was thinking of going to before it picked up the user (if the user onboard isn't going to those floors), but once the user gets onboard, that floor is a hard commitment.