Store each floor request independently, then summarize pending calls above, below and at the current floor. Keep the dispatch direction while requests remain ahead, and define a separate starting rule for idle calls on both sides. Request scheduling must remain separate from motion and safety control.
Keep each floor request in its own stored bit, then summarize whether requests exist above, below or at the current floor. Elevator call direction logic needs those summaries plus a remembered dispatch direction. Comparing the current floor with only the latest button press loses the information needed to serve several requests. This article explains that request-selection model only. It does not provide motion commands, door control or a complete passenger elevator controller.
Define the request data first
For a 16-floor example, number the floors from 0 through 15. Use R0 as the current-floor value and B0 through B15 as independent pending requests.
| Data | Meaning | Example |
|---|---|---|
R0 |
Valid current-floor reference supplied by the complete controller | 9 |
B0 through B15 |
One pending request per floor | Requests at 0, 3, 6, 7, 11, 12 and 15 |
| Dispatch direction | Remembered preference for serving requests | Up, down or idle |
| Service confirmation | An event authorizing completion of a particular request | Supplied by the complete controller |
The dispatch direction is scheduler state. It is not a motor command, a measurement of movement or permission to travel.
The meaning of R0 also needs a written definition. A last-passed floor, a destination floor and a confirmed landing position are different things. The comparison logic below assumes a valid floor reference at a dispatch decision point. It does not determine physical position between landings.
Store simultaneous requests independently
A new request for floor 12 must not erase a pending request for floor 3. Each floor bit records its own outstanding service request.
The request-handling rules are:
- Set the bit associated with an accepted floor-selection event.
- Leave other pending bits unchanged.
- Clear a floor's bit only when the complete controller supplies the defined service-confirmation event for that floor.
- Keep request acceptance separate from direction selection.
Do not make the requests mutually exclusive. An arrangement that replaces the previous selection with each new selection cannot represent several outstanding calls. Applying XOR between an incoming request and its stored bit would also toggle the request rather than reliably record it.
Holding a request across program scans is not the same as restoring it after a power interruption. Define restart behavior separately. Do not assume every stored request should automatically return after a restart.
Also define what happens when a new request and a service confirmation for the same floor arrive in one evaluation cycle. The result must follow an explicit event-ordering rule, not incidental program execution order. Input event handling should distinguish a genuinely new selection from a button that remains pressed.
Summarize requests above, below and here
Evaluate every pending bit against the same current-floor snapshot. The three useful summaries are:
- Above: at least one pending floor number is greater than
R0. - Below: at least one pending floor number is less than
R0. - Here: the request bit for
R0is set.
These are Boolean summaries, not counts. Five calls above the car still produce one true Above result. You can calculate them with comparisons and OR operations across the floor requests.
At floor 9, the example separates like this:
| Summary | Pending floors contributing to it | Result |
|---|---|---|
| Above | 11, 12, 15 | True |
| Below | 0, 3, 6, 7 | True |
| Here | None | False |
A request at the current floor belongs in neither Above nor Below. Handle it through the defined current-floor service process. Equality alone is not service confirmation and should not automatically clear the bit.
If the floor reference is invalid or outside the defined range, mark the direction evaluation unavailable and report that condition to the complete controller. Do not invent a floor value to keep the calculation running.
Preserve direction while requests remain ahead
For a simple collective sweep, keep the dispatch direction while pending requests remain ahead in that direction. Consider the opposite direction only when the current sweep has no remaining requests ahead.
| Remembered dispatch direction | Request summaries | Next dispatch preference |
|---|---|---|
| Up | Above is true | Keep up |
| Up | Above is false and Below is true | Select down for the next sweep |
| Down | Below is true | Keep down |
| Down | Below is false and Above is true | Select up for the next sweep |
| Idle | Only Above is true | Select up |
| Idle | Only Below is true | Select down |
| Idle | Above and Below are true | Apply the documented starting rule |
| Any | Neither Above nor Below is true | No travel request from these summaries; handle Here separately |
Evaluate direction changes only at decision points defined by the complete controller. A change in these summaries is never permission to reverse a moving car.
Starting from idle with calls on both sides requires an additional policy. Possibilities include a fixed starting preference, the oldest accepted request or the nearest pending floor with a defined tie-breaker. These are different service policies. The request bits alone do not tell you which one to use.
If the policy depends on request age, store timestamps or ordering information as well. One Boolean bit per floor cannot preserve arrival order.
Work through the floor 9 example
With requests at floors 0, 3, 6, 7, 11, 12 and 15, both Above and Below are true. That does not identify one uniquely correct starting direction.
Assuming no new calls, no special operating modes and a service confirmation at each listed stop:
- With an upward dispatch preference, the request order is 11, 12 and 15, followed by 7, 6, 3 and 0.
- With a downward dispatch preference, the request order is 7, 6, 3 and 0, followed by 11, 12 and 15.
- From idle, the documented starting rule decides which sequence begins.
Once a direction is selected, the nearest pending floor ahead is the next candidate destination in this simplified model. In the upward case, that is floor 11, not floor 15 merely because it is the highest request.
After confirmed service at floor 11, clear only B11. Requests at 12 and 15 remain pending, so the upward sweep still has work ahead.
Know what one bit per floor cannot describe
This model records destinations without distinguishing the source or requested travel direction of a call. It can illustrate collective request storage and sweep selection, but it does not fully describe directional hall-call service.
A hall call asking to travel upward is different from a hall call asking to travel downward at the same floor. If those distinctions matter, represent them separately from car destination requests. Then specify which call types are eligible for service during each sweep and when each can be cleared.
Special operating modes, multiple-car allocation and priority service also require additional requirements. Do not infer those behaviors from the Above and Below summaries.
Passenger information is a separate design question. The elevator screen planning guide covers that display task, not request scheduling or motion authorization.
Check the scheduler without treating it as motion control
Use an isolated logic model or simulation to check the request rules before integrating them into a larger design. Include these cases:
- All seven example requests remain pending together after registration.
- At floor 9, Above and Below are both true and Here is false.
- A new request behind the current sweep does not erase requests ahead.
- Confirmed service clears only the associated request.
- A current-floor request is handled separately from direction selection.
- Idle calls on both sides follow the documented starting rule.
- Simultaneous request and service events follow the specified ordering rule.
- Invalid position data prevents a normal direction result.
These checks establish only whether the scheduler follows its specification. They do not establish that an elevator is safe to operate.
Keep request selection separate from doors, braking, leveling, terminal limits, position validation, emergency operation and motion authorization. The complete control and safety design must govern those functions and the permitted decision points. Never connect this example directly to drive or motor outputs.
Questions
How should simultaneous elevator floor requests be stored?
Use an independent pending bit for each floor. An accepted selection sets its corresponding bit without changing other requests. Clear that bit only on the service-confirmation event defined by the complete controller. Specify restart behavior and simultaneous set-and-clear handling separately.
How is direction selected when requests exist above and below?
Both request summaries can be true at once. A simple collective scheduler keeps its existing dispatch direction while requests remain ahead, then selects the opposite sweep when appropriate. From idle, it needs an explicit starting rule. These preferences do not authorize physical movement.
Is one request bit per floor enough for selective service?
Not by itself. One bit can record that a floor needs service, but it cannot distinguish upward hall calls, downward hall calls and car destination requests. Directional selective service needs separate request data and written rules for stop eligibility and request clearing.
Can this request logic serve as a complete elevator controller?
No. The model covers request storage and dispatch preference only. It does not define doors, brakes, leveling, position validation, emergency operation or motion authorization. Those functions belong to the complete control and safety design, which must be validated against the governing requirements before commissioning.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.