Configuring a Custom Elevator VFD for PMSM Hoist Control

A custom elevator VFD for the reported 5 kW, 60 rpm, 16-pole PMSM must be developed as a complete motor-feedback and controller-interface system, not as a DSP algorithm alone. The project moved from initially planned resolver feedback and analog commands to reported Hall-based speed feedback and discrete station connections; it later reported vector current and speed loops and movement tests on a mock elevator shaft, while Hall-derived speed lag remained a limitation.

How should you scope the first elevator-PMSM prototype?

Freeze the motor, feedback device, power stage, and elevator-controller interface as one defined configuration before tuning. The reported motor data—5 kW, 60 rpm, 16 poles, and 5.6 A—give useful starting points, but the motor documentation must establish the operating conditions and meaning of the current rating before you set current limits or sensor scaling.

Some useful checks can be derived from the reported nameplate values. A 16-pole synchronous motor has eight pole pairs. At 60 rpm, it turns at one mechanical revolution per second, so its electrical frequency at that speed is 8 Hz. If 5 kW is the mechanical output at 60 rpm, the corresponding nominal shaft torque is approximately 796 N·m, calculated as 9550 × 5 / 60. Treat that as a consistency check, not a final torque limit: confirm output rating, duty, overload capability, and thermal limits from the motor and drive data.

The early design named a TMS DSP, three-phase permanent-magnet motor, resolver-type sin/cos position sensor, vector control, and an analog elevator-station command. Later reports describe Hall-based speed feedback, discrete station connections, and RS-485 as a planned digital channel. Those are different development stages, not proof that all options were validated together. Record which hardware and interface belong to each test result.

Which symptoms point to wiring or interface faults rather than bad tuning?

Read time-aligned traces before changing gains. A regulator cannot correct a reversed current sensor, a mismatched command scale, a wrong rotor-angle offset, or a delayed speed estimate; increasing gain in response to those faults can make current and torque response worse.

Interpret symptoms by comparing the command, measured feedback, and controller output at the same time. If the command itself is wrong, trace the station wiring, scaling, polarity, and state sequence. If measured current or position is wrong while the physical motor response looks different, inspect sensors, conditioning, wiring, and angle alignment before touching regulators. If those signals are credible but the response is slow or oscillatory, then investigate loop bandwidth and mechanical loading.

How does the PMSM control chain turn a station request into hoist torque?

The elevator station requests a motion state or reference. The drive interprets that request, shapes the commanded speed, compares it with measured speed, and uses the speed controller to request torque-producing current. The inner current controllers act on measured motor current; the inverter then switches the motor phases to produce the commanded electromagnetic torque. Rotor-angle feedback tells the controller how to orient those phase currents relative to the permanent-magnet rotor.

This chain explains why a working analog or discrete interface does not prove that the motor-control loop is sound. The station can issue a correct command while a bad angle estimate produces poor torque. Likewise, accurate commutation cannot compensate for a station command with the wrong polarity or scale. Keep command interpretation, speed control, current regulation, angle estimation, and inverter output separately observable.

In a field-oriented PMSM design, the controller resolves measured currents into rotor-related components and regulates them in the rotating reference frame. The speed loop normally supplies the torque-producing current request; current-loop performance depends on correct current measurement, rotor angle, motor electrical data, and inverter behavior. Derive control constants and limits from the actual motor and power-stage data. The discussion provides no regulator gains, motor inductance, resistance, flux, switching rate, or current-sensor scaling from which to calculate production settings.

What should you measure before adjusting current or speed gains?

Capture a synchronized trend for station command, drive enable and direction, commanded and measured speed, phase currents or controller current values, rotor position, DC-bus behavior, temperature, and brake command/status where those signals are available. Use an independent speed or position measurement during controlled tests to check the drive’s feedback estimate. Preserve raw sensor channels as well as filtered values; a filter can hide wiring noise but also add delay.

1. With the power stage disabled, verify sensor wiring, current-channel polarity and offset, rotor-position continuity, temperature-sensor behavior, and the station’s state and direction signals.
2. With the motor mechanically secured and the test plan controlling any possible torque, verify the angle and current signals against independent instruments. Confirm that each channel changes in the expected direction when the shaft or signal is moved through a controlled, safe test.
3. Record the command and feedback at each operating point. Compare drive-estimated speed with an independent measurement, and compare current-channel readings with the approved measurement method for the power stage.
4. Only after the signals agree, tune the current loop under controlled conditions; then tune the speed loop with current limits and the independent test safeguards active. Change one loop or parameter group at a time and retain each trace.

Do not start by increasing gain to force a sluggish response. First determine whether the delay is in sensor transitions, signal filtering, sampling, command handling, or mechanical response. A gain adjustment can amplify noise or provoke oscillation without removing the source of lag.

How should you choose between resolver and Hall feedback?

The initial design identified a sin/cos rotating transformer—described as a resolver—with a reported position accuracy of one angular minute and mounting at the motor’s intended sensor location. A later test report instead describes speed measurement from Hall-sensor states, with a stated accuracy of 2 degrees, and explicitly reports substantial delay from that method. Treat these as alternative feedback arrangements; the reports do not establish that the resolver and Hall setup were used simultaneously.

A resolver supplies continuous position information that the drive must condition, interpret, and align to the motor’s electrical angle. Verify excitation and return wiring, signal conditioning, direction, offset, and electrical-angle scaling against the motor’s pole-pair count. The quoted angular accuracy does not by itself establish installed accuracy: mechanical coupling, alignment, signal conditioning, and calibration all affect the angle used for commutation.

Hall sensors provide discrete state transitions rather than continuous angle measurement. A speed estimate based on those transitions updates only when the relevant transitions arrive; at low speed, that can make feedback update slowly and produce delayed speed-loop response. The reported 2-degree value does not remove this update-delay limitation. Measure low-speed response and compare it with an independent speed trace before deciding whether the Hall arrangement supports the required starting, leveling, and stopping behavior.

Use the feedback device that the motor and drive were designed and validated to accept. If the prototype changes sensor type, redo angle, direction, speed-estimation, and loop checks; do not carry resolver alignment or tuning results over to a Hall implementation by assumption.

How should you tune the current and speed loops?

The development history indicates that current- and speed-regulator tuning was initially a blocker. A later report says vector control with both loops was operating on a mock shaft, with speed derived from Hall states. That is a useful development milestone, but the reported Hall delay means that the resulting response still needs measurement against the application’s motion requirements.

Establish the electrical model and signal conditioning first. Check the motor’s phase-current basis, pole pairs, sensor polarity, rotor-angle offset, current limits, and inverter operating range. Then validate current regulation at controlled operating points before closing the speed loop. The current loop is the inner actuator loop: if it cannot follow its reference cleanly, speed-loop tuning cannot produce predictable acceleration or deceleration.

Next, close the speed loop using a verified speed estimate and conservative, controlled test limits. Trend command, measured speed, torque-producing current request, actual current, and any limiting state. Distinguish a slow response caused by Hall update delay or filtering from one caused by speed-loop gains; increasing gain against measurement delay can create oscillation or overshoot. The source supplies no gains or tuning recipe, so calculate and tune against the actual motor, inverter, sampling, and feedback data rather than copying an algorithm from another drive.

The project also mentioned an initial plan to use algorithms without feedback on early samples and a first-order filter as a ramp generator. An open-loop or filtered reference may help characterize a controlled prototype, but a smooth command ramp is not closed-loop speed regulation. Validate actual acceleration, deceleration, and load response from measured motion, not from the shape of the reference signal alone.

How should the VFD and elevator station exchange commands?

Define the interface as a state contract, not just a wire list. The early plan involved an analog station signal; later reports say the implemented connection was discrete and that a digital channel was planned. The later RS-485 mention identifies a future direction only; no message map, protocol, timing, or fault behavior is given.

For each interface, document the signal meaning, active polarity, scaling or units, valid range, direction semantics, startup and stop sequence, enable conditions, fault handling, and behavior on wire loss or invalid data. Confirm whether an analog value means speed, torque, or another reference before mapping it into the drive. For a discrete interface, verify that run, direction, enable, and stop states cannot be interpreted inconsistently during transitions.

Test the station connection independently of motor tuning. Inject or command known interface states, read the drive’s interpreted values, and compare them with the station’s requested values. Then test the integrated chain at low-risk operating conditions. Keep a clear distinction between the presently implemented discrete connection and the planned digital interface until the latter has its own complete validation.

How should tests progress from a generator-motor bench to a hoist?

The development team described a generator-motor test stand in which a DC machine applies adjustable load to an AC machine, followed by testing on a mock elevator shaft. A controlled load stand helps expose current regulation and speed response without treating a real elevator as the first tuning environment. It does not reproduce every hoist, rope, counterweight, brake, or elevator-controller condition.

1. Check the low-voltage control path and feedback signals before enabling inverter power. Resolve sensor polarity, command scaling, state interpretation, and fault handling first.
2. On the instrumented stand, validate phase sequence and motor direction at controlled conditions. Increase test range only under an approved test plan, capturing current, speed, rotor angle, bus behavior, and temperature.
3. Apply the stand’s controllable load in planned increments and repeat acceleration, steady operation, deceleration, and stop tests. Compare requested and measured speed, current, and torque response; stop if feedback becomes implausible, protection acts unexpectedly, or the drive departs from the approved test envelope.
4. Move to a mock shaft only after the bench results are repeatable. Test each intended travel and stop mode with the elevator controller, brake system, and independent safeguards operating as designed.
5. Before any service or production use, repeat validation on the exact motor, feedback, VFD, station, and mechanical configuration intended for deployment. Record configuration, measurements, faults, and acceptance criteria.

Do not treat a motor-generator bench result as proof of elevator performance. It verifies a subset of electrical and control behavior; shaft tests must reveal interactions with the complete machine and its protective systems.

What proves that stopping, holding, and protection work?

Verify controlled starts, commanded speed tracking, acceleration and deceleration, direction, stop accuracy, and repeatability under the specified load conditions. Trend both the reference and actual motion; a smooth first-order ramp in software does not prove that the car follows an acceptable motion profile. The project later reported operation of all motion modes on a mock shaft, but the report does not provide measured stopping tolerances or a repeatability data set.

The reported prototype included current, speed, and temperature protections set to nominal parameters. Verify each protection against the motor, sensor, inverter, and test documentation: confirm the measured value, trip response, reset behavior, and resulting safe state. A displayed threshold alone does not show that a protection path works end to end.

The team also reported holding by applying constant current to the windings, including a test with an unbalanced car and no brake. Treat this only as an observed prototype test, not as a safe elevator holding strategy. Electromagnetic holding depends on energized power electronics and thermal limits; it does not provide the independent mechanical restraint or power-loss behavior of a properly designed brake system. Validate brake operation and all required elevator protective functions independently, and do not use motor current as a substitute for them.

Which development pitfalls should block field release?

The most consequential mistake is tuning before validating measurement. Current-loop problems can originate in sensor polarity or scale; speed-loop problems can originate in Hall update delay, resolver alignment, filtering, or station command interpretation. Maintain separate acceptance checks for the interface, sensors, inner current loop, outer speed loop, brake coordination, and protective functions so a pass in one layer cannot mask a fault in another.

A second pitfall is treating the prototype’s successful movement as production readiness. Reports later claimed successful testing and serial production, but that does not supply the configuration record, motor and inverter limits, endurance data, installation acceptance criteria, or safety validation for a different machine. Release decisions must follow results from the exact final hardware and software configuration.

Finally, do not conflate optional development paths: resolver versus Hall feedback, analog versus discrete station connection, and a planned RS-485 channel are separate design choices. Freeze and document each combination before comparing tests. If a sensor, motor, station, or power-stage revision changes, reassess affected measurements and repeat the relevant tests instead of carrying old tuning forward.

Frequently asked questions about elevator VFD control