Elevator model control logic: signals, feedback and safety

Define the signal path

Control logic connects an accepted request to a measured result. For an elevator model, that means tracing the path from the selection input through the controller and motor interface, then back through position feedback.

Write a signal list before assigning controller connections. Record each signal's source, destination, electrical interface, active state and meaning when disconnected. Use the controller and interface manufacturers' documentation to establish electrical limits and compatible connections.

Separate logic power, motor power and the interface between them on the drawing. A controller output is a command signal, not a motor supply. Relay coils and other loads need interfaces appropriate to their electrical characteristics; they must not be treated as interchangeable controller inputs or outputs.

Also confirm that the selected programming runtime supports the controller, keypad interface and required feedback capture. A device appearing on a schematic does not establish software support.

Prove what the motor commands mean

Two relays do not automatically provide forward and reverse operation. The result depends on the motor type, contact arrangement and power circuit. A circuit that interrupts one unchanged supply path provides run and stop, not necessarily reversal.

Define the intended motor-interface states before writing movement logic:

• Stopped: the documented interface state for stopping the mechanism.
• Up: a command that produces upward carriage travel.
• Down: a command that produces downward carriage travel.
• Conflicting commands: an invalid condition that must not reach the power stage.

Use the motor and interface documentation to determine the reversal method and any required transition behavior. Do not infer motor direction from an output indicator or relay sound.

Software should prevent opposing direction commands from being asserted together. That does not replace electrical interlocking or protective functions required by the motor interface. Nor does removing a movement command necessarily hold a suspended carriage. The mechanical design must account for gravity and stored energy.

For an initial direction check, secure the lightweight model, guard the travel area and use the documented commissioning procedure. Do not investigate unexpected direction by swapping wires while energized. Stop, isolate the relevant energy sources and correct the documented connection or command mapping.

Separate position from travel boundaries

A destination sensor and a travel-boundary device answer different questions. The first indicates a stopping location. The second limits movement beyond the intended operating range. Do not make both functions depend solely on the same software interpretation of one input.

Floor switches are often easier to understand in a basic model because their locations correspond directly to destinations. Record which input belongs to each location and whether an active signal means the carriage is within that sensor's detection region.

Encoder feedback introduces additional questions:

• What physical movement does each count represent?
• Is the encoder measuring the motor shaft or the carriage itself?
• Can the transmission slip between those points?
• How is a position reference established after startup or reset?
• Can the controller capture pulses at the intended operating speed?

A motor-shaft encoder measures shaft movement. It does not, by itself, prove equal carriage movement through a slipping coupling or transmission.

No floor input being active can be normal when the carriage is between floors. At startup, however, that same reading may leave the position unknown. Do not silently assign a starting floor. Keep automatic movement inhibited until position is established through a separately designed, guarded reference procedure.

Treat impossible sensor combinations according to the actual sensor geometry. If the arrangement cannot physically activate two floor sensors together, that combination warrants investigation. If detection regions overlap, the interpretation must explicitly account for that overlap.

Turn key presses into requests

A matrix keypad requires scanning and decoding. Its raw electrical state is not yet a floor command. Keep three values separate: the raw reading, the decoded key and the accepted destination.

With motor power isolated, check every intended key against the displayed or monitored decoded value. Reject selections that do not correspond to fitted floors. Define how the interface handles simultaneous keys rather than assuming every combination produces a valid selection.

A held key also needs a defined meaning. For a simple model, one accepted press can create one request, with another request allowed only after release and a new press. Repeated scanning of the same held key should not accidentally fill a request queue.

Store an accepted destination separately from the live keypad reading. Releasing the key must not erase a journey already accepted by the controller.

For the first version, accepting one destination while idle is easier to verify than handling a queue. Define whether additional requests during travel are ignored or explicitly rejected. Add queuing only after single-request operation is understood, and decide how duplicate requests, cancellations and faults affect stored destinations.

Describe the operating states

A small state model makes the intended behavior easier to review than a collection of unrelated movement conditions. Each state should have a clear entry condition, permitted outputs and exit condition.

This table describes application behavior, not a complete safety design.

Choose direction using a valid position reference and the physical ordering of floors. Do not assume that a numerical label represents height unless the mapping says so. Once travel begins, the last confirmed floor is historical information, not proof that the carriage remains there.

Define arrival using the selected position system and the mechanism's stopping behavior. A floor sensor can change state before the carriage comes to rest. If travel carries the carriage beyond the detection region, simply removing the command at that sensor may not produce repeatable positioning.

A travel timeout can identify missing arrival feedback. It cannot prove arrival and must not substitute for position measurement. Likewise, a status message saying that the target was reached must follow valid feedback, not merely an elapsed delay.

Verify one layer at a time

Begin with checks that do not require powered movement. Inspect the signal map, monitor keypad decoding and actuate accessible sensors using a controlled, de-energized mechanical setup. Check disconnected-input behavior without defeating protective devices.

Then separate the remaining questions:

• Interface behavior: Does each controller command produce the documented motor-interface state?
• Direction: Does each permitted direction command move the carriage the intended way?
• Position mapping: Does each sensor correspond to its recorded physical location?
• Request handling: Does one accepted selection produce one stored destination?
• Arrival: Do feedback and stopping behavior agree at the selected floor?
• Restart: Does a reset return to a defined state without unexpected movement?

Observe command and feedback values together. An output that changes without movement points toward a different problem from correct movement with missing position feedback.

Evaluate abnormal input combinations through simulation or another documented low-energy commissioning method where possible. Do not bridge a protective device to keep the mechanism moving. A fault response must suit the motor and mechanical arrangement, including any possibility of movement after power removal.

Record expected and observed results. A discrepancy is a reason to stop and correct the relevant layer, not to compensate with an unexplained delay elsewhere in the program.

Keep the model outside real lift control

The useful result is a model whose signals and state transitions you can explain: what requests movement, what proves position, what stops motion and what prevents an unintended restart. Writing ladder logic comes after those definitions, not before them.

Do not connect the model controller to an operating lift or use a successful demonstration as evidence of suitability for carrying loads. Real lift control requires purpose-designed equipment, protective systems and the applicable installation and inspection process.

If the actual requirement is an elevator information screen, keep that display installation separate from motion control. Showing information inside a lift is a different job from controlling its movement.

Questions