Applications.

Power Supplies, Power Stage, and Control Board

A servo drive's system boundary includes auxiliary power supplies, the DC bus, three-phase power bridge, gate drivers, sampling, and control board. The control board determines targets and modulation, the power stage delivers bus energy to the motor, and auxiliary supplies keep the control circuitry and drivers operating. Their startup and power-down sequences affect output permission; the MCU program reaching its main loop does not establish that the power section is ready.

When building a signal table, specify active levels and default states for each supply monitor, driver fault, PWM enable, brake, and feedback interface. Pins may be high-impedance during reset; hardware should provide deterministic output states consistent with the design, with software taking over after initialization. Bus measurements and gate-driver undervoltage status must also participate in permission logic, preventing modulation from continuing when the control supply is healthy but gate power has not been established.

Split board bring-up into modules: first confirm low-voltage supplies and clocks, then verify sampling, driver logic, and PWM without power applied, and finally connect the bus and motor under controlled conditions. Define observable quantities for every step and record board versions, configuration, and fault entry points. Rated voltages, currents, layouts, and components in a reference design apply only to that design; verify them again against the actual hardware when porting.

Software should maintain independent states for supplies, power-stage readiness, control initialization, and run permission, retaining which stage failed first when a fault occurs. Do not bypass all conditions by setting one global enable variable to true. During integration, observe the establishment and release sequence of the bus, driver supplies, and output permission together, with particular coverage of power-on fluctuations, partial power loss, and stale commands after reset.

Debugging Checks

• Record a timeline for control power, gate power, bus detection, and PWM permission, and check that output is never permitted while any required condition is unmet.
• Introduce an auxiliary-supply or driver-supply fault independently, and check the reported cause, default pin states, and conditions for restarting.

Control Tasks and Communication Interfaces

Servo firmware usually separates current control, slower speed/position control, communication services, parameter management, and diagnostics into execution paths with explicit periods. Communication supplies targets and modes, which the controller uses at fixed adoption points; receiving a frame must not directly alter PWM execution timing. The real-time budget must cover sampling, feedback updates, control computation, modulation, and actual register loading.

Interface definitions should specify target units, positive direction, limits, valid states, and update timing to form a complete command snapshot. The communication task must not modify mode, controlword, and target separately in a shared structure; consumers accept only a fully validated, consistent version. Use unified command arbitration for PDO, serial, and local debugging inputs, explicitly identifying the active control source and communication-loss policy.

Keep blocking access, dynamic allocation, and unbounded logging out of the fast current loop; move parameter storage and long protocol transactions to the background. When decimating speed and position loops, calculate discrete gains using their actual periods instead of copying the fast-loop period to every loop. Task priorities are only scheduling tools; measure how preemption and critical sections affect deadlines as well.

During integration, observe protocol arrival, command publication, control adoption, and output effect separately to distinguish late targets from fast-loop overruns. Test full communication load concurrent with background storage and fault reporting, confirming that control still executes within budget. Measuring only average CPU utilization can miss occasional worst-case paths; record overrun counts and versions instead of judging real-time behavior from a normally refreshing interface.

Debugging Checks

• Apply PDO updates and background parameter operations simultaneously, and measure worst-case fast-loop completion time and command age.
• Switch control sources and modes, confirming that adopted targets belong to one snapshot and that the old source can no longer write.

Motor, Feedback, and Mechanical Load

Servo response depends jointly on motor electrical parameters, position feedback, mechanical inertia, transmission ratio, friction, and compliance. Controller inputs should include more than rated motor power: pole-pair count, flux linkage or torque constant, winding parameters, feedback resolution, and load direction are also needed. With the same motor connected to different loads, speed- and position-loop tuning and limiting conditions may be entirely different.

Create a motor and load parameter table with units and measurement or manual sources. Convert motor-shaft and load-shaft positions through the transmission ratio; encoder placement changes the error seen by the closed loop. Flexible couplings, gearbox backlash, and mechanical resonance cannot be directly eliminated by raising control gains. First identify feedback mounting position and mechanical constraints, then choose bandwidth and filtering.

Feedback paths should include validity and data-freshness indicators; after failure, do not treat the last angle as the current angle indefinitely. Incremental encoders generally do not supply an absolute electrical zero at power-on; whether alignment, homing, or retained position is needed depends on the actual structure. Systems with a holding brake must also specify brake engagement and release timing, load-support conditions, and coordination with drive torque.

During bring-up, first verify that positive and negative directions, feedback counts, and mechanical movement agree, then close the loops in stages under current and speed limits. When the load changes, record inertia estimates, following error, control output, and limit states to distinguish parameter errors, feedback delay, and mechanical constraints. One successful no-load round trip cannot establish full-load positioning performance or safe-stop capability.

Debugging Checks

• Compare motor-shaft and load-shaft motion, and check transmission ratio, positive direction, pole-pair count, and feedback-count conversion.
• Repeat error and limit-state recording after changing the load or mechanical connection, confirming that tuning conclusions cover the actual operating conditions.

System Constraints and Verification Entry Points

Servo acceptance must turn positioning, speed, torque, temperature-rise, and communication requirements into observable metrics under defined operating conditions. Specify the bus, load, temperature, trajectory, duration, and feedback conditions for every metric; 'high precision' alone cannot define a test. Capability is also constrained by current, available voltage, mechanical speed, and cooling, so the controller cannot be expected to maintain the same dynamic response after saturation.

Arrange verification entry points by dependency: sampling calibration, phase sequence and angle, PWM/ADC timing, current loop, speed loop, position trajectories, and communication control. Save pass criteria and raw records at every step, stopping at the layer closest to the cause on failure. Software unit tests suit unit conversion, limiting, and state logic; actual current waveforms, delays, and mechanical errors require target hardware.

Establish separate observables for limiting conditions, including voltage saturation, current limiting, following error, expired commands, and fault response. When output reaches a limit, logs should show the target actually adopted rather than only the master's reference. This distinguishes insufficient system capability from control errors and reveals whether an integrator is continuing to accumulate, causing an abrupt change when the limit is released.

Regression coverage should include cold and hot conditions, different directions and loads, communication disturbances, and fault recovery, with hardware/firmware versions recorded. Explicitly retain untested scope; do not substitute vendor reference-design results for your own data. After changing sampling rate, feedback filtering, compiler optimization, or the power board, reverify the relevant timing and performance instead of merely checking that the code compiles.

Debugging Checks

• Link every performance requirement to specific operating conditions, records, and judgments, and check for metrics that lack bus or load boundaries.
• Enter and exit voltage/current limiting, observing integrator state, adopted targets, and error recovery to confirm there are no hidden abrupt changes.

Inverter Bridge and Gate Drivers

A three-phase inverter bridge combines upper- and lower-switch states to generate motor-terminal voltages, while gate drivers convert MCU logic signals into gate actions suitable for the power devices. Check PWM active levels, upper/lower bridge-arm relationships, driver modes, and default off states together. Apparently complementary logic waveforms do not prove that the actual gates have no overlap; propagation delay, Miller coupling, and device switching times all affect the result.

Configure dead time, minimum pulse width, and fault inputs according to power-board and driver parameters. Do not assume that built-in interlocking, dead-time, or protection functions are all active based on their names; check the specific modes and registers. Bootstrap-powered high-side drivers also have refresh constraints. High duty cycles or prolonged static conduction may affect gate power and must be included in operating boundaries.

Gate-drive strength involves tradeoffs among switching losses, overshoot, and noise; do not simply maximize turn-on speed. Communication firmware can read back configuration and faults, while the fast protection path must still be designed for actual device tolerances. When replacing MOSFETs, IGBTs, or SiC devices, recheck gate voltage, drive current, turn-off behavior, and sampling noise instead of changing only the current rating.

During integration, first verify default states with controlled power and no run command, then measure the correspondence between logic inputs and actual gate/phase nodes. Abnormal pulses, driver undervoltage, or fault recovery may occur at enable edges; focus on transitions during power-on, stopping, and renewed permission. Reference-design test waveforms establish behavior only for their own components and layout; they cannot directly validate another board.

Debugging Checks

• Compare PWM inputs with actual upper- and lower-switch gate timing, checking dead time, minimum pulse width, default off states, and outputs after faults.
• Read back driver modes and protection configuration. Cover high duty cycles, undervoltage, and enable transitions to confirm that software assumptions agree with hardware.

Current, Voltage, and Temperature Measurement

The current, DC-bus voltage, and temperature used by servo control come from different sampling paths; their bandwidths, units, and valid ranges must not be conflated. Phase currents support closed-loop control and diagnostics, bus voltage determines voltage capability and protection, and temperature reflects slower thermal states. Each sampling path must define the sensor, gain, offset, ADC reference, and conversion relationship, plus how out-of-range or invalid data is flagged.

Measure current offsets in a known zero-current state that meets hardware conditions, rather than forcing the average to zero while the motor runs under load. Calibrate gain using a justified input or reference measurement, recording positive/negative directions and channel differences. Amplifiers with PWM rejection still have settling times and frequency characteristics; verify sampling windows against actual common-mode transitions and front-end response.

Voltage and temperature channels may use slower updates and appropriate filtering, but the protection path requires independent response-time consideration. An open or shorted temperature sensor, or an out-of-range reading, must not simply be clamped to a normal temperature. ADC triggering, DMA buffers, and control adoption need temporal consistency. In particular, nonsimultaneous sampling of two phase currents can introduce errors into reconstruction and transforms.

During debugging, record raw ADC codes, engineering units, calibration values, and validity flags together to distinguish conversion problems from real noise. After changing the bus, duty cycle, and load, observe offsets, waveforms, and saturation, checking whether the sampling front end is overdriven. Do not smooth a display waveform with heavy filtering while introducing phase delay into the current loop without reverifying stability.

Debugging Checks

• Check offset, gain, and signs at known zero current and positive/negative inputs, then observe settling time during PWM switching.
• Disconnect the temperature sensor or drive the ADC to its range boundary, and check that invalid-data flags, fault actions, and filter delays match the definition.

Isolation and Fault Protection

Isolation in power systems separates voltage domains and transfers signals; fault protection detects faults and limits damage. Their respective boundaries must be clear. An isolated driver with a given isolation rating does not establish that the entire board's spacing, supplies, connectors, and system meet the same level. Interpret datasheet parameters in the context of actual routing, working voltage, and system requirements.

List overcurrent, driver undervoltage, overtemperature, and other actual fault sources in the protection path, specifying detection points, threshold justification, shutdown paths, and reset permission. Fast hardware fault signals can directly inhibit PWM or gates, with software subsequently recording and latching the event. A slow current warning in a communication task is not short-circuit protection, and the presence of an isolator does not establish that noise cannot affect fault inputs.

For fault signals crossing isolation domains, check active levels, unpowered defaults, pulse widths, and propagation delays so a broken wire is not interpreted as normal. Configure driver blanking and soft turn-off parameters against device tolerances: excessive blanking may miss dangerous events, while overly fast turn-off may increase overvoltage. Software should preserve the first fault and a contextual snapshot, preventing subsequent power-loss states from overwriting the original cause.

Verify the fault-input path, software latching, logs, and recovery separately, rather than declaring the entire chain passed after calling a simulated-fault function. Actual power-fault tests must be performed under suitable conditions by appropriate personnel according to the design. Low-energy injection can verify logic first, but cannot replace device-withstand and actual shutdown-timing tests. Clearing a record does not mean output recovery is permitted.

Debugging Checks

• Inject logic signals from each actual fault source, measure the time to PWM/driver inhibition, and record latching and the first cause.
• Test loss of power on the isolated side and invalid fault lines, checking default states and recovery permission so failures are not interpreted as normal.

Principles and Boundaries of Safety Functions

Safety functions such as STO concern limiting the energy that can generate torque under specified conditions. This is neither ordinary software stopping nor immediate motor standstill. Inertia may keep motion going, vertical loads may need a mechanical holding brake, and the bus may retain hazardous voltage. Setting a software PWM-inhibit variable alone does not establish that STO has been implemented.

Safety chains typically involve dedicated hardware, redundant or diagnostic architectures, fault analysis, and full lifecycle requirements. TI's STO reference design provides a specific architecture and evaluation scope; using one of its components or copying a piece of logic does not automatically inherit its SIL or PL conclusions. Compliance of an independently developed product requires verification and assessment of the actual system.

Ordinary drive firmware may receive safety status, prohibit new run permission, and provide diagnostics, but should not bypass or automatically reset an independent safety chain. Status reporting must distinguish safety requests, actual hardware states, ordinary drive faults, and mechanical standstill signals. Restored communication or cleared faults are insufficient for restoring safety permission; restart policies must prevent old start commands from generating torque again.

Begin engineering analysis by drawing energy paths and safety interfaces, and listing expected observations for broken wires, power loss, single-point failures, and contradictory feedback. Verifying software interfaces does not replace safety-hardware verification. Every test report should limit its claims to the channels, operating conditions, and fault types actually covered. Simulated STO inputs, an ordinary emergency-stop button, or a single motor stop are not complete evidence of safety compliance.

Debugging Checks

• Record safety requests, hardware permission, and drive operating state separately, and check that stale controlwords cannot automatically restart the drive after permission is withdrawn.
• Review the coverage boundaries of test results, distinguishing reference-design assessment, software-disable testing, and full product certification.

Inner d/q Current Loops

For a PMSM servo using rotor-flux orientation, the inner current loops transform phase currents into a rotating reference frame, regulate d- and q-axis currents separately, then generate voltage commands through inverse transforms and modulation. Coordinate directions, phase sequence, angle offset, and transform normalization must agree. Steady d/q values do not establish correct torque direction; an incorrect angle can make current components look normal while missing the physical target.

The implementation first corrects sampling offsets and scaling, uses a time-aligned electrical angle for the transform, then computes error, PI action, necessary compensation, and voltage limits, and finally generates modulation based on the bus voltage. PI gain definitions must specify the discrete period and whether the integral term already includes the period factor. Coordinate voltage limiting with anti-windup to prevent further integral accumulation when commands exceed bus capability.

Inner-loop bandwidth is constrained by sample-to-output delay, PWM updates, sensor noise, and motor parameters; there is no fixed ratio universal to all servos. Confirm hardware and signs before tuning gains. Outer-loop references need current-magnitude and slew constraints. When d and q change together, consider the current-vector boundary rather than clamping each axis independently to the same maximum and producing excessive resultant current.

Begin debugging with controlled small current commands, observing phase currents, d/q feedback, adopted voltages, and saturation flags. Check responses to positive and negative steps at different electrical angles; success at one fixed angle does not establish consistency over a full revolution. Then estimate bandwidth and stability margins with appropriate methods. Vendor example results are references, not performance already achieved by an independently developed board.

Debugging Checks

• Apply small positive and negative current targets at different electrical angles, checking consistency among phase sequence, transform signs, and feedback response.
• Change the bus voltage or enter and leave voltage limiting, checking anti-windup, integral state, and smooth output recovery.

Torque Commands and Limits

Torque mode converts an external mechanical target into a current target, but the conversion depends on the motor model, flux linkage, pole-pair count, normalization, and current definition. Under specific assumptions, a surface-mounted PMSM allows a simplified relationship between torque and q-axis current; an interior PMSM also involves reluctance torque. A fixed Iq multiplier cannot be generalized to all motors, and peak and RMS currents must not be mixed.

The product parameter table should specify rated torque, torque-constant units, and the current basis; the interface should provide commanded torque, actual adopted current, and the reason for limiting together. Higher-level torque scaling, mechanical transmission direction, and electrical-angle direction must agree. Internal limits must consider the motor, power devices, temperature, and available voltage, rather than allowing output up to the numeric type limit of a communication object.

Dynamic commands need magnitude and slew-rate limits to avoid mechanical shocks from a torque step. Torque mode also requires an explicit strategy at speed boundaries; it does not inherently constrain shaft position as position mode does. Handle integration and target handoff when limits change. Thermal derating or bus changes must not leave outer loops accumulating error against capability that is no longer available.

First verify units and encoding without power applied, then compare commands, dq currents, and load response under controlled conditions. Actual torque measurement requires suitable sensors and operating conditions; a software-converted Iq value alone cannot be claimed as measured output torque. Verify forward/reverse directions, continuous loads, and short-term peaks separately. Record adopted values rather than targets alone so the cause of limiting can be explained.

Debugging Checks

• Check torque constant, pole-pair count, and peak/RMS basis, including the direction and scaling from positive/negative commands to Iq.
• Trigger thermal derating or speed boundaries, observing adopted current, limiting reasons, and recovery; do not substitute software estimates for measured torque.

Feedforward and Decoupling

Feedforward and decoupling in servo current loops reduce the effect of predictable voltage demands on PI error, often involving rotating-frame cross terms and back EMF. They depend on motor parameters, speed, and sign conventions; do not simply copy signs from an online formula into firmware. Establish the coordinate equations being used, then check electrical angular velocity, Ld/Lq, and flux-linkage units in the implementation.

Record PI output, feedforward terms, and final adopted voltage separately, and apply anti-windup feedback after limiting according to the actual control structure. Compensation also consumes voltage headroom; do not limit PI and feedforward independently and then add them beyond the modulation boundary. Define valid compensation ranges and filtering/limits for parameter errors or speed noise, preventing high-gain feedforward from amplifying errors during startup or invalid feedback.

First establish a trustworthy inner loop with compensation disabled, then enable individual terms and compare current errors under disturbances and speed changes. Model compensation may be inaccurate when low-speed angle is unlocked, speed estimates jump, or inductance changes with current; permit gradual engagement or limited use. Some FCL libraries have specific APIs and variable organization. Read the implementation for the relevant version when porting instead of inferring formulas from variable names.

The debugging focus is whether compensation uses data from the same cycle at the correct execution point. Using an old speed sample with new angle and current samples creates additional inconsistency. If enabling compensation causes oscillation, first check units, signs, delay, and saturation instead of continuing to raise PI gains. Verify results in different directions and bus conditions; one smoother high-speed waveform does not establish general effectiveness.

Debugging Checks

• Record PI, feedforward, and post-limit voltage separately, and reverse rotation to check that cross-coupling compensation signs match the coordinate equations.
• Compare errors and saturation during compensation on/off and parameter-mismatch tests, confirming that invalid speed or angle does not amplify output.

Sampling Delay and Ripple

Servo current ripple depends jointly on PWM switching, motor inductance, bus voltage, current-sensing location, and control output, while displayed traces also depend on sampling phase and filtering. A smooth sequence from ADC samples always taken at the same phase does not mean the actual current has no ripple. Distinguish instantaneous switching ripple, control-cycle variation, and sampling noise, choosing appropriate measurement bandwidth and observation points.

Effective closed-loop delay includes analog-front-end settling, ADC conversion, interrupt waiting, computation, PWM shadow loading, and other digital filtering. Shorter computation reduces only part of it. For single-shunt or low-side sampling, also verify that valid windows remain sufficient after duty-cycle changes; when a window becomes invalid, do not force meaningless samples into the dq transform.

Angle-to-current timing also affects high-speed current error. Delay compensation may be considered based on a confirmed model, but actual delay must first be known rather than guessing a constant. Noise-reducing filtering introduces phase lag and requires rechecking the loop. Higher PWM frequency may improve ripple while increasing switching losses and CPU load; choose it against power and real-time constraints rather than pursuing smoother traces alone.

Measure ADC triggers, ISR start/end, actual PWM loading, and phase-current waveforms together, comparing different duty cycles, directions, and bus voltages. Measure worst-case waiting under full communication and background-task load as well. If waveforms change after modifying sampling location, driver switching settings, or the amplifier, recheck sampling scale and windows instead of merely tuning PI to hide hardware sampling defects.

Debugging Checks

• Compare oscilloscope current waveforms with ADC sample phase to distinguish actual ripple, aliasing, and insufficient front-end settling.
• Measure the complete delay from sampling to PWM loading, covering windows at high modulation indices, and check invalid-sample and deadline counters.

Outer Speed Loop

The speed loop generates torque or q-axis current targets from mechanical-speed error, relying on the inner current loop to have trustworthy tracking capability first. Its plant includes mechanical inertia, friction, and load torque, differing from the electrical plant of the current loop. Before tuning, fix speed units, direction, estimation method, and update period. Mechanical rpm, electrical frequency, and increments per cycle must not be interchanged.

Speed feedback often comes from position differences, captured periods, or combined estimation; low-speed quantization and filtering delay affect control. Choose measurement windows according to feedback resolution and speed range instead of adding excessive filtering for smooth traces while ignoring phase. The outer loop may generally execute more slowly than the current loop, but its discrete PI integral gain must use the actual outer-loop period.

Set output limits according to current available from the motor and power stage, and constrain the speed target with a trajectory. During current saturation, the speed PI needs anti-windup or explicit integral handling to prevent a high-speed surge when load is removed. Load changes, mechanical resonance, and feedback noise should not all be treated with higher gains. First observe adopted current, speed error, and limit states to distinguish plant changes from feedback-path problems.

Begin verification with small speed steps and disturbances, recording target, feedback, current target, and actual current, then vary load and direction to check stability. Frequency analysis can help estimate bandwidth and margins, but injection amplitude and operating conditions must suit the system. A vendor's dual-axis reference design demonstrates an analysis method; it does not mean every load can use the same gains or bandwidth ratio.

Debugging Checks

• Check speed-measurement windows and filtering delay, comparing continuity and unit consistency of feedback at low speed, high speed, and reversal.
• Drive current to its limit and then unload, observing the speed integrator state and overshoot to confirm that anti-windup and target ramps are effective.

Position Loop and Cascade Relationships

The position loop converts position error into speed or another intermediate target, then speed and current paths execute it in a cascade with different time scales. Position feedback may come from the motor shaft or the load side, producing different closed-loop plants. Define axis coordinates, zero, transmission ratio, positive direction, and position range first; encoder counts alone are not calibrated mechanical position.

Bring up the current loop first, then the speed loop, and finally connect position targets and trajectories. Position-loop bandwidth is limited by inner-loop capability, feedback delay, and mechanics; do not increase all three loops together. The outermost output also has speed and acceleration boundaries. Constrain targets generated by large position errors or long-distance commands may continuously saturate the inner loops.

Position differences must handle multiturn counts, counter wraparound, shortest-path versus specified-direction movement, and integer width. Direct subtraction at wraparound can produce a huge false error. Homing, mode changes, and feedback resets require realignment of targets and coordinates so a sudden coordinate change does not make the controller produce a surge in response to apparent displacement.

Validate small displacements, long travel, both directions, dwell, and wraparound crossings while observing position error, adopted speed, and current limits. Backlash and elasticity can allow correct motor-shaft positioning with incorrect load positioning, so interpret results according to feedback location. Final in-position values alone establish neither stable trajectories nor positioning accuracy under different loads.

Debugging Checks

• Check position-error calculation and target reconstruction during counter wraparound, homing, and mode changes, ensuring no sudden large setpoints occur.
• Observe motor-shaft and load-shaft feedback separately, checking the effects of cascade bandwidth, speed limiting, and backlash.

Command Trajectories and Feedforward

Position commands need speed, acceleration, and, when necessary, jerk constraints to form executable trajectories. Trapezoidal velocity and S-curve profiles serve different mechanical smoothness requirements, chosen according to load and cycle budget. A position-target step is not realizable instantaneous motion; planner position, velocity, and acceleration outputs must belong to the same instant of one continuous trajectory.

Feedforward uses planned velocity or acceleration to reduce predictable following error but does not replace feedback correction. Units, signs, and injection points must match the cascade: velocity feedforward enters the speed target, while torque feedforward requires a load model and limits. Do not add trajectory derivatives repeatedly in multiple loops or amplify abnormal acceleration calculated after missing target frames.

When communication and local control periods differ, define target holding, interpolation, or replanning and record each target's effective time. Handle current velocity and acceleration when a new endpoint arrives instead of restarting at zero speed. Planning must consider stopping distance and travel limits; total feedforward remains constrained by current and available voltage and must cooperate with anti-windup.

First disable feedforward to verify basic trajectories, then enable velocity and acceleration terms separately and compare error, overshoot, and saturation. Test short moves, reversal, continuous target updates, and cancellation, checking continuity and stopping behavior. Accuracy claims must specify load, speed, and measurement conditions; a software curve matching its target does not prove actual mechanics meet the specification.

Debugging Checks

• Continuously change endpoints, cancel, and reverse; check position/velocity/acceleration continuity at boundaries and stopping distance against constraints.
• Enable feedforward terms separately and compare errors with limited outputs, checking units, signs, and duplicate compensation.

Following Error and Dynamic Response

Following error is deviation between the desired trajectory and actual position, with an explicitly defined reference. The master's final endpoint, interpolated instantaneous target, and drive-local constrained target differ; endpoint minus current position may be remaining travel rather than closed-loop following error. Different target and feedback sampling times also turn timing differences into apparent control error.

Monitoring generally combines magnitude and duration with operating mode and valid-feedback conditions, distinguishing brief normal dynamic error from sustained loss of tracking. Define thresholds in real position units rather than copying another device's encoder counts. The resulting stop, limit, or fault response depends on mechanical and power boundaries; an error-bit name does not establish the actual action.

Observe trajectory, actual position, speed, current, and limit flags together when evaluating dynamics. Error can arise from voltage saturation, insufficient torque, late communication, feedback delay, or mechanical resonance; increasing position gain alone does not address every cause. Record steady-state error, peak error, recovery time, and direction-dependent behavior, preserving sampling periods and alignment methods.

Cover acceleration/deceleration, load changes, continuous target updates, and fault recovery, recording conditions rather than only the most attractive trace. Host tests can verify monitoring calculations and time windows, but stopping distance, feedback chains, and mechanical position require hardware validation. Beckhoff monitoring parameters are implementation references rather than thresholds and actions every custom drive must copy.

Debugging Checks

• Compare interpolated targets and feedback on one timebase, confirming that monitoring measures following error rather than remaining travel.
• Vary loads and limits, record peaks, durations, and fault actions, and check consistency of threshold units and stopping policy.

Encoders, Hall Sensors, and Position Feedback

Feedback devices differ in resolution, absolute information, latency, and failure reporting. Incremental encoders count phase changes, absolute encoders return positions in specified formats, and Hall sensors generally identify coarse rotor regions. Choose according to startup, low-speed torque, positioning, and environmental needs; decodable signals do not automatically satisfy every servo-feedback requirement.

For incremental links, check A/B phase relationship, count multiplier, Z-pulse handling, count range, and input filtering; for absolute links, check clock, frame length, checksums, status bits, and transmission delay. Cables, supply, interface levels, and differential receivers also belong to the feedback chain; changing a software sign cannot conceal disconnection or electrical mismatch. Hall combinations additionally need valid-sequence and abnormal-state detection.

Feedback data should carry validity and time or sequence information corresponding to its use by control. Filtering, serial reads, and retries delay position and particularly affect electrical angle at high speed. Distinguish temporary checksum failure, consecutive missing samples, count abnormalities, and sensor resets; the last position cannot remain 'currently valid' indefinitely.

Begin integration without torque output, manually rotating or using controlled inputs to check direction, counts per revolution, and zero before powered motor operation. Record raw feedback, decoded position, speed, and validity to distinguish protocol parsing, unit conversion, and mechanical problems. The referenced eQEP manual applies to its listed chips; other MCUs require separate checks of input filtering and latch rules.

Debugging Checks

• Rotate one full revolution manually and reverse, checking count multiplier, direction, index pulse, and resolution as defined in feedback documentation.
• Inject disconnection, bad checksums, and consecutive sample loss, checking validity, last-sample age, and drive fault handling.

Angle Alignment and Decoding

FOC electrical angle references the rotor-flux relationship to phase windings; encoder mechanical zero or its Z pulse is not inherently that reference. Define phase sequence, the viewpoint for positive rotation, encoder direction, and Park convention before determining electrical offset. Continuous mechanical-angle readings do not mean commutation alignment is complete; incorrect alignment makes current direction inconsistent with torque.

The decoding path must explicitly handle counter wraparound, absolute-frame checksums, status, and multiturn information, returning common mechanical position and validity. Design alignment for the motor, feedback type, and mechanical constraints, and record conditions and results. Determine beforehand whether loaded or braked axes can perform alignment that produces motion/torque; do not run it unconditionally at every power-up.

Zero offsets depend on motor wiring, encoder installation, and direction; associate stored values with hardware/configuration identity and verify their applicability after upgrades. Commutation signs are not merely a combination that makes the motor turn: an incorrect relationship may seem normal at low speed without load yet produce large d-axis current or wrong torque. PI gains must not compensate for an unverified angle reference.

Check angle continuity and dq feedback across a full revolution or several electrical cycles, then verify positive/negative torque with controlled current. Save phase currents, raw mechanical position, converted electrical angle, and alignment offset together to distinguish phase-sequence, pole-pair, and offset errors. Recheck after wiring, sensor, or mounting changes instead of retaining old calibration.

Debugging Checks

• Check electrical-angle repetitions and continuity over one full mechanical revolution, confirming agreement among phase sequence, direction, and pole pairs.
• After wiring or encoder-mounting changes, check offset applicability and record dq currents and torque direction; do not directly reuse old calibration.

Mechanical/Electrical Quantity Conversion

Mechanical position describes shaft motion; electrical angle describes the rotor-field cycle relative to the stator. Pole pairs and offset connect them: typically electrical angle equals pole pairs times mechanical angle plus alignment offset, normalized to one electrical cycle, with direction signs included in the defined convention. Mechanical rotational speed and electrical frequency are not directly interchangeable either.

Fix interface units: angle in radians, degrees, or turns; speed in rpm, radians per second, or counts per cycle. Distinguish encoder lines, edge-count multipliers, and absolute bit resolution, and state whether feedback is on the motor or load shaft when defining transmission ratio. Use sufficiently wide intermediate integers to avoid overflow when multiplying by pole pairs or scaling factors.

Speed estimation from position differences must handle wraparound and actual time intervals rather than assuming every read is exactly one fixed period apart. Low speed suffers quantization; high speed requires consideration of feedback latency and electrical-angle extrapolation. State the valid range of the chosen method. Filtered speed and instantaneous position have different temporal characteristics and must not be treated as simultaneous raw quantities.

Create software vectors from known counts per revolution, pole pairs, and direction, then compare with actual manual shaft rotation. Verify separately the electrical cycles per motor revolution and motor revolutions per load revolution. Passing formula checks does not prove correct installation and wiring; connect physical direction and actual feedback to the same convention table.

Illustration: θe = wrap(p × θm + θoffset); p is the pole-pair count, and signs and wrap interval depend on the coordinate convention.

Debugging Checks

• Validate conversion with forward/reverse, wraparound, and pole-pair boundary vectors, checking for integer-intermediate overflow and mixed units.
• Rotate the actual shaft and compare mechanical revolutions, electrical-angle cycles, and load transmission ratio, confirming physical direction matches software conventions.

Conditions for Sensorless Estimation

Sensorless algorithms estimate angle and speed from voltage, current, and motor models; whether they replace sensors depends on observation principles, operating region, and application needs. Back-EMF methods lack information at low or zero speed and cannot directly promise stationary positioning or full-load starting. Compare servo holding, low-speed positioning, and fast reversal requirements with the specific method's observable range.

Estimator inputs must reflect actual applied voltage and valid current rather than ideal unlimited controller commands. Dead time, bus variation, sampling offset, and PWM-update latency create model error. Parameters vary with temperature and operating conditions, so define their source, units, and scope; one observer gain cannot suit every motor with filtering used to conceal mismatches.

Design startup and mode handover separately, including angle establishment, open-loop or other initialization, estimation-validity checks, gradual closed-loop entry, and loss-of-lock recovery. Keep direction and offset consistent when switching estimated and sensor angles to avoid sudden dq changes. PLL filter bandwidth trades off against dynamics; validate using residuals, signal conditions, and operating regions rather than merely observing changing estimates.

Begin validation against trustworthy feedback, recording estimation error, speed, and load before exploring startup, low speed, reversal, and bus disturbances. Smooth estimation at one speed does not generalize across the range. Microchip AN1292 demonstrates a particular PMSM PLL and field-weakening scheme whose motor and hardware conditions require revalidation; it does not guarantee every precision-servo positioning function.

Debugging Checks

• Compare estimated angle with sensored operation, recording error and validity at low speed, during reversal, and with load changes.
• Test startup handover and loss of lock, observing angle continuity, dq currents, and recovery policy, and identify unsupported operating regions.

Position/Speed/Torque Modes

Position mode follows trajectories, speed mode controls rotational speed, and torque mode controls torque or corresponding current, with different boundaries and user responsibilities. Torque mode does not inherently limit axis position, nor does speed mode guarantee that a load reaches a specified position. Products must define active loops, target units, constraints, and valid feedback per mode rather than merely changing a mode number.

Provide separate target decoding and adoption rules per mode while sharing underlying current control and protection. Position mode plans or interpolates, speed mode constrains acceleration/deceleration and current, and torque mode handles amplitude, slew rate, and speed boundaries. Expose control source, input-validity time, and adopted values after limiting so the host can understand why targets were not executed directly.

Before changing modes, define whether stopping is mandatory or controlled online transfer is supported, and handle integrators, trajectory buffers, and old targets. Do not write new targets into old-mode fields before confirming actual mode. Position coordinates, homing state, and torque references may also change; design initialization and invalidation conditions rather than clearing every variable as a universal solution.

Verify individual modes under unpowered or controlled conditions first, then test transitions with nonzero old targets, paused commands, and cancellation. Record targets, actual mode, adopted loop values, and output permission to detect jumps. Published drive models suggest interface structures, but document device-supported modes and optional objects rather than claiming every CiA 402 mode is implemented.

Debugging Checks

• Switch modes from nonzero targets, checking old-trajectory and integrator handling and ensuring new targets activate only after mode confirmation.
• Reach position, speed, and torque limits separately and verify that returned adopted values and status explain application behavior.

CiA 402 Objects and Enabling

In a CiA 402 servo interface, objects expose drive behavior to communication and must connect to real states, modes, and feedback. The controlword requests actions, the statusword reports results, and requested/displayed modes indicate desired/actual modes. Creating indices and echoing written values does not prove the motor is ready to operate or that targets entered the control loop.

The drive state machine must check bus voltage, feedback, parameters, and faults before permitting output, mapping rejection conditions to understandable diagnostics. NMT Operational and EtherCAT OP are communication states, not substitutes for drive Operation enabled. Initialize in a valid inhibited state; even valid controlwords must satisfy application conditions, and a network-connection callback must not automatically turn on power output.

Pass controlword, mode, and target to the application in one cycle snapshot, treating edge actions and persistent commands separately. Fault reset must confirm the real fault is gone and recovery is permitted; a master holding reset high must not clear diagnostics every cycle. Quick stop and disable-operation output behavior depend on supported options and mechanics and require documentation rather than just a status code.

Begin integration by reading identity and confirming object attributes, then advance state transitions while recording controlword, statusword, mode display, PWM permission, and adopted target. Test enable requests without valid feedback or bus conditions, requests during faults, and old targets after reset. Example SDKs demonstrate interface connection; actual protection and timing require independent validation.

Debugging Checks

• Keep communication healthy while blocking feedback or bus permission and verify that controlword requests cannot create a false operating state.
• Send fault reset as both a sustained level and an edge, observing real faults, state transitions, and new-enable requirements.

Parameters, Units, and Command Updates

Servo interfaces need independently verifiable units for position, speed, current/torque, and time. Host engineering units, on-wire integer scaling, and internal normalized values are different layers; centralize conversions at controlled boundaries. Mixing peak/RMS, motor/load shaft, or mechanical/electrical speed can yield plausible numbers but incorrect motion.

Parameter tables should declare width, signedness, scale, defaults, legal range, activation conditions, and saving policy. Command updates also need effective time, sequence or cycle, and communication-loss rules; a target written long ago cannot remain the newest command forever. Reject out-of-range configuration; if continuous motion targets are clipped, follow documented limits and return adopted values and reasons.

Commit parameter combinations and large multiregister values completely so control interrupts cannot see half-new/half-old data. Use wide intermediates for conversions and handle integer overflow, position wraparound, and invalid floating-point values. Revalidate unconsumed targets when modes or feedback zeros change, preventing formerly legal values from becoming dangerous under new coordinates or scaling.

Verify encoding with distinctive bit patterns, then physical scale with controlled positive/negative motion. Log raw wire values, decoded values, limited/adopted values, and actual feedback to distinguish protocol word order from mechanical error. Recheck compatibility after scaling, pole-pair, transmission-ratio, or firmware-object-version changes; identical displays do not establish continued compatibility with old control software.

Debugging Checks

• Validate interfaces with positive/negative, boundary, and cross-word bit patterns, then compare the scale from wire values to mechanical motion.
• When changing parameter scaling or mode, check pending targets, versions, and control snapshots, ensuring old targets cannot execute directly in new units.

Communication/Control Boundary Integration

Servo integration must observe the complete command path from wire to mechanical output: protocol validation, control-ownership arbitration, state permission, target snapshot, control computation, and PWM activation. Packet capture proves only messages, while changing software variables proves only one stage. Record sequence numbers, times, and rejection reasons at each stage to locate a target-without-motion issue at the protocol or application boundary.

Communication and local current periods usually differ; define target holding, interpolation, adoption points, and expiration windows. Bursts from the master must not turn periodic control into message-triggered execution. Receive buffers should retain only permitted transactions with explicit expiration rules. When multiple interfaces connect, changing control source requires fresh commands and clear permission.

Start integration with one mode and one control source, confirm states and units, then add communication stress, mode changes, parameter access, and fault reporting. Compare desired targets, actual adopted targets, and feedback separately, observing current/voltage limits. Protocol retries must not repeat actions, and network recovery must not automatically replay old trajectories or clear internal drive faults.

The validation matrix should include stopped master updates, network exit from operation, delays and missed cycles, device reset, and recovery. Record communication state, drive state, command age, and output behavior, distinguishing synchronization, liveness, and execution deadlines. Host simulation verifies arbitration and conversions, but mechanical stopping distance and real sampling delay still require target hardware rather than virtual feedback.

Debugging Checks

• Trace reception, publication, adoption, and PWM activation using the same command sequence number to locate missing or late stages.
• Stop master updates and resume, checking application communication-loss action and control-source permission and ensuring old trajectories are not replayed automatically.

Electrical, Angular, and Mechanical Directions

First establish three corresponding direction definitions: power-terminal A/B/C phase sequence and positive current, feedback count/angle direction, and mechanical positive rotation from a specified viewpoint. Inconsistency may prevent stable commutation or allow apparent rotation with abnormal current under some conditions. 'Tuned until it turns' is not acceptance, and higher gains must not conceal sign errors.

Under unpowered or controlled conditions, verify raw feedback counts per revolution, wraparound, and direction, then compare phase-current channels with PWM outputs. Centralize electrical offset, pole pairs, and transform normalization in a convention table used by all algorithms and communication objects. Revalidate alignment parameters after rewiring, encoder changes, or mounting changes rather than assuming stored values remain correct forever.

With limited current and speed, check positive/negative targets, dq feedback, and mechanical direction, and compare angle-offset effects with the model. Transmission ratio, load-side feedback, and backlash also affect final axis direction and position; motor-shaft checks alone are insufficient. Plan alignment for braked or constrained loads according to the system; movement-producing tests are not side-effect-free software checks.

Save wiring version, feedback configuration, offset source, and validation waveforms, linking raw counts, mechanical angle, electrical angle, and dq currents to one timebase. When regressions occur, compare these facts before gains. Example pole pairs, channel order, and sensor models are test conditions; after porting, rebuild evidence using the actual motor and power board.

Debugging Checks

• Compare physical direction, feedback counts, and dq currents for positive/negative targets, ensuring the convention table explains every result.
• Repeat full-revolution checks after wiring or feedback changes, ensuring old offsets and pole-pair settings are not reused without verification.

Multiloop Tuning and Trajectory Validation

Tune servo cascades from the inside outward: sampling and current loop first, then speed and position, limiting each layer's output and checking units/direction. Outer loops cannot repair an unstable inner loop, and overly fast outer loops impose untrackable targets on inner loops and mechanics. Determine bandwidth relationships from delay, load, and resonance rather than copying fixed gains.

Create repeatable trajectories and load conditions and record each loop's target, feedback, error, and limit state. Current steps, speed changes, and position moves excite different plants; one position trace is not evidence for every loop. Frequency analysis helps identify bandwidth and margin, but injection point, amplitude, operating point, and nonlinear limits affect results and require explicit scope.

Change only a limited set of parameters at a time and preserve before/after waveforms and parameter sets. For oscillation, check saturation, feedback delay, angle/scaling, and mechanics before blaming gains. Add feedforward and filters separately after basic loops are trustworthy so improvements remain explainable; sustained limiting also requires integrator and release-recovery verification.

Trajectory validation should cover short/long moves, reversal, dwell, continuous updates, and cancellation, checking consistent velocity/acceleration limits, stopping distance, and error monitoring. No-load tuning does not establish full-load behavior, and one-way success does not cover reversal backlash. After changes to power boards, feedback filtering, PWM period, or load, recheck affected loops and timing rather than presenting reference-design results as your own measurements.

Debugging Checks

• Preserve before/after records under the same conditions in current/speed/position order, checking each layer's limits and frequency-analysis injection conditions.
• Replay reversal, cancellation, and limit-reaching trajectories, checking error recovery, integrator states, and mechanical response against specified boundaries.

Communication Interruptions and Fault Recovery

Servo recovery must distinguish communication loss, drive faults, feedback loss, and supply problems. Network recovery establishes only a usable link; it does not clear other faults or validate old targets. Maintain separate communication state, drive state, command freshness, active faults, and operating permission so the host can identify the condition blocking recovery.

Communication-loss actions depend on product requirements and mechanics and may include hold, limited deceleration, or output disable; validate actual energy and axis behavior for each policy. Control uses the last complete snapshot until its defined expiry rather than refreshing liveness on arbitrary bytes. Entry to communication-loss or fault states must explicitly invalidate expired targets and unfinished trajectories so queued old start requests cannot execute after recovery.

Recovery first confirms that real faults are gone, feedback and parameters are valid, and communication configuration matches, then reestablishes permission through the required new controlword or local action. Clearing historical logs, clearing active faults, and resetting the protocol stack have separate meanings. Default outputs and brake coordination during disconnect, reconnect, or reset must suit the system rather than relying solely on the host to resend a stop packet.

Separately interrupt heartbeat/PDO, leave EtherCAT OP, reset the communication stack, and create local faults, recording trigger times and why recovery is allowed. Cover healthy networking with stalled control setpoints too. Logic can be host-simulated, but real stopping times and mechanical loads need target evidence; one successful automatic reconnection does not establish safe recovery as a whole.

Debugging Checks

• Freeze valid setpoints, disconnect the network, and inject local faults separately, checking that trigger reasons, output actions, and records remain distinguishable.
• After recovery, retain the old start value without issuing new permission and confirm the drive neither replays trajectories nor directly reenables.

Following Error, Logs, and Regression

Useful diagnostics connect symptoms with control-chain state rather than storing only a 'position error too large' code. On following faults, save trajectory target, actual position, speed, current target/feedback, limits, mode, command sequence, and relevant times. Include sampling periods and units, or logs from different versions cannot be compared directly.

Use bounded events or ring records, prioritizing the window around the first fault and marking lost-record and overwrite rules. Synchronous printing in control interrupts changes timing and may create or hide issues, so separate acquisition from export. Bus or feedback decline after a fault may be a consequence; later events must not overwrite the original limiting condition or late target that caused following error.

Compare regressions using fixed trajectories, load ranges, configuration, and firmware versions, reproducing first and then making minimal changes. Describe 'no recurrence' through trial counts, covered conditions, and unverified ranges; one normal motion does not prove root-cause removal. Host tests suit coordinate conversion and state logic, while mechanics, PWM delay, and feedback noise still require target hardware.

After repair or upgrade, rerun checks related to the change: angle/units after feedback changes, worst-case deadlines after scheduling changes, and cancellation/reversal after trajectory changes. Logs, raw traces, parameter sets, and versions together form reviewable records.

Debugging Checks

• When following error triggers, check before/after windows, first fault, limit flags, and command age, ensuring logs explain causal order.
• Retest before and after changes with fixed configuration and trajectories, preserving trial counts, raw measurements, and hardware evidence.

Rectification, DC Bus, and Inverter Bridge

A typical voltage-source variable-frequency drive rectifies AC input into a DC bus, then uses a three-phase inverter bridge to produce motor voltage. Rectifiers may be diode bridges, controlled rectifiers, or active front ends, determining input-current shape and whether energy can return to the grid. DC-fed equipment may omit input rectification, so draw the actual topology rather than describing every drive with the same power chain.

Bus capacitors smooth rectified ripple and temporarily store operating energy. Manage charging inrush at power-up; common precharge resistors and bypass contactors need states, feedback, and timeouts, while active precharge has its own control and faults. Reaching a bus voltage does not prove successful bypass; inspect contactor feedback or related diagnostics. Capacitors may retain energy after disconnection, so discharge paths and voltage confirmation require separate design.

PWM converts bus voltage into average phase voltage through the inverter bridge, with frequency, amplitude, and phase set by the operating algorithm. An ordinary diode rectifier generally cannot actively return braking energy to the grid; deceleration must account for bus, braking-unit, and load capabilities. Maintenance records should define actual boundaries of rectification, precharge, inversion, braking, and discharge; an MCU enable flag alone does not prove every energy path has the intended state.

Debugging Checks

• Check rectifier topology and braking/regeneration paths, listing preconditions and feedback sources for precharge, bypass, discharge, and inverter operation.
• Check bus behavior during charging, bypass failure, and power-off, assessing residual capacitor energy separately from software operating state.

Control Board, Sampling, and Protection

The control board handles setpoints, operating states, modulation, and measurement, but signals have different real-time needs. Phase currents serve fast control, bus voltage determines voltage capability and abnormalities, temperature informs thermal state and derating, and communication supplies slower commands and diagnostics. Placing all signals in one low-rate polling task can leave current data stale or hide bus faults behind prolonged averaging.

Sampling chains include shunts or other sensors, analog conditioning, isolation, ADCs, and scaling; protection may separately use comparators or driver desaturation detection. State the bandwidth, validity, and action path of control currents and fast protection signals. Software current limiting improves operating constraints, while fast hardware shutdown must perform its designed short-circuit/device-protection role. Normal execution of a control interrupt does not prove timely power-fault interruption.

Interface design must account for control-board reset, supply sequencing, default PWM levels, and fault polarity. Drivers need an explicit disabled state before MCU startup; loss of supply on the isolated sampling side must not make abnormal output appear to be real zero current. Preserve original diagnostic causes from drivers, ADCs, and operating algorithms. Reference designs offer architecture ideas, but protection thresholds, delays, and coverage require verification for the actual devices and product configuration.

Debugging Checks

• Draw separate control-sampling and hardware-protection paths, checking bandwidth, fault polarity, PWM during MCU reset, and default driver state.
• Inject sampling-side power loss, control-board restart, and protection inputs, checking validity bits, actual gate outputs, and recorded fault causes separately.

Motor, Load, and Supervisory Control

Variable-frequency-drive goals must match motor and load. Fans and pumps emphasize continuous speed adjustment, efficiency, and process control; conveyors or winders may require coordinated torque and acceleration/deceleration. These do not automatically imply servo positioning. Sharing a three-phase power bridge or FOC algorithm does not establish absolute positioning, multiaxis synchronization, or high-precision holding; state actual capability in interfaces and specifications.

Motor nameplates specify rated voltage, frequency, current, speed, and connection, which must be checked with wiring and parameter choices. Induction-motor speed differs from supply frequency through slip and changes with load; permanent-magnet angle and control strategies differ again. Host frequency, speed, torque, or process setpoints need a defined conversion chain and active channel; one unitless percentage cannot mean the same command in every mode.

Loads also determine startup and stopping. High inertia creates substantial braking energy, constant-torque loads may require sustained low-speed torque, and fans may already be windmilling before power-up. Collect load curves, inertia, rotation direction, permitted stopping methods, and motor cooling conditions. Supervisory control sets process targets, while local drives enforce constraints and validity; document this boundary so a host run command is not unconditional output permission.

Debugging Checks

• Check nameplate, star/delta wiring, and motor type, and define supervisory setpoints, conversion units, operating mode, and local enable conditions.
• Check startup with residual rotation, sustained low-speed load, and deceleration energy by load type, documenting unsupported positioning or synchronization functions.

Product Specifications and Operating Conditions

Product specifications need rated operating points and permitted ranges. Input supply, output current, output frequency, overload duration, ambient temperature, and cooling are interrelated; a short-term peak is not long-term continuous capability. State whether control accuracy means output-frequency or mechanical-speed accuracy: precise electrical frequency under open-loop V/f does not imply equally precise mechanical speed as load changes.

Validation conditions should cover motor/load types, both directions, bus variation, acceleration/deceleration, and thermal states. Continuous low-speed running may reduce shaft-fan cooling, while higher switching frequency may increase power-stage loss, requiring design-based derating. Load inertia and braking repetition change braking-unit thermal load; one successful stop does not prove continuous-cycle capability.

Separate functional, dynamic, protection, and diagnostic requirements, defining methods, time windows, errors, and evidence sources. Rotation proves only a basic chain, not supply-disturbance, communication-timeout, or abnormal-recovery performance. Reference-design power and temperature ranges belong to its board and must not become current-product claims. Regulatory, functional-safety-level, and certification statements must come from existing product records; routine firmware tests and component certification do not establish whole-product compliance.

Debugging Checks

• Distinguish rated, peak, and continuous capability, attaching supply, load, temperature, cooling, and test-duration conditions to each specification.
• Accept frequency output, mechanical speed, thermal state, and recovery separately, preserving untested conditions without copying reference-board ratings or inferring certification.

DC-Bus Voltage and Energy Paths

Bus voltage is an important energy-state observation, but interpret changes with input and load. Inadequate rectifier capacity, input sag, or heavy acceleration can lower it; regenerative braking can raise it; rectification ripple is a normal topology characteristic. For approximately constant capacitance C, stored energy is E=½CV², with C in farads, V in volts, and E in joules. This estimates capacitor energy rather than replacing ripple-current, loss, and lifetime analysis.

During braking, trace mechanical kinetic energy through the bus to the braking unit. With a nonregenerative front end, capacitors generally store it temporarily before a chopper and resistor dissipate it. Deceleration is jointly constrained by the resistor, switches, temperature rise, and control limits. Longer deceleration reduces instantaneous power but cannot guarantee controlled stopping for every load or power-loss case; gravity or externally driven loads may continuously supply energy.

Precharge completion, normal supply, braking, and discharge need different states and diagnostics. Software may monitor bus rise rate, bypass feedback, and post-braking trends, using design-specific criteria. Invalid bus measurements must not permit increased modulation or braking based on erroneous voltage. Save bus voltage, input state, operating stage, and braking duty to distinguish supply faults, excessive regeneration, and measurement errors rather than attributing every overvoltage to short deceleration time.

Debugging Checks

• Estimate energy in one deceleration and permitted capacitor-voltage change, checking front-end regeneration and braking-resistor pulse/continuous thermal capability.
• Cross-check precharge, bypass, braking, and discharge states, and inject invalid bus measurements to verify control does not use an incorrect available voltage.

Three-Phase Inverter Bridge

A three-phase two-level inverter comprises three half bridges whose midpoints connect to the motor. Average line-to-line voltage depends on duty-cycle differences and bus voltage. Motor neutral normally floats, so leg-to-bus and phase-to-neutral voltages differ. State measurement reference, peak, and RMS definitions rather than treating oscilloscope switching-pulse peaks as motor fundamental RMS voltage.

Upper and lower switches must not conduct simultaneously; complementary PWM and dead time must account for driver propagation, device turn-off, and asymmetric delay. Dead time changes output, while minimum pulse width and bootstrap supply restrict duty cycles. Higher modulation may shrink current-sampling windows, so mathematical voltage limits alone do not define feasibility. Overmodulation and discontinuous modulation require separate validation; do not silently change algorithms while retaining old sampling settings.

First check counting, phase sequence, polarity, and inhibit logic without power output, then validate actual gates and legs incrementally under prescribed conditions. For reversed motors, imbalance, or current spikes, compare PWM requests and hardware waveforms together; correct registers do not prove correct gate waveforms. Explain leg states and freewheeling paths after output stops too: all PWM low does not instantly remove motor current or bus energy.

Debugging Checks

• Check leg polarity, complementary relationships, dead time, and shadow loading, including bootstrap and minimum-pulse limits at extreme duty cycles.
• Compare final duty cycles, gates, and average line-to-line voltage, observing freewheeling and bus changes after disable rather than only software PWM flags.

Power Devices and Gate Drivers

Power-device selection must consider conduction, switching, voltage withstand, thermal behavior, and fault tolerance together. IGBTs, silicon MOSFETs, and silicon-carbide devices differ in gate voltage, turn-off method, and parasitic sensitivity and cannot be exchanged by current rating alone. Gate resistance, loop inductance, and layout determine slew rates and ringing. Faster switching may reduce some losses while increasing common-mode interference and overvoltage, so validate actual waveforms.

Gate drivers provide current amplification, isolation, and some protection. Undervoltage lockout, Miller clamps, desaturation detection, and soft shutdown each have trigger conditions and timing that require configuration from the selected datasheet. Excessive desaturation blanking/filtering delays real faults, while too little causes false trips. Soft shutdown changes current fall and voltage overshoot but does not automatically eliminate every short-circuit energy risk.

Firmware must understand driver ready, fault, reset, and enable interfaces rather than treating drivers as PWM conduits. Inhibit output before driver supplies stabilize, latch driver-fault causes, and check all leg states. Before resetting a driver fault, determine whether its cause is gone and whether restarting needs precharge or motor checks. Calibrate protection currents, gate voltages, and blanking times for actual devices and power boards.

Debugging Checks

• Check power-device and driver recommended conditions, fault paths, and reset requirements individually, retaining evidence of gate ringing and turn-off behavior.
• Cover driver undervoltage, desaturation, and disable inputs, measuring actual shutdown and fault-report times and assessing overshoot/false-trip tradeoffs.

Isolation and Signal Interfaces

Define isolation boundaries between accessible interfaces and power-reference ground. Communication, encoders, sampling, gate drivers, and auxiliary supplies may use different isolation methods; a high component withstand rating does not establish whole-board isolation. Working voltage, transients, creepage, clearance, pollution degree, and altitude jointly affect design and require review against applicable standards and product conditions.

Signal isolation also affects delay, defaults, and power-loss behavior. Check PWM propagation differences and output behavior under common-mode transients, analog-isolation linear range/gain/fault indication, and digital-communication direction and bus reference. Power isolation must match signal boundaries; a debug cable bridging the two sides may defeat intended isolation. Include measurement and debug connections in interface diagrams.

Ordinary electrical isolation and safe torque off are different functions. PWM inhibition is an operating-control action, but cannot be called STO without the corresponding architecture, diagnostics, and validation; isolator certification does not establish whole-system safety level. Firmware documents should accurately describe observable/controllable interfaces and defer isolation and functional-safety conclusions to formal design evidence. Preserve fault-default states during debugging rather than forcing abnormal indications to normal for communication convenience.

Debugging Checks

• Draw isolation boundaries for every signal, power, and debug connection, checking working conditions, layout distances, and default states after power loss.
• Verify output behavior under common-mode disturbances and interface-side power loss, distinguishing ordinary disabling, isolation performance, and safety functions supported by existing formal evidence.

PWM and ADC Synchronization

Synchronizing PWM and ADC in a variable-frequency drive aims to obtain interpretable current and voltage samples, not merely to give them the same frequency. Sample-and-hold must fall within a window allowed by the topology, avoiding switching transients and allowing sufficient amplifier settling. Center alignment, sectors, and duty cycles all change measurable intervals; sampling triggers must follow modulation or use a validated fixed region.

ADC conversion completion, DMA transfer, and control computation follow sampling, and new duty cycles still await a loading event. If bus-voltage sampling is asynchronous to current, define its age in voltage reconstruction. Multichannel scanning can introduce time differences between phase samples, affecting coordinate transforms at high speed or during fast current changes. Even simultaneous-sampling hardware requires verification of triggers and result association, not just configuration-option names.

Verify triggers, sampling, reads, and output activation on the actual counter timeline, covering low modulation, sector boundaries, and near-maximum duty cycles. Control interrupts need adequate margin before the next load; communication and diagnostic stress may delay only a few cycles. Insufficient sampling windows or incomplete conversions must produce validity flags and defined handling. Do not treat old ADC data as fresh current, amplifying errors in current limiting or observers.

Debugging Checks

• Sweep duty cycles and sectors. Measure window width, analog settling, sample-and-hold, and loading margin, checking that the shortest window meets configuration requirements.
• Correlate ADC and PWM by cycle number. Add communication stress and incomplete conversions, verifying stale-sample identification and specified timeout actions.

Phase Current and DC-Bus Current

Phase current and DC-bus current are different physical quantities. Phase-line sensors directly observe winding currents; low-side shunts measure during particular conduction states; a single bus shunt indirectly extracts phase information from switching states. Average bus current indicates power or input loading. It cannot replace instantaneous phase currents, and the ordinary arithmetic average of three phase currents cannot estimate DC input current.

Single-shunt reconstruction needs enough independent samples during active vectors, with signs mapped by sector and switching state. Short active vectors create unmeasurable regions. Pulse shifting or substitute samples change voltage and data age. Reconstructing the third phase from two requires an approximately zero three-phase sum, which may fail during ground faults or common-mode leakage. A reconstructed zero sum is not independent proof of hardware health.

Distinguish current use for control, protection, and power analysis. Control needs time-defined samples; fast overcurrent needs a shorter path; input-power estimation needs suitable averaging synchronized with bus voltage. Revalidate sampling triggers, amplifier ranges, protection coverage, and voltage observation after topology changes. Log raw samples, switching states, validity flags, and reconstruction together so filtered currents do not hide short windows or channel saturation.

Debugging Checks

• Label sensor locations and purposes separately. Check single-shunt mapping and unmeasurable-region handling; reconstruction identities do not prove healthy sensors.
• Use extreme modulation, saturation, and simulated ground faults to check control/protection coverage, comparing sample age, final reconstructed currents, and raw waveforms.

DC-Bus Voltage and Temperature Sampling

Bus voltage and temperature generally change more slowly than phase current, but sampling must still suit their purposes. Bus voltage supports modulation normalization and over/undervoltage decisions and may change rapidly during precharge or braking. Temperature supports derating and protection; measurement location, thermal inertia, and channel faults matter. Long averaging with only smooth values can misrepresent available voltage or slow protection.

High-impedance bus dividers require consideration of input impedance, isolation-amplifier range, and ADC sample-and-hold settling. Divider resistance and voltage-rating distribution are hardware design matters; software conversion must match actual resistors and gains. Temperature may come from module NTCs, heatsinks, or other sensors; location readings are not instantaneous junction temperature. Handle NTC nonlinearity, open/short circuits, and reference drift separately rather than treating every full-scale anomaly as hot or cold.

Data interfaces should expose raw values, engineering values, validity, and sample times, separately documenting filters for control estimates, display, and protection. Isolation-side power loss may produce a device-defined fault output; check validity before normalization. Validate multiple range points and transitions with controlled inputs, including lost updates. Product-specific requirements define thermal and bus thresholds; example-device values are not universal settings.

Debugging Checks

• Use known inputs to check bus scaling and NTC conversion across low, middle, and high ranges, open/short circuits, and isolation-side power loss, verifying validity-first handling.
• Measure control, display, and protection filter delays separately. Verify voltage-data age during precharge/braking and the policy for lost temperature updates.

Calibration, Filtering, and Measurement Error

Calibration distinguishes offset, gain, linearity, and dynamic errors. Internal ADC calibration may improve the converter but does not automatically remove shunt, amplifier, divider, or sensor errors. Acquire current offsets only at genuinely zero current; residual motor rotation or freewheeling current invalidates simple averaging as offset. Gain calibration needs a trustworthy reference and range coverage. Single-point zeroing does not establish full-range accuracy.

Filtering reduces random noise but cannot repair wrong scaling, saturation, or inadequate sampling windows. Match acquisition time to source impedance and ADC input characteristics; channel switching may need additional settling. Software averages spanning state changes mix precharge, operation, and braking meanings. Bind digital filter coefficients to task periods and include delay in current-limit and observer models.

Calibration parameters need versions, temperature, date, hardware association, and integrity checks. Replacing sampling boards, ADC references, or amplifier gains must invalidate old parameters or require explicit revalidation. Acceptance can cover static known inputs, PWM common-mode interference, and actual operation, recording raw/processed data and checking range clipping and low-amplitude offsets. Smooth filtered current alone does not prove correctness; connect error budgets and diagnostic evidence to control use.

Debugging Checks

• Check offset, gain, and linearity at genuine zero current and multiple known inputs, confirming calibration association with the correct board and reference voltage.
• Vary PWM common-mode disturbances and ADC acquisition time to check dynamic errors. Compare raw and filtered values and delay without letting filters hide invalid sampling windows.

Operating States and Start/Stop

A variable-frequency drive's start request must pass through the operating state machine before becoming a frequency or torque reference. Standby, precharge, ready, starting, running, decelerating, and fault states each need entry conditions and exit actions. Completed precharge alone does not permit power pulses: check gate-drive supply, sampling validity, contactor feedback, and command source. Share a consistent start-permission snapshot with the control interrupt so the fast loop cannot retain an old enable after background revocation.

Distinguish stationary motors from already rotating loads during startup. Airflow can backdrive fans, and backflow can rotate pumps. Applying a fixed initial frequency without identifying speed/direction can create current surges. Flying-start capability depends on motor type, measurements, and algorithms, not one universal delay. Induction-motor vector control requiring flux buildup also needs timeout and constrained exit paths during flux preparation.

Stop commands must at least distinguish controlled deceleration, coast stop, and fault shutdown. Controlled deceleration keeps the inverter active and needs a regenerative-energy path; coast-stop time depends on the load. Clearing a run bit proves neither an unenergized bus nor a stationary shaft. Report requested state, actual state, and stop reason separately. Decide restart permission independently after reset, preventing stored run commands from causing unexpected restart.

Debugging Checks

• Apply start requests with incomplete precharge, unready gate drive, and invalid samples separately. Confirm the prescribed state is maintained, output enable never appears briefly, and failure reasons are readable.
• Test command withdrawal during deceleration, restart before stopping completes, and old commands remaining after reset. Record actual output, bus changes, and state transitions against designed restart rules.

V/f Scalar Control

Scalar speed control of induction motors generally varies fundamental voltage amplitude with stator electrical frequency to maintain flux over a range. A constant ratio assumes approximately steady state and relatively small stator-resistance drops. Specify line-to-line RMS versus phase-voltage amplitude and frequency in hertz. Do not insert nameplate line-voltage numbers directly into modulation calculated from phase-voltage peaks.

At low frequency, stator-resistance drops become more significant, so linear voltage scaling may underexcite flux. Compensation can also overexcite and heat the motor, requiring validation against parameters and current limits. Above base frequency, the DC bus and modulation range limit voltage; further frequency increases generally enter field weakening and change continuous torque capability. Scalar control does not automatically guarantee low-speed full load or fast torque response.

Synchronous mechanical speed is n_s=60f_e/p in revolutions per minute, where f_e is stator electrical frequency and p is pole pairs. Actual induction-motor rotor speed also depends on slip and load. Normal displayed frequency with falling shaft speed is not necessarily a communication-reference error. Coordinate reference ramps, low-frequency compensation, bus normalization, and current limiting. Distinguish output frequency, estimated shaft speed, and measured shaft speed rather than confusing all three under one register name.

Debugging Checks

• Check nameplate connections, line/phase voltage conversion, poles versus pole pairs, and software voltage units. Check actual modulation amplitude at output limits so correct conversions are not obscured by clipping.
• Validate low-frequency compensation and base-frequency transitions under different loads. Record current, actual speed, temperature-rise trends, and current-limit state. Preserve load conditions with results; no-load running alone is insufficient.

FOC / Vector Control

First identify the motor type for vector control. Rotor-flux-oriented induction-motor control needs measured or estimated speed and a flux angle, with flux and torque components controlled by corresponding currents. Permanent-magnet motors rely on rotor electrical angle and their flux model. Both share transforms and current-loop structures, but parameters, startup preparation, and sensorless observer equations are not interchangeable.

For induction motors, the rotor-flux frame's electrical angular speed includes mechanical speed times pole pairs plus slip angular frequency, all in rad/s. Shaft speed is not directly the synchronous frame speed. Rotor time constant affects flux orientation, and winding temperature can shift parameters. Observe excitation current, torque current, and estimated flux together; good current tracking alone does not prove correct flux direction.

Schedule current loops, speed loops, flux buildup, voltage limits, and current limits on explicit sampling cadences. If estimated speed is invalid, select constrained reference hold, return to startup, or stopping according to stage; do not close the speed loop unconditionally. Low/zero-speed observability depends on algorithm and measurements. Sensorless vector control does not imply zero-speed torque holding under arbitrary loads. Speed-control products need torque/speed validation under specified conditions; positioning has additional feedback/mechanical constraints.

Debugging Checks

• Check motor model, pole pairs, speed units, flux-angle direction, and current signs. Confirm feedback direction in low-risk conditions with known rotation, rather than masking sign errors by adjusting gains.
• Cover flux preparation, closed-loop takeover, voltage limits, and speed-estimate failure. Record flux, both axis currents, and takeover state, verifying no extra reference jumps and valid exit rules.

Acceleration, Deceleration, Current Limits, and Loads

Acceleration/deceleration times describe reference changes; actual mechanical response also depends on inertia, load torque, and available current. For the shaft-side model J·dω_m/dt=T_e−T_L, inertia is in kg·m², mechanical angular speed in rad/s, and torque in N·m, with all quantities referred to the same shaft. This checks ramp plausibility but does not replace specific friction, transmission-elasticity, and process-load models.

Overly fast acceleration references may sustain torque-current limiting. Continued speed-error integration causes overshoot after limiting clears, requiring speed-loop coordination with current limits and implementation-consistent anti-windup. Scalar current limiting may adjust frequency slew or voltage, differing from vector torque limits. Expose readable limiting reasons and duration rather than merely indicating an unmet speed target.

During deceleration, motors may return mechanical energy to the bus. Braking resistors, regenerative front ends, or extended deceleration determine achievable stop trajectories. Relaxing overvoltage criteria does not dispose of energy. Evaluate high inertia, backdriven fans, and frequent starts separately; fan load laws do not apply directly to constant-torque conveyors. Define whether live ramp changes continue from the present reference or regenerate paths, avoiding abrupt frequency changes.

Debugging Checks

• Vary acceleration time for specified inertia/load combinations. Distinguish reference ramps, actual speed, and current-limit duration, checking integrator states and recovery after limiting clears.
• Cover deceleration with braking available, absent, and temporarily unavailable. Check bus trends, extended ramps, and stop reasons. Trajectory acceptance requires both electrical and mechanical constraints.

Run Commands and Reference Channels

Variable-frequency drives often offer panel, terminal, analog-input, and communication control. Run commands and speed references may use different channels, but the product must define valid combinations and authority to start, stop, and reverse. Form command objects with source and validity first, then submit through arbitration to the state machine. Multiple interrupts must not directly write run flags or frequencies, making the last write an implicit priority.

Reference channels also need dimensions, scaling, deadbands, and fault behavior. A broken analog input may appear out of range or fixed; communication registers must distinguish frequency, shaft speed, and proportional references. Centralize conversion and report the resulting actual target. Reading back the raw written value does not establish that it passed direction, maximum-frequency, and ramp constraints. Reversals must follow operating rules, not immediately swap phases or invert modulation angular speed.

Arbitration must define stop priorities, external inhibit effects, and local/remote takeover conditions. Publish control ownership separately from actual operation to explain accepted remote writes that are not executed. Communication acknowledgment proves protocol acceptance only; the interface contract must relate it to command application. Application stops and ordinary enables must not be independently labeled Safe Torque Off. Safety functions depend on actual system design and verification scope.

Debugging Checks

• Continuously issue opposing run requests and different references from two inputs. Check published priorities, rejection reasons, and actual targets, confirming no single-cycle ownership chatter.
• Check units, direction, and current ramps when switching panel, terminal, and communication references. For analog overrange or restricted remote writes, readback must explain the final adopted value and source.

Modbus Mapping and Write Permissions

A communication register table is a device-interface contract specifying addresses, types, units, scaling, valid ranges, access conditions, and activation stages. Modbus registers are 16 bits and the protocol defines multibyte transfer byte order. Devices must additionally define cross-register word order and sign interpretation for 32-bit application quantities. Distinguish documented numbering from frame addresses to prevent offsets caused by host numbering conventions.

Run commands, parameters, and status quantities need distinct permissions. Read-only feedback must not become writable merely because it shares an underlying array. Motor parameters restricted to stopped operation must not silently change while running. Validate length, addresses, ranges, and state conditions before committing an entire group. Mixed old/new multiregister references or parameters can form valid but wrong values; fast loops must read one generation's snapshot.

Distinguish protocol errors from application rejection: unsupported functions, invalid addresses, and disallowed values need interface-defined responses. Asynchronous actions also need processing, completed, or failed states. Serial broadcast writes have no per-device responses; silence does not prove nonexecution. New parameter fields need compatibility versions and default behavior. Do not reuse an old address with changed units, causing old hosts to assign another physical meaning to the same number.

Debugging Checks

• Use raw frames to check addresses, byte order, cross-word order, and signed boundaries, including physical readback. Test responses for read-only addresses, out-of-range values, and prohibited writes during operation.
• Interleave multiregister writes with control cycles, confirming that applications see complete versions only. Verify execution/response rules separately for broadcasts and unsupported functions, with diagnosable rejection logs.

Parameter Activation, Storage, and Recovery

Parameter changes have at least receipt, validation, application, and persistence stages. Real-time references usually need no per-update storage; motor models and power-stage settings may require stopped operation and coefficient rebuilding. Successful communication writes, algorithm adoption, and survival across reboot are separate facts. Expose parameter identifiers or versions and states so a power cut before saving is not mistaken for lost configuration.

Persistent records may use validity markers, versions, lengths, and checksums while retaining a recoverable previous complete configuration; atomic update methods depend on storage media and firmware. For internal-Flash EEPROM emulation, check erase/program granularity, endurance, interrupted-power behavior, and execution stalls. A library's power-loss recovery does not automatically guarantee application consistency. Related fields still need one validated commit unit.

Applying parameters also affects derived quantities and operating state. Rated-frequency changes may alter voltage curves; current-scaling changes affect display, control, and protection, not just UI fields. Factory reset must retain or explicitly reconstruct board calibration and hardware-type constraints; generic defaults must not overwrite dedicated measurement calibration. Unknown versions, corrupt records, or hardware mismatch at boot should report reasons and restrict startup, not interpret unexplained bytes as current configuration.

Debugging Checks

• Simulate reset or power loss during writing, validation, commit, and erase. Confirm boot adoption of complete, recognized versions only, checking backup records, error reporting, and startup restrictions.
• Repeatedly change related parameters, checking active, stored, and reboot-readback values. Monitor control cycles during erase/program operations to determine whether stopping or independent persistence scheduling is required.

Communication Timeouts and Control-Ownership Changes

Communication timeout is first a control contract, not a serial-error count. Frames for other devices, valid queries, or stale retransmissions do not necessarily renew the current controller's run permission. Define messages that refresh control leases or run heartbeats, calculate validity with monotonic time, and log reception, protocol validation, and command submission separately. Receive-interrupt activity alone must not preserve old run commands indefinitely.

Timeout actions depend on loads and product requirements: controlled deceleration, bounded holding of a limited target, or run revocation, accounting for deceleration energy and braking availability. Reconnection must not replay queued old start requests. Takeover validates the new channel, reasonable targets, and run permission before designed reference blending. Switching directly from a high remote reference to the panel value may create unacceptable speed jumps.

Serial gaps, checksum errors, and physical interference affect availability, but application timeouts need independent states/reasons. Stopping must not depend on timely background parsing; check command validity on an independently bounded cycle. Multimaster control, broadcasts, or local takeover after loss require explicit owner identity and revocation conditions if supported. Diagnostics should show active input, last valid command time, and invalidation action to distinguish link faults from ownership changes.

Debugging Checks

• Keep bus queries active while stopping control heartbeats, checking contractual command expiry. Inject retransmissions, delayed frames, and blocked parsing, verifying that validity is not refreshed incorrectly.
• Test reconnection, local takeover, and return of the original controller. Check reference transfer, renewed permission, and old-queue cleanup, recording maximum timeout-detection-to-output-change time.

Overcurrent Protection

Separate destructive fast faults, regulated current limiting, and longer overloads. Shorts or shoot-through can damage switches before a software cycle, so gate drivers, comparators, and timer fault paths must directly control outputs as designed. Display averages or slowly filtered current cannot replace this path. Fault interrupts record and coordinate subsequent states rather than serving as the sole shutdown mechanism.

Cycle-by-cycle timer handling and one-shot latching recover differently. Cycle-by-cycle limiting may release outputs at specified counter events; one-shot latching generally requires clearance conditions and explicit reset. Wrong modes can reenergize the bridge every cycle during persistent faults. Verify actual gate states through complementary outputs, dead time, and input polarity. Disabled registers do not prove correct external shutdown levels.

Derive criteria from selected power devices, measurement chains, and product conditions, considering detection error, blanking, and propagation. Distinguish noise trips from actual overlimits. Longer blanking reduces switching-transient trips but enlarges unprotected intervals; clean logs are not the optimization goal. Save trigger sources, sample saturation, operating stage, and reference changes. Use distinct codes for recoverable limiting and faults requiring explicit recovery, separating excessive load demand from hardware-path anomalies.

Debugging Checks

• Use prescribed low-risk signal injection to check comparator, timer, and gate-driver paths. Measure detection-input-to-gate delay, covering all bridge legs and persistent faults.
• Verify cycle-by-cycle limiting, one-shot latching, and restart after clearance separately, ensuring software does not clear faults prematurely. Analyze trips near switching noise and valid peaks instead of simply relaxing protection.

DC-Bus Undervoltage and Overvoltage

Interpret bus under/overvoltage by operating stage. Low voltage during precharge may be normal; a sudden running drop may arise from supply dips, rectification, or precharge-bypass faults. Deceleration rises may reflect regeneration. Log voltage changes, state, and braking requests in addition to range flags to distinguish energy imbalance from measurement faults.

Set thresholds, hysteresis, and confirmation times from actual voltage ratings, minimum operating voltages, measurement error, and conditions. DC-bus undervoltage, gate-supply undervoltage, and logic-supply reset are different observations and must not share recovery conditions merely because all are 'undervoltage.' Supply dips reduce available output voltage and may limit control; unchanged torque/high-speed demands affect current and stopping, requiring coordinated operating restrictions.

Overvoltage handling must check energy outlets. A braking request with overheated resistors, inactive choppers, or unavailable branches cannot justify normal-braking deceleration planning. After bridge shutdown, motor/bus behavior still depends on motor type and speed; voltage may not fall immediately. Diagnose stale samples, open dividers, and invalid isolation separately. Unknown bus voltage must not be treated as normal zero voltage permitting precharge.

Debugging Checks

• Apply identical voltage changes during precharge, steady operation, and deceleration. Check stage criteria, hysteresis, confirmation times, and event causes, ensuring running criteria do not falsely trip startup.
• Verify exit paths with unavailable braking, failed bus measurement, and restored supply. Record requests/feedback, ensuring recovery requires valid measurements and ready hardware.

Temperature Monitoring and Protection

Temperature protection starts with measurement location. Heatsinks, module thermistors, control-board ambient, and motor windings represent different thermal processes; none is automatically power-chip junction temperature. Thermal resistance and delay separate sensors from hotspots. Transient losses may raise junction temperature while slow readings look normal. Evaluate continuous-load limits jointly with losses and cooling.

Thermistor channels need nonlinearity, component tolerances, divider-reference, and ADC-error analysis, with tables/fits covering the actual range. Detect open circuits, shorts, and stale samples rather than mapping all to minimum temperature. Calibration reduces bias but not heat-transfer delay. If loss estimates assist derating, document model applicability and temperature-validation methods.

Protection may include warning, gradual derating, and fault stop, with hysteresis, minimum hold times, and reset conditions matching product requirements. Fan failure, blocked airflow, low-speed self-cooled motors, and high ambient temperatures change load capability; one ambient test cannot cover all conditions. Module thermistor monitoring and shutdown designs guide architecture, but their thresholds are not universal protection settings for another drive.

Debugging Checks

• Check physical locations, units, table ranges, and failure codes for every temperature value. Use known inputs for open/short and endpoint tests, ensuring abnormal inputs cannot appear as normal low temperature.
• Combine ambient temperature, load duration, and degraded cooling. Observe warning, derating, stop, and recovery order. Preserve measured temperature and thermal predictions separately, checking worst-case delay.

Fault Latching, Recording, and Reset

Track currently active faults, occurred but unacknowledged faults, and the first stop-causing event separately. A drive fault may lead to undervoltage, invalid speed feedback, and control timeouts; the last error is not necessarily the cause. Include monotonic time or control-cycle IDs, operating stage, and source. Add calendar time in background display if desired; unstable wall-clock time cannot order fast-loop events.

After faults, perform bounded output actions before freezing essential incident data. Flash logging, text formatting, and communication reporting must stay outside critical shutdown paths. Ring buffers retain pre/post-trigger current, voltage, references, and limits, with sample-loss and overwrite counts. Mark data invalid when faults also affect measurements, preventing saturated post-fault values from being mistaken for genuine pretrigger currents.

A vanished condition is not acknowledgment, and acknowledgment is not run permission. Control-library divisions into active faults, cleared-but-unacknowledged faults, and idle can guide design, but add product precharge, driver latches, and external permissions. Reset requests must check eligibility and report failure, not continuously clear flags to conceal persistent faults. Allowed retries need counts, intervals, and cumulative-fault policies; such logic is not evidence of functional-safety certification.

Debugging Checks

• Inject two faults and a later measurement failure in known order. Check first event, current bitmap, and history, ensuring the first cause is retained and frozen data includes validity flags.
• Issue reset/start requests with active faults, cleared but unacknowledged conditions, and missing post-acknowledgment permission. Check gate states, return reasons, retry limits, and log completeness.

Motor Parameters and Load Conditions

Start system integration with traceable motor, connection, and load configurations. Record type, nameplate voltage/frequency, rated current, pole pairs, connections, and cooling, matching software physical definitions. Nameplate current may differ from algorithm phase-current peak, while delta/star connections affect winding conversions. Copying another motor's working parameters can simultaneously change flux, current limits, and display scaling.

Define self-identification conditions and permitted actions. Algorithms may use stationary injection, rotation, or rotor restraint, requiring suitable mechanical permission and exits. 'Complete' status does not prove accuracy at every temperature, speed, and load. Preserve motor state, sampling calibration, and parameter versions; validate model/real response with independent conditions rather than using the same data to estimate and prove validity.

Load records need referred inertia, torque-versus-speed characteristics, breakaway resistance, backdriving potential, and continuous duration. No-load startup proves only that the sequence works in that condition, not high-inertia deceleration, low-speed cooling, or process peaks. Speed-control drives need specified-load startup, steady speed, limiting, and energy-handling evaluation. Accurate holding additionally requires feedback, brakes, and system capability; frequency accuracy alone is insufficient.

Debugging Checks

• Check every parameter against motor connections and measurement units. Link nameplates, board calibration, and software versions, and check startup restrictions for missing parameters or mismatched motor types.
• Validate identification at speed/load conditions excluded from estimation, comparing current, actual shaft speed, and limits. Record cold/hot and mechanically constrained conditions separately, stating coverage.

Startup, Speed Control, and Stopping

Integrate startup, speed control, and stopping as a complete event chain; separate successful jogs do not establish system acceptance. Begin from power-up, recording precharge feedback, driver readiness, sampling calibration, run permission, reference generation, and output order. Give each step observable success/timeout outcomes so early host commands or delayed contactor feedback still follow the designed progression.

Speed tests cover small changes, large ramps, direction requests, and load disturbances, preserving raw targets, constrained targets, and real shaft speed. Without shaft measurement, evidence proves only frequency or estimates, not mechanical-speed accuracy. Align communication times and control cycles to separate transport delay, ramp limits, and response. Slow host refresh can create stair-step plots that are not motor oscillation.

Stop tests examine both shaft and bus. Controlled deceleration checks braking availability, bus trends, and output exit timing; coast stops measure load-dependent mechanical stopping time. Repeated starts/stops accumulate resistor/motor heat, so one stop does not establish repeated operation. External inhibits or faults during startup, steady operation, or deceleration may use different exits. Check final states and renewed-request requirements after recovery.

Debugging Checks

• Apply identical start/stop sequences to first operation after power-up and repeated hot operation. Check state timing, bus voltage, and braking requests. Delay precharge feedback and run permission, confirming that commands cannot bypass preparation.
• Use one timebase for speed steps, ramps, and stop events. Preserve targets, constrained targets, measured or estimated shaft speeds, and states, specifying the feedback evidence used by each criterion.

Undervoltage, Overcurrent, and Limited States

Limited-state verification establishes what the device can deliver and when it must exit operation. Undervoltage reduces available voltage, overcurrent criteria may trigger fast shutdown, and regulating current limits may prevent target speed. These need different failure criteria. Predefine inputs, durations, expected states, and output constraints, observing unrestricted operation, limit entry, sustained limiting, and recovery.

First validate fault criteria/transitions in models, interface simulation, or controlled signal injection, then verify required hardware paths on the real device. Changing software measurements proves software branches only, not comparator, isolator, timer, or gate response. Fast overcurrent and control-current measurement may have different bandwidths/filters. State the triggered path so slow tests are not mislabeled short-circuit protection acceptance.

After limits clear, check internal controller state and target transfer. Sustained voltage/current limits can accumulate integration, invalidate observers, or retain stale references, creating recovery surges. Bus voltage may recover before gate supplies or measurements are ready. Wait for all prerequisites, then recover or remain stopped as defined. State injection levels and operating coverage; simulated passes do not establish product certification or complete fault coverage.

Debugging Checks

• Vary duration and operating stage for the same undervoltage waveform, checking differences in limiting, faults, and recovery. Preserve integrators, estimate validity, and reference transfer, checking abnormal post-limit peaks.
• List software-input injection, comparator-input injection, and actual output-chain verification separately, recording sources and response times. Limit conclusions to their tested paths without cross-layer inference.

Logs, Recovery, and Regression Verification

Repeatable integration requires saved test inputs and results. Logs need firmware IDs, hardware versions, motor settings, parameter IDs, command sources, and operating conditions; waveforms need sample periods, dimensions, and validity. Record serial packet loss or decimation with sequences and rules, or apparent curve differences may be logging artifacts. Correlate fast-loop buffers and slower state logs through event cycle IDs.

Recovery verification spans resets and power cycles, checking contractual retention/clearance of fault records, parameters, run permission, and ownership. After reconnection, hosts must read current states and decide actions rather than resend preinterruption commands solely because links recovered. Persistence busy states, corrupt records, and incompatible versions need reproducible inputs and observable outputs to distinguish configuration recovery errors from algorithm faults.

Build regressions around defined product behavior, preserving sequences, initial conditions, and criteria. Analog comparisons may use engineering-based numerical/time tolerances; state order, illegal output enables, and prohibited automatic restarts need independent checks. Do not merely replace baseline curves to hide new-firmware differences. Explain requirement changes or fixes and retain old baselines/reasons. Compare debug-enabled timing against normal operation.

Debugging Checks

• Replay baseline and new versions with identical configuration and inputs. Check waveform units, cycles, missing-sample flags, and event alignment. Ensure requirement-based tolerances and independent discrete-state criteria rather than curve comparison alone.
• Cover reset during storage, restart after faults, and control-link recovery. Check parameter versions, historical events, and run permission. Disable debug output and recheck key responses, recording tool-induced timing differences.

Power Supplies, Power Stage, and Control Board

A servo drive's system boundary includes auxiliary power supplies, the DC bus, three-phase power bridge, gate drivers, sampling, and control board. The control board determines targets and modulation, the power stage delivers bus energy to the motor, and auxiliary supplies keep the control circuitry and drivers operating. Their startup and power-down sequences affect output permission; the MCU program reaching its main loop does not establish that the power section is ready.

When building a signal table, specify active levels and default states for each supply monitor, driver fault, PWM enable, brake, and feedback interface. Pins may be high-impedance during reset; hardware should provide deterministic output states consistent with the design, with software taking over after initialization. Bus measurements and gate-driver undervoltage status must also participate in permission logic, preventing modulation from continuing when the control supply is healthy but gate power has not been established.

Split board bring-up into modules: first confirm low-voltage supplies and clocks, then verify sampling, driver logic, and PWM without power applied, and finally connect the bus and motor under controlled conditions. Define observable quantities for every step and record board versions, configuration, and fault entry points. Rated voltages, currents, layouts, and components in a reference design apply only to that design; verify them again against the actual hardware when porting.

Software should maintain independent states for supplies, power-stage readiness, control initialization, and run permission, retaining which stage failed first when a fault occurs. Do not bypass all conditions by setting one global enable variable to true. During integration, observe the establishment and release sequence of the bus, driver supplies, and output permission together, with particular coverage of power-on fluctuations, partial power loss, and stale commands after reset.

Debugging Checks

• Record a timeline for control power, gate power, bus detection, and PWM permission, and check that output is never permitted while any required condition is unmet.
• Introduce an auxiliary-supply or driver-supply fault independently, and check the reported cause, default pin states, and conditions for restarting.

Control Tasks and Communication Interfaces

Servo firmware usually separates current control, slower speed/position control, communication services, parameter management, and diagnostics into execution paths with explicit periods. Communication supplies targets and modes, which the controller uses at fixed adoption points; receiving a frame must not directly alter PWM execution timing. The real-time budget must cover sampling, feedback updates, control computation, modulation, and actual register loading.

Interface definitions should specify target units, positive direction, limits, valid states, and update timing to form a complete command snapshot. The communication task must not modify mode, controlword, and target separately in a shared structure; consumers accept only a fully validated, consistent version. Use unified command arbitration for PDO, serial, and local debugging inputs, explicitly identifying the active control source and communication-loss policy.

Keep blocking access, dynamic allocation, and unbounded logging out of the fast current loop; move parameter storage and long protocol transactions to the background. When decimating speed and position loops, calculate discrete gains using their actual periods instead of copying the fast-loop period to every loop. Task priorities are only scheduling tools; measure how preemption and critical sections affect deadlines as well.

During integration, observe protocol arrival, command publication, control adoption, and output effect separately to distinguish late targets from fast-loop overruns. Test full communication load concurrent with background storage and fault reporting, confirming that control still executes within budget. Measuring only average CPU utilization can miss occasional worst-case paths; record overrun counts and versions instead of judging real-time behavior from a normally refreshing interface.

Debugging Checks

• Apply PDO updates and background parameter operations simultaneously, and measure worst-case fast-loop completion time and command age.
• Switch control sources and modes, confirming that adopted targets belong to one snapshot and that the old source can no longer write.

Motor, Feedback, and Mechanical Load

Servo response depends jointly on motor electrical parameters, position feedback, mechanical inertia, transmission ratio, friction, and compliance. Controller inputs should include more than rated motor power: pole-pair count, flux linkage or torque constant, winding parameters, feedback resolution, and load direction are also needed. With the same motor connected to different loads, speed- and position-loop tuning and limiting conditions may be entirely different.

Create a motor and load parameter table with units and measurement or manual sources. Convert motor-shaft and load-shaft positions through the transmission ratio; encoder placement changes the error seen by the closed loop. Flexible couplings, gearbox backlash, and mechanical resonance cannot be directly eliminated by raising control gains. First identify feedback mounting position and mechanical constraints, then choose bandwidth and filtering.

Feedback paths should include validity and data-freshness indicators; after failure, do not treat the last angle as the current angle indefinitely. Incremental encoders generally do not supply an absolute electrical zero at power-on; whether alignment, homing, or retained position is needed depends on the actual structure. Systems with a holding brake must also specify brake engagement and release timing, load-support conditions, and coordination with drive torque.

During bring-up, first verify that positive and negative directions, feedback counts, and mechanical movement agree, then close the loops in stages under current and speed limits. When the load changes, record inertia estimates, following error, control output, and limit states to distinguish parameter errors, feedback delay, and mechanical constraints. One successful no-load round trip cannot establish full-load positioning performance or safe-stop capability.

Debugging Checks

• Compare motor-shaft and load-shaft motion, and check transmission ratio, positive direction, pole-pair count, and feedback-count conversion.
• Repeat error and limit-state recording after changing the load or mechanical connection, confirming that tuning conclusions cover the actual operating conditions.

System Constraints and Verification Entry Points

Servo acceptance must turn positioning, speed, torque, temperature-rise, and communication requirements into observable metrics under defined operating conditions. Specify the bus, load, temperature, trajectory, duration, and feedback conditions for every metric; 'high precision' alone cannot define a test. Capability is also constrained by current, available voltage, mechanical speed, and cooling, so the controller cannot be expected to maintain the same dynamic response after saturation.

Arrange verification entry points by dependency: sampling calibration, phase sequence and angle, PWM/ADC timing, current loop, speed loop, position trajectories, and communication control. Save pass criteria and raw records at every step, stopping at the layer closest to the cause on failure. Software unit tests suit unit conversion, limiting, and state logic; actual current waveforms, delays, and mechanical errors require target hardware.

Establish separate observables for limiting conditions, including voltage saturation, current limiting, following error, expired commands, and fault response. When output reaches a limit, logs should show the target actually adopted rather than only the master's reference. This distinguishes insufficient system capability from control errors and reveals whether an integrator is continuing to accumulate, causing an abrupt change when the limit is released.

Regression coverage should include cold and hot conditions, different directions and loads, communication disturbances, and fault recovery, with hardware/firmware versions recorded. Explicitly retain untested scope; do not substitute vendor reference-design results for your own data. After changing sampling rate, feedback filtering, compiler optimization, or the power board, reverify the relevant timing and performance instead of merely checking that the code compiles.

Debugging Checks

• Link every performance requirement to specific operating conditions, records, and judgments, and check for metrics that lack bus or load boundaries.
• Enter and exit voltage/current limiting, observing integrator state, adopted targets, and error recovery to confirm there are no hidden abrupt changes.

Inverter Bridge and Gate Drivers

A three-phase inverter bridge combines upper- and lower-switch states to generate motor-terminal voltages, while gate drivers convert MCU logic signals into gate actions suitable for the power devices. Check PWM active levels, upper/lower bridge-arm relationships, driver modes, and default off states together. Apparently complementary logic waveforms do not prove that the actual gates have no overlap; propagation delay, Miller coupling, and device switching times all affect the result.

Configure dead time, minimum pulse width, and fault inputs according to power-board and driver parameters. Do not assume that built-in interlocking, dead-time, or protection functions are all active based on their names; check the specific modes and registers. Bootstrap-powered high-side drivers also have refresh constraints. High duty cycles or prolonged static conduction may affect gate power and must be included in operating boundaries.

Gate-drive strength involves tradeoffs among switching losses, overshoot, and noise; do not simply maximize turn-on speed. Communication firmware can read back configuration and faults, while the fast protection path must still be designed for actual device tolerances. When replacing MOSFETs, IGBTs, or SiC devices, recheck gate voltage, drive current, turn-off behavior, and sampling noise instead of changing only the current rating.

During integration, first verify default states with controlled power and no run command, then measure the correspondence between logic inputs and actual gate/phase nodes. Abnormal pulses, driver undervoltage, or fault recovery may occur at enable edges; focus on transitions during power-on, stopping, and renewed permission. Reference-design test waveforms establish behavior only for their own components and layout; they cannot directly validate another board.

Debugging Checks

• Compare PWM inputs with actual upper- and lower-switch gate timing, checking dead time, minimum pulse width, default off states, and outputs after faults.
• Read back driver modes and protection configuration. Cover high duty cycles, undervoltage, and enable transitions to confirm that software assumptions agree with hardware.

Current, Voltage, and Temperature Measurement

The current, DC-bus voltage, and temperature used by servo control come from different sampling paths; their bandwidths, units, and valid ranges must not be conflated. Phase currents support closed-loop control and diagnostics, bus voltage determines voltage capability and protection, and temperature reflects slower thermal states. Each sampling path must define the sensor, gain, offset, ADC reference, and conversion relationship, plus how out-of-range or invalid data is flagged.

Measure current offsets in a known zero-current state that meets hardware conditions, rather than forcing the average to zero while the motor runs under load. Calibrate gain using a justified input or reference measurement, recording positive/negative directions and channel differences. Amplifiers with PWM rejection still have settling times and frequency characteristics; verify sampling windows against actual common-mode transitions and front-end response.

Voltage and temperature channels may use slower updates and appropriate filtering, but the protection path requires independent response-time consideration. An open or shorted temperature sensor, or an out-of-range reading, must not simply be clamped to a normal temperature. ADC triggering, DMA buffers, and control adoption need temporal consistency. In particular, nonsimultaneous sampling of two phase currents can introduce errors into reconstruction and transforms.

During debugging, record raw ADC codes, engineering units, calibration values, and validity flags together to distinguish conversion problems from real noise. After changing the bus, duty cycle, and load, observe offsets, waveforms, and saturation, checking whether the sampling front end is overdriven. Do not smooth a display waveform with heavy filtering while introducing phase delay into the current loop without reverifying stability.

Debugging Checks

• Check offset, gain, and signs at known zero current and positive/negative inputs, then observe settling time during PWM switching.
• Disconnect the temperature sensor or drive the ADC to its range boundary, and check that invalid-data flags, fault actions, and filter delays match the definition.

Isolation and Fault Protection

Isolation in power systems separates voltage domains and transfers signals; fault protection detects faults and limits damage. Their respective boundaries must be clear. An isolated driver with a given isolation rating does not establish that the entire board's spacing, supplies, connectors, and system meet the same level. Interpret datasheet parameters in the context of actual routing, working voltage, and system requirements.

List overcurrent, driver undervoltage, overtemperature, and other actual fault sources in the protection path, specifying detection points, threshold justification, shutdown paths, and reset permission. Fast hardware fault signals can directly inhibit PWM or gates, with software subsequently recording and latching the event. A slow current warning in a communication task is not short-circuit protection, and the presence of an isolator does not establish that noise cannot affect fault inputs.

For fault signals crossing isolation domains, check active levels, unpowered defaults, pulse widths, and propagation delays so a broken wire is not interpreted as normal. Configure driver blanking and soft turn-off parameters against device tolerances: excessive blanking may miss dangerous events, while overly fast turn-off may increase overvoltage. Software should preserve the first fault and a contextual snapshot, preventing subsequent power-loss states from overwriting the original cause.

Verify the fault-input path, software latching, logs, and recovery separately, rather than declaring the entire chain passed after calling a simulated-fault function. Actual power-fault tests must be performed under suitable conditions by appropriate personnel according to the design. Low-energy injection can verify logic first, but cannot replace device-withstand and actual shutdown-timing tests. Clearing a record does not mean output recovery is permitted.

Debugging Checks

• Inject logic signals from each actual fault source, measure the time to PWM/driver inhibition, and record latching and the first cause.
• Test loss of power on the isolated side and invalid fault lines, checking default states and recovery permission so failures are not interpreted as normal.

Principles and Boundaries of Safety Functions

Safety functions such as STO concern limiting the energy that can generate torque under specified conditions. This is neither ordinary software stopping nor immediate motor standstill. Inertia may keep motion going, vertical loads may need a mechanical holding brake, and the bus may retain hazardous voltage. Setting a software PWM-inhibit variable alone does not establish that STO has been implemented.

Safety chains typically involve dedicated hardware, redundant or diagnostic architectures, fault analysis, and full lifecycle requirements. TI's STO reference design provides a specific architecture and evaluation scope; using one of its components or copying a piece of logic does not automatically inherit its SIL or PL conclusions. Compliance of an independently developed product requires verification and assessment of the actual system.

Ordinary drive firmware may receive safety status, prohibit new run permission, and provide diagnostics, but should not bypass or automatically reset an independent safety chain. Status reporting must distinguish safety requests, actual hardware states, ordinary drive faults, and mechanical standstill signals. Restored communication or cleared faults are insufficient for restoring safety permission; restart policies must prevent old start commands from generating torque again.

Begin engineering analysis by drawing energy paths and safety interfaces, and listing expected observations for broken wires, power loss, single-point failures, and contradictory feedback. Verifying software interfaces does not replace safety-hardware verification. Every test report should limit its claims to the channels, operating conditions, and fault types actually covered. Simulated STO inputs, an ordinary emergency-stop button, or a single motor stop are not complete evidence of safety compliance.

Debugging Checks

• Record safety requests, hardware permission, and drive operating state separately, and check that stale controlwords cannot automatically restart the drive after permission is withdrawn.
• Review the coverage boundaries of test results, distinguishing reference-design assessment, software-disable testing, and full product certification.

Inner d/q Current Loops

For a PMSM servo using rotor-flux orientation, the inner current loops transform phase currents into a rotating reference frame, regulate d- and q-axis currents separately, then generate voltage commands through inverse transforms and modulation. Coordinate directions, phase sequence, angle offset, and transform normalization must agree. Steady d/q values do not establish correct torque direction; an incorrect angle can make current components look normal while missing the physical target.

The implementation first corrects sampling offsets and scaling, uses a time-aligned electrical angle for the transform, then computes error, PI action, necessary compensation, and voltage limits, and finally generates modulation based on the bus voltage. PI gain definitions must specify the discrete period and whether the integral term already includes the period factor. Coordinate voltage limiting with anti-windup to prevent further integral accumulation when commands exceed bus capability.

Inner-loop bandwidth is constrained by sample-to-output delay, PWM updates, sensor noise, and motor parameters; there is no fixed ratio universal to all servos. Confirm hardware and signs before tuning gains. Outer-loop references need current-magnitude and slew constraints. When d and q change together, consider the current-vector boundary rather than clamping each axis independently to the same maximum and producing excessive resultant current.

Begin debugging with controlled small current commands, observing phase currents, d/q feedback, adopted voltages, and saturation flags. Check responses to positive and negative steps at different electrical angles; success at one fixed angle does not establish consistency over a full revolution. Then estimate bandwidth and stability margins with appropriate methods. Vendor example results are references, not performance already achieved by an independently developed board.

Debugging Checks

• Apply small positive and negative current targets at different electrical angles, checking consistency among phase sequence, transform signs, and feedback response.
• Change the bus voltage or enter and leave voltage limiting, checking anti-windup, integral state, and smooth output recovery.

Torque Commands and Limits

Torque mode converts an external mechanical target into a current target, but the conversion depends on the motor model, flux linkage, pole-pair count, normalization, and current definition. Under specific assumptions, a surface-mounted PMSM allows a simplified relationship between torque and q-axis current; an interior PMSM also involves reluctance torque. A fixed Iq multiplier cannot be generalized to all motors, and peak and RMS currents must not be mixed.

The product parameter table should specify rated torque, torque-constant units, and the current basis; the interface should provide commanded torque, actual adopted current, and the reason for limiting together. Higher-level torque scaling, mechanical transmission direction, and electrical-angle direction must agree. Internal limits must consider the motor, power devices, temperature, and available voltage, rather than allowing output up to the numeric type limit of a communication object.

Dynamic commands need magnitude and slew-rate limits to avoid mechanical shocks from a torque step. Torque mode also requires an explicit strategy at speed boundaries; it does not inherently constrain shaft position as position mode does. Handle integration and target handoff when limits change. Thermal derating or bus changes must not leave outer loops accumulating error against capability that is no longer available.

First verify units and encoding without power applied, then compare commands, dq currents, and load response under controlled conditions. Actual torque measurement requires suitable sensors and operating conditions; a software-converted Iq value alone cannot be claimed as measured output torque. Verify forward/reverse directions, continuous loads, and short-term peaks separately. Record adopted values rather than targets alone so the cause of limiting can be explained.

Debugging Checks

• Check torque constant, pole-pair count, and peak/RMS basis, including the direction and scaling from positive/negative commands to Iq.
• Trigger thermal derating or speed boundaries, observing adopted current, limiting reasons, and recovery; do not substitute software estimates for measured torque.

Feedforward and Decoupling

Feedforward and decoupling in servo current loops reduce the effect of predictable voltage demands on PI error, often involving rotating-frame cross terms and back EMF. They depend on motor parameters, speed, and sign conventions; do not simply copy signs from an online formula into firmware. Establish the coordinate equations being used, then check electrical angular velocity, Ld/Lq, and flux-linkage units in the implementation.

Record PI output, feedforward terms, and final adopted voltage separately, and apply anti-windup feedback after limiting according to the actual control structure. Compensation also consumes voltage headroom; do not limit PI and feedforward independently and then add them beyond the modulation boundary. Define valid compensation ranges and filtering/limits for parameter errors or speed noise, preventing high-gain feedforward from amplifying errors during startup or invalid feedback.

First establish a trustworthy inner loop with compensation disabled, then enable individual terms and compare current errors under disturbances and speed changes. Model compensation may be inaccurate when low-speed angle is unlocked, speed estimates jump, or inductance changes with current; permit gradual engagement or limited use. Some FCL libraries have specific APIs and variable organization. Read the implementation for the relevant version when porting instead of inferring formulas from variable names.

The debugging focus is whether compensation uses data from the same cycle at the correct execution point. Using an old speed sample with new angle and current samples creates additional inconsistency. If enabling compensation causes oscillation, first check units, signs, delay, and saturation instead of continuing to raise PI gains. Verify results in different directions and bus conditions; one smoother high-speed waveform does not establish general effectiveness.

Debugging Checks

• Record PI, feedforward, and post-limit voltage separately, and reverse rotation to check that cross-coupling compensation signs match the coordinate equations.
• Compare errors and saturation during compensation on/off and parameter-mismatch tests, confirming that invalid speed or angle does not amplify output.

Sampling Delay and Ripple

Servo current ripple depends jointly on PWM switching, motor inductance, bus voltage, current-sensing location, and control output, while displayed traces also depend on sampling phase and filtering. A smooth sequence from ADC samples always taken at the same phase does not mean the actual current has no ripple. Distinguish instantaneous switching ripple, control-cycle variation, and sampling noise, choosing appropriate measurement bandwidth and observation points.

Effective closed-loop delay includes analog-front-end settling, ADC conversion, interrupt waiting, computation, PWM shadow loading, and other digital filtering. Shorter computation reduces only part of it. For single-shunt or low-side sampling, also verify that valid windows remain sufficient after duty-cycle changes; when a window becomes invalid, do not force meaningless samples into the dq transform.

Angle-to-current timing also affects high-speed current error. Delay compensation may be considered based on a confirmed model, but actual delay must first be known rather than guessing a constant. Noise-reducing filtering introduces phase lag and requires rechecking the loop. Higher PWM frequency may improve ripple while increasing switching losses and CPU load; choose it against power and real-time constraints rather than pursuing smoother traces alone.

Measure ADC triggers, ISR start/end, actual PWM loading, and phase-current waveforms together, comparing different duty cycles, directions, and bus voltages. Measure worst-case waiting under full communication and background-task load as well. If waveforms change after modifying sampling location, driver switching settings, or the amplifier, recheck sampling scale and windows instead of merely tuning PI to hide hardware sampling defects.

Debugging Checks

• Compare oscilloscope current waveforms with ADC sample phase to distinguish actual ripple, aliasing, and insufficient front-end settling.
• Measure the complete delay from sampling to PWM loading, covering windows at high modulation indices, and check invalid-sample and deadline counters.

Outer Speed Loop

The speed loop generates torque or q-axis current targets from mechanical-speed error, relying on the inner current loop to have trustworthy tracking capability first. Its plant includes mechanical inertia, friction, and load torque, differing from the electrical plant of the current loop. Before tuning, fix speed units, direction, estimation method, and update period. Mechanical rpm, electrical frequency, and increments per cycle must not be interchanged.

Speed feedback often comes from position differences, captured periods, or combined estimation; low-speed quantization and filtering delay affect control. Choose measurement windows according to feedback resolution and speed range instead of adding excessive filtering for smooth traces while ignoring phase. The outer loop may generally execute more slowly than the current loop, but its discrete PI integral gain must use the actual outer-loop period.

Set output limits according to current available from the motor and power stage, and constrain the speed target with a trajectory. During current saturation, the speed PI needs anti-windup or explicit integral handling to prevent a high-speed surge when load is removed. Load changes, mechanical resonance, and feedback noise should not all be treated with higher gains. First observe adopted current, speed error, and limit states to distinguish plant changes from feedback-path problems.

Begin verification with small speed steps and disturbances, recording target, feedback, current target, and actual current, then vary load and direction to check stability. Frequency analysis can help estimate bandwidth and margins, but injection amplitude and operating conditions must suit the system. A vendor's dual-axis reference design demonstrates an analysis method; it does not mean every load can use the same gains or bandwidth ratio.

Debugging Checks

• Check speed-measurement windows and filtering delay, comparing continuity and unit consistency of feedback at low speed, high speed, and reversal.
• Drive current to its limit and then unload, observing the speed integrator state and overshoot to confirm that anti-windup and target ramps are effective.

Position Loop and Cascade Relationships

The position loop converts position error into speed or another intermediate target, then speed and current paths execute it in a cascade with different time scales. Position feedback may come from the motor shaft or the load side, producing different closed-loop plants. Define axis coordinates, zero, transmission ratio, positive direction, and position range first; encoder counts alone are not calibrated mechanical position.

Bring up the current loop first, then the speed loop, and finally connect position targets and trajectories. Position-loop bandwidth is limited by inner-loop capability, feedback delay, and mechanics; do not increase all three loops together. The outermost output also has speed and acceleration boundaries. Constrain targets generated by large position errors or long-distance commands may continuously saturate the inner loops.

Position differences must handle multiturn counts, counter wraparound, shortest-path versus specified-direction movement, and integer width. Direct subtraction at wraparound can produce a huge false error. Homing, mode changes, and feedback resets require realignment of targets and coordinates so a sudden coordinate change does not make the controller produce a surge in response to apparent displacement.

Validate small displacements, long travel, both directions, dwell, and wraparound crossings while observing position error, adopted speed, and current limits. Backlash and elasticity can allow correct motor-shaft positioning with incorrect load positioning, so interpret results according to feedback location. Final in-position values alone establish neither stable trajectories nor positioning accuracy under different loads.

Debugging Checks

• Check position-error calculation and target reconstruction during counter wraparound, homing, and mode changes, ensuring no sudden large setpoints occur.
• Observe motor-shaft and load-shaft feedback separately, checking the effects of cascade bandwidth, speed limiting, and backlash.

Command Trajectories and Feedforward

Position commands need speed, acceleration, and, when necessary, jerk constraints to form executable trajectories. Trapezoidal velocity and S-curve profiles serve different mechanical smoothness requirements, chosen according to load and cycle budget. A position-target step is not realizable instantaneous motion; planner position, velocity, and acceleration outputs must belong to the same instant of one continuous trajectory.

Feedforward uses planned velocity or acceleration to reduce predictable following error but does not replace feedback correction. Units, signs, and injection points must match the cascade: velocity feedforward enters the speed target, while torque feedforward requires a load model and limits. Do not add trajectory derivatives repeatedly in multiple loops or amplify abnormal acceleration calculated after missing target frames.

When communication and local control periods differ, define target holding, interpolation, or replanning and record each target's effective time. Handle current velocity and acceleration when a new endpoint arrives instead of restarting at zero speed. Planning must consider stopping distance and travel limits; total feedforward remains constrained by current and available voltage and must cooperate with anti-windup.

First disable feedforward to verify basic trajectories, then enable velocity and acceleration terms separately and compare error, overshoot, and saturation. Test short moves, reversal, continuous target updates, and cancellation, checking continuity and stopping behavior. Accuracy claims must specify load, speed, and measurement conditions; a software curve matching its target does not prove actual mechanics meet the specification.

Debugging Checks

• Continuously change endpoints, cancel, and reverse; check position/velocity/acceleration continuity at boundaries and stopping distance against constraints.
• Enable feedforward terms separately and compare errors with limited outputs, checking units, signs, and duplicate compensation.

Following Error and Dynamic Response

Following error is deviation between the desired trajectory and actual position, with an explicitly defined reference. The master's final endpoint, interpolated instantaneous target, and drive-local constrained target differ; endpoint minus current position may be remaining travel rather than closed-loop following error. Different target and feedback sampling times also turn timing differences into apparent control error.

Monitoring generally combines magnitude and duration with operating mode and valid-feedback conditions, distinguishing brief normal dynamic error from sustained loss of tracking. Define thresholds in real position units rather than copying another device's encoder counts. The resulting stop, limit, or fault response depends on mechanical and power boundaries; an error-bit name does not establish the actual action.

Observe trajectory, actual position, speed, current, and limit flags together when evaluating dynamics. Error can arise from voltage saturation, insufficient torque, late communication, feedback delay, or mechanical resonance; increasing position gain alone does not address every cause. Record steady-state error, peak error, recovery time, and direction-dependent behavior, preserving sampling periods and alignment methods.

Cover acceleration/deceleration, load changes, continuous target updates, and fault recovery, recording conditions rather than only the most attractive trace. Host tests can verify monitoring calculations and time windows, but stopping distance, feedback chains, and mechanical position require hardware validation. Beckhoff monitoring parameters are implementation references rather than thresholds and actions every custom drive must copy.

Debugging Checks

• Compare interpolated targets and feedback on one timebase, confirming that monitoring measures following error rather than remaining travel.
• Vary loads and limits, record peaks, durations, and fault actions, and check consistency of threshold units and stopping policy.

Encoders, Hall Sensors, and Position Feedback

Feedback devices differ in resolution, absolute information, latency, and failure reporting. Incremental encoders count phase changes, absolute encoders return positions in specified formats, and Hall sensors generally identify coarse rotor regions. Choose according to startup, low-speed torque, positioning, and environmental needs; decodable signals do not automatically satisfy every servo-feedback requirement.

For incremental links, check A/B phase relationship, count multiplier, Z-pulse handling, count range, and input filtering; for absolute links, check clock, frame length, checksums, status bits, and transmission delay. Cables, supply, interface levels, and differential receivers also belong to the feedback chain; changing a software sign cannot conceal disconnection or electrical mismatch. Hall combinations additionally need valid-sequence and abnormal-state detection.

Feedback data should carry validity and time or sequence information corresponding to its use by control. Filtering, serial reads, and retries delay position and particularly affect electrical angle at high speed. Distinguish temporary checksum failure, consecutive missing samples, count abnormalities, and sensor resets; the last position cannot remain 'currently valid' indefinitely.

Begin integration without torque output, manually rotating or using controlled inputs to check direction, counts per revolution, and zero before powered motor operation. Record raw feedback, decoded position, speed, and validity to distinguish protocol parsing, unit conversion, and mechanical problems. The referenced eQEP manual applies to its listed chips; other MCUs require separate checks of input filtering and latch rules.

Debugging Checks

• Rotate one full revolution manually and reverse, checking count multiplier, direction, index pulse, and resolution as defined in feedback documentation.
• Inject disconnection, bad checksums, and consecutive sample loss, checking validity, last-sample age, and drive fault handling.

Angle Alignment and Decoding

FOC electrical angle references the rotor-flux relationship to phase windings; encoder mechanical zero or its Z pulse is not inherently that reference. Define phase sequence, the viewpoint for positive rotation, encoder direction, and Park convention before determining electrical offset. Continuous mechanical-angle readings do not mean commutation alignment is complete; incorrect alignment makes current direction inconsistent with torque.

The decoding path must explicitly handle counter wraparound, absolute-frame checksums, status, and multiturn information, returning common mechanical position and validity. Design alignment for the motor, feedback type, and mechanical constraints, and record conditions and results. Determine beforehand whether loaded or braked axes can perform alignment that produces motion/torque; do not run it unconditionally at every power-up.

Zero offsets depend on motor wiring, encoder installation, and direction; associate stored values with hardware/configuration identity and verify their applicability after upgrades. Commutation signs are not merely a combination that makes the motor turn: an incorrect relationship may seem normal at low speed without load yet produce large d-axis current or wrong torque. PI gains must not compensate for an unverified angle reference.

Check angle continuity and dq feedback across a full revolution or several electrical cycles, then verify positive/negative torque with controlled current. Save phase currents, raw mechanical position, converted electrical angle, and alignment offset together to distinguish phase-sequence, pole-pair, and offset errors. Recheck after wiring, sensor, or mounting changes instead of retaining old calibration.

Debugging Checks

• Check electrical-angle repetitions and continuity over one full mechanical revolution, confirming agreement among phase sequence, direction, and pole pairs.
• After wiring or encoder-mounting changes, check offset applicability and record dq currents and torque direction; do not directly reuse old calibration.

Mechanical/Electrical Quantity Conversion

Mechanical position describes shaft motion; electrical angle describes the rotor-field cycle relative to the stator. Pole pairs and offset connect them: typically electrical angle equals pole pairs times mechanical angle plus alignment offset, normalized to one electrical cycle, with direction signs included in the defined convention. Mechanical rotational speed and electrical frequency are not directly interchangeable either.

Fix interface units: angle in radians, degrees, or turns; speed in rpm, radians per second, or counts per cycle. Distinguish encoder lines, edge-count multipliers, and absolute bit resolution, and state whether feedback is on the motor or load shaft when defining transmission ratio. Use sufficiently wide intermediate integers to avoid overflow when multiplying by pole pairs or scaling factors.

Speed estimation from position differences must handle wraparound and actual time intervals rather than assuming every read is exactly one fixed period apart. Low speed suffers quantization; high speed requires consideration of feedback latency and electrical-angle extrapolation. State the valid range of the chosen method. Filtered speed and instantaneous position have different temporal characteristics and must not be treated as simultaneous raw quantities.

Create software vectors from known counts per revolution, pole pairs, and direction, then compare with actual manual shaft rotation. Verify separately the electrical cycles per motor revolution and motor revolutions per load revolution. Passing formula checks does not prove correct installation and wiring; connect physical direction and actual feedback to the same convention table.

Illustration: θe = wrap(p × θm + θoffset); p is the pole-pair count, and signs and wrap interval depend on the coordinate convention.

Debugging Checks

• Validate conversion with forward/reverse, wraparound, and pole-pair boundary vectors, checking for integer-intermediate overflow and mixed units.
• Rotate the actual shaft and compare mechanical revolutions, electrical-angle cycles, and load transmission ratio, confirming physical direction matches software conventions.

Conditions for Sensorless Estimation

Sensorless algorithms estimate angle and speed from voltage, current, and motor models; whether they replace sensors depends on observation principles, operating region, and application needs. Back-EMF methods lack information at low or zero speed and cannot directly promise stationary positioning or full-load starting. Compare servo holding, low-speed positioning, and fast reversal requirements with the specific method's observable range.

Estimator inputs must reflect actual applied voltage and valid current rather than ideal unlimited controller commands. Dead time, bus variation, sampling offset, and PWM-update latency create model error. Parameters vary with temperature and operating conditions, so define their source, units, and scope; one observer gain cannot suit every motor with filtering used to conceal mismatches.

Design startup and mode handover separately, including angle establishment, open-loop or other initialization, estimation-validity checks, gradual closed-loop entry, and loss-of-lock recovery. Keep direction and offset consistent when switching estimated and sensor angles to avoid sudden dq changes. PLL filter bandwidth trades off against dynamics; validate using residuals, signal conditions, and operating regions rather than merely observing changing estimates.

Begin validation against trustworthy feedback, recording estimation error, speed, and load before exploring startup, low speed, reversal, and bus disturbances. Smooth estimation at one speed does not generalize across the range. Microchip AN1292 demonstrates a particular PMSM PLL and field-weakening scheme whose motor and hardware conditions require revalidation; it does not guarantee every precision-servo positioning function.

Debugging Checks

• Compare estimated angle with sensored operation, recording error and validity at low speed, during reversal, and with load changes.
• Test startup handover and loss of lock, observing angle continuity, dq currents, and recovery policy, and identify unsupported operating regions.

Position/Speed/Torque Modes

Position mode follows trajectories, speed mode controls rotational speed, and torque mode controls torque or corresponding current, with different boundaries and user responsibilities. Torque mode does not inherently limit axis position, nor does speed mode guarantee that a load reaches a specified position. Products must define active loops, target units, constraints, and valid feedback per mode rather than merely changing a mode number.

Provide separate target decoding and adoption rules per mode while sharing underlying current control and protection. Position mode plans or interpolates, speed mode constrains acceleration/deceleration and current, and torque mode handles amplitude, slew rate, and speed boundaries. Expose control source, input-validity time, and adopted values after limiting so the host can understand why targets were not executed directly.

Before changing modes, define whether stopping is mandatory or controlled online transfer is supported, and handle integrators, trajectory buffers, and old targets. Do not write new targets into old-mode fields before confirming actual mode. Position coordinates, homing state, and torque references may also change; design initialization and invalidation conditions rather than clearing every variable as a universal solution.

Verify individual modes under unpowered or controlled conditions first, then test transitions with nonzero old targets, paused commands, and cancellation. Record targets, actual mode, adopted loop values, and output permission to detect jumps. Published drive models suggest interface structures, but document device-supported modes and optional objects rather than claiming every CiA 402 mode is implemented.

Debugging Checks

• Switch modes from nonzero targets, checking old-trajectory and integrator handling and ensuring new targets activate only after mode confirmation.
• Reach position, speed, and torque limits separately and verify that returned adopted values and status explain application behavior.

CiA 402 Objects and Enabling

In a CiA 402 servo interface, objects expose drive behavior to communication and must connect to real states, modes, and feedback. The controlword requests actions, the statusword reports results, and requested/displayed modes indicate desired/actual modes. Creating indices and echoing written values does not prove the motor is ready to operate or that targets entered the control loop.

The drive state machine must check bus voltage, feedback, parameters, and faults before permitting output, mapping rejection conditions to understandable diagnostics. NMT Operational and EtherCAT OP are communication states, not substitutes for drive Operation enabled. Initialize in a valid inhibited state; even valid controlwords must satisfy application conditions, and a network-connection callback must not automatically turn on power output.

Pass controlword, mode, and target to the application in one cycle snapshot, treating edge actions and persistent commands separately. Fault reset must confirm the real fault is gone and recovery is permitted; a master holding reset high must not clear diagnostics every cycle. Quick stop and disable-operation output behavior depend on supported options and mechanics and require documentation rather than just a status code.

Begin integration by reading identity and confirming object attributes, then advance state transitions while recording controlword, statusword, mode display, PWM permission, and adopted target. Test enable requests without valid feedback or bus conditions, requests during faults, and old targets after reset. Example SDKs demonstrate interface connection; actual protection and timing require independent validation.

Debugging Checks

• Keep communication healthy while blocking feedback or bus permission and verify that controlword requests cannot create a false operating state.
• Send fault reset as both a sustained level and an edge, observing real faults, state transitions, and new-enable requirements.

Parameters, Units, and Command Updates

Servo interfaces need independently verifiable units for position, speed, current/torque, and time. Host engineering units, on-wire integer scaling, and internal normalized values are different layers; centralize conversions at controlled boundaries. Mixing peak/RMS, motor/load shaft, or mechanical/electrical speed can yield plausible numbers but incorrect motion.

Parameter tables should declare width, signedness, scale, defaults, legal range, activation conditions, and saving policy. Command updates also need effective time, sequence or cycle, and communication-loss rules; a target written long ago cannot remain the newest command forever. Reject out-of-range configuration; if continuous motion targets are clipped, follow documented limits and return adopted values and reasons.

Commit parameter combinations and large multiregister values completely so control interrupts cannot see half-new/half-old data. Use wide intermediates for conversions and handle integer overflow, position wraparound, and invalid floating-point values. Revalidate unconsumed targets when modes or feedback zeros change, preventing formerly legal values from becoming dangerous under new coordinates or scaling.

Verify encoding with distinctive bit patterns, then physical scale with controlled positive/negative motion. Log raw wire values, decoded values, limited/adopted values, and actual feedback to distinguish protocol word order from mechanical error. Recheck compatibility after scaling, pole-pair, transmission-ratio, or firmware-object-version changes; identical displays do not establish continued compatibility with old control software.

Debugging Checks

• Validate interfaces with positive/negative, boundary, and cross-word bit patterns, then compare the scale from wire values to mechanical motion.
• When changing parameter scaling or mode, check pending targets, versions, and control snapshots, ensuring old targets cannot execute directly in new units.

Communication/Control Boundary Integration

Servo integration must observe the complete command path from wire to mechanical output: protocol validation, control-ownership arbitration, state permission, target snapshot, control computation, and PWM activation. Packet capture proves only messages, while changing software variables proves only one stage. Record sequence numbers, times, and rejection reasons at each stage to locate a target-without-motion issue at the protocol or application boundary.

Communication and local current periods usually differ; define target holding, interpolation, adoption points, and expiration windows. Bursts from the master must not turn periodic control into message-triggered execution. Receive buffers should retain only permitted transactions with explicit expiration rules. When multiple interfaces connect, changing control source requires fresh commands and clear permission.

Start integration with one mode and one control source, confirm states and units, then add communication stress, mode changes, parameter access, and fault reporting. Compare desired targets, actual adopted targets, and feedback separately, observing current/voltage limits. Protocol retries must not repeat actions, and network recovery must not automatically replay old trajectories or clear internal drive faults.

The validation matrix should include stopped master updates, network exit from operation, delays and missed cycles, device reset, and recovery. Record communication state, drive state, command age, and output behavior, distinguishing synchronization, liveness, and execution deadlines. Host simulation verifies arbitration and conversions, but mechanical stopping distance and real sampling delay still require target hardware rather than virtual feedback.

Debugging Checks

• Trace reception, publication, adoption, and PWM activation using the same command sequence number to locate missing or late stages.
• Stop master updates and resume, checking application communication-loss action and control-source permission and ensuring old trajectories are not replayed automatically.

Electrical, Angular, and Mechanical Directions

First establish three corresponding direction definitions: power-terminal A/B/C phase sequence and positive current, feedback count/angle direction, and mechanical positive rotation from a specified viewpoint. Inconsistency may prevent stable commutation or allow apparent rotation with abnormal current under some conditions. 'Tuned until it turns' is not acceptance, and higher gains must not conceal sign errors.

Under unpowered or controlled conditions, verify raw feedback counts per revolution, wraparound, and direction, then compare phase-current channels with PWM outputs. Centralize electrical offset, pole pairs, and transform normalization in a convention table used by all algorithms and communication objects. Revalidate alignment parameters after rewiring, encoder changes, or mounting changes rather than assuming stored values remain correct forever.

With limited current and speed, check positive/negative targets, dq feedback, and mechanical direction, and compare angle-offset effects with the model. Transmission ratio, load-side feedback, and backlash also affect final axis direction and position; motor-shaft checks alone are insufficient. Plan alignment for braked or constrained loads according to the system; movement-producing tests are not side-effect-free software checks.

Save wiring version, feedback configuration, offset source, and validation waveforms, linking raw counts, mechanical angle, electrical angle, and dq currents to one timebase. When regressions occur, compare these facts before gains. Example pole pairs, channel order, and sensor models are test conditions; after porting, rebuild evidence using the actual motor and power board.

Debugging Checks

• Compare physical direction, feedback counts, and dq currents for positive/negative targets, ensuring the convention table explains every result.
• Repeat full-revolution checks after wiring or feedback changes, ensuring old offsets and pole-pair settings are not reused without verification.

Multiloop Tuning and Trajectory Validation

Tune servo cascades from the inside outward: sampling and current loop first, then speed and position, limiting each layer's output and checking units/direction. Outer loops cannot repair an unstable inner loop, and overly fast outer loops impose untrackable targets on inner loops and mechanics. Determine bandwidth relationships from delay, load, and resonance rather than copying fixed gains.

Create repeatable trajectories and load conditions and record each loop's target, feedback, error, and limit state. Current steps, speed changes, and position moves excite different plants; one position trace is not evidence for every loop. Frequency analysis helps identify bandwidth and margin, but injection point, amplitude, operating point, and nonlinear limits affect results and require explicit scope.

Change only a limited set of parameters at a time and preserve before/after waveforms and parameter sets. For oscillation, check saturation, feedback delay, angle/scaling, and mechanics before blaming gains. Add feedforward and filters separately after basic loops are trustworthy so improvements remain explainable; sustained limiting also requires integrator and release-recovery verification.

Trajectory validation should cover short/long moves, reversal, dwell, continuous updates, and cancellation, checking consistent velocity/acceleration limits, stopping distance, and error monitoring. No-load tuning does not establish full-load behavior, and one-way success does not cover reversal backlash. After changes to power boards, feedback filtering, PWM period, or load, recheck affected loops and timing rather than presenting reference-design results as your own measurements.

Debugging Checks

• Preserve before/after records under the same conditions in current/speed/position order, checking each layer's limits and frequency-analysis injection conditions.
• Replay reversal, cancellation, and limit-reaching trajectories, checking error recovery, integrator states, and mechanical response against specified boundaries.

Communication Interruptions and Fault Recovery

Servo recovery must distinguish communication loss, drive faults, feedback loss, and supply problems. Network recovery establishes only a usable link; it does not clear other faults or validate old targets. Maintain separate communication state, drive state, command freshness, active faults, and operating permission so the host can identify the condition blocking recovery.

Communication-loss actions depend on product requirements and mechanics and may include hold, limited deceleration, or output disable; validate actual energy and axis behavior for each policy. Control uses the last complete snapshot until its defined expiry rather than refreshing liveness on arbitrary bytes. Entry to communication-loss or fault states must explicitly invalidate expired targets and unfinished trajectories so queued old start requests cannot execute after recovery.

Recovery first confirms that real faults are gone, feedback and parameters are valid, and communication configuration matches, then reestablishes permission through the required new controlword or local action. Clearing historical logs, clearing active faults, and resetting the protocol stack have separate meanings. Default outputs and brake coordination during disconnect, reconnect, or reset must suit the system rather than relying solely on the host to resend a stop packet.

Separately interrupt heartbeat/PDO, leave EtherCAT OP, reset the communication stack, and create local faults, recording trigger times and why recovery is allowed. Cover healthy networking with stalled control setpoints too. Logic can be host-simulated, but real stopping times and mechanical loads need target evidence; one successful automatic reconnection does not establish safe recovery as a whole.

Debugging Checks

• Freeze valid setpoints, disconnect the network, and inject local faults separately, checking that trigger reasons, output actions, and records remain distinguishable.
• After recovery, retain the old start value without issuing new permission and confirm the drive neither replays trajectories nor directly reenables.

Following Error, Logs, and Regression

Useful diagnostics connect symptoms with control-chain state rather than storing only a 'position error too large' code. On following faults, save trajectory target, actual position, speed, current target/feedback, limits, mode, command sequence, and relevant times. Include sampling periods and units, or logs from different versions cannot be compared directly.

Use bounded events or ring records, prioritizing the window around the first fault and marking lost-record and overwrite rules. Synchronous printing in control interrupts changes timing and may create or hide issues, so separate acquisition from export. Bus or feedback decline after a fault may be a consequence; later events must not overwrite the original limiting condition or late target that caused following error.

Compare regressions using fixed trajectories, load ranges, configuration, and firmware versions, reproducing first and then making minimal changes. Describe 'no recurrence' through trial counts, covered conditions, and unverified ranges; one normal motion does not prove root-cause removal. Host tests suit coordinate conversion and state logic, while mechanics, PWM delay, and feedback noise still require target hardware.

After repair or upgrade, rerun checks related to the change: angle/units after feedback changes, worst-case deadlines after scheduling changes, and cancellation/reversal after trajectory changes. Logs, raw traces, parameter sets, and versions together form reviewable records.

Debugging Checks

• When following error triggers, check before/after windows, first fault, limit flags, and command age, ensuring logs explain causal order.
• Retest before and after changes with fixed configuration and trajectories, preserving trial counts, raw measurements, and hardware evidence.

Rectification, DC Bus, and Inverter Bridge

A typical voltage-source variable-frequency drive rectifies AC input into a DC bus, then uses a three-phase inverter bridge to produce motor voltage. Rectifiers may be diode bridges, controlled rectifiers, or active front ends, determining input-current shape and whether energy can return to the grid. DC-fed equipment may omit input rectification, so draw the actual topology rather than describing every drive with the same power chain.

Bus capacitors smooth rectified ripple and temporarily store operating energy. Manage charging inrush at power-up; common precharge resistors and bypass contactors need states, feedback, and timeouts, while active precharge has its own control and faults. Reaching a bus voltage does not prove successful bypass; inspect contactor feedback or related diagnostics. Capacitors may retain energy after disconnection, so discharge paths and voltage confirmation require separate design.

PWM converts bus voltage into average phase voltage through the inverter bridge, with frequency, amplitude, and phase set by the operating algorithm. An ordinary diode rectifier generally cannot actively return braking energy to the grid; deceleration must account for bus, braking-unit, and load capabilities. Maintenance records should define actual boundaries of rectification, precharge, inversion, braking, and discharge; an MCU enable flag alone does not prove every energy path has the intended state.

Debugging Checks

• Check rectifier topology and braking/regeneration paths, listing preconditions and feedback sources for precharge, bypass, discharge, and inverter operation.
• Check bus behavior during charging, bypass failure, and power-off, assessing residual capacitor energy separately from software operating state.

Control Board, Sampling, and Protection

The control board handles setpoints, operating states, modulation, and measurement, but signals have different real-time needs. Phase currents serve fast control, bus voltage determines voltage capability and abnormalities, temperature informs thermal state and derating, and communication supplies slower commands and diagnostics. Placing all signals in one low-rate polling task can leave current data stale or hide bus faults behind prolonged averaging.

Sampling chains include shunts or other sensors, analog conditioning, isolation, ADCs, and scaling; protection may separately use comparators or driver desaturation detection. State the bandwidth, validity, and action path of control currents and fast protection signals. Software current limiting improves operating constraints, while fast hardware shutdown must perform its designed short-circuit/device-protection role. Normal execution of a control interrupt does not prove timely power-fault interruption.

Interface design must account for control-board reset, supply sequencing, default PWM levels, and fault polarity. Drivers need an explicit disabled state before MCU startup; loss of supply on the isolated sampling side must not make abnormal output appear to be real zero current. Preserve original diagnostic causes from drivers, ADCs, and operating algorithms. Reference designs offer architecture ideas, but protection thresholds, delays, and coverage require verification for the actual devices and product configuration.

Debugging Checks

• Draw separate control-sampling and hardware-protection paths, checking bandwidth, fault polarity, PWM during MCU reset, and default driver state.
• Inject sampling-side power loss, control-board restart, and protection inputs, checking validity bits, actual gate outputs, and recorded fault causes separately.

Motor, Load, and Supervisory Control

Variable-frequency-drive goals must match motor and load. Fans and pumps emphasize continuous speed adjustment, efficiency, and process control; conveyors or winders may require coordinated torque and acceleration/deceleration. These do not automatically imply servo positioning. Sharing a three-phase power bridge or FOC algorithm does not establish absolute positioning, multiaxis synchronization, or high-precision holding; state actual capability in interfaces and specifications.

Motor nameplates specify rated voltage, frequency, current, speed, and connection, which must be checked with wiring and parameter choices. Induction-motor speed differs from supply frequency through slip and changes with load; permanent-magnet angle and control strategies differ again. Host frequency, speed, torque, or process setpoints need a defined conversion chain and active channel; one unitless percentage cannot mean the same command in every mode.

Loads also determine startup and stopping. High inertia creates substantial braking energy, constant-torque loads may require sustained low-speed torque, and fans may already be windmilling before power-up. Collect load curves, inertia, rotation direction, permitted stopping methods, and motor cooling conditions. Supervisory control sets process targets, while local drives enforce constraints and validity; document this boundary so a host run command is not unconditional output permission.

Debugging Checks

• Check nameplate, star/delta wiring, and motor type, and define supervisory setpoints, conversion units, operating mode, and local enable conditions.
• Check startup with residual rotation, sustained low-speed load, and deceleration energy by load type, documenting unsupported positioning or synchronization functions.

Product Specifications and Operating Conditions

Product specifications need rated operating points and permitted ranges. Input supply, output current, output frequency, overload duration, ambient temperature, and cooling are interrelated; a short-term peak is not long-term continuous capability. State whether control accuracy means output-frequency or mechanical-speed accuracy: precise electrical frequency under open-loop V/f does not imply equally precise mechanical speed as load changes.

Validation conditions should cover motor/load types, both directions, bus variation, acceleration/deceleration, and thermal states. Continuous low-speed running may reduce shaft-fan cooling, while higher switching frequency may increase power-stage loss, requiring design-based derating. Load inertia and braking repetition change braking-unit thermal load; one successful stop does not prove continuous-cycle capability.

Separate functional, dynamic, protection, and diagnostic requirements, defining methods, time windows, errors, and evidence sources. Rotation proves only a basic chain, not supply-disturbance, communication-timeout, or abnormal-recovery performance. Reference-design power and temperature ranges belong to its board and must not become current-product claims. Regulatory, functional-safety-level, and certification statements must come from existing product records; routine firmware tests and component certification do not establish whole-product compliance.

Debugging Checks

• Distinguish rated, peak, and continuous capability, attaching supply, load, temperature, cooling, and test-duration conditions to each specification.
• Accept frequency output, mechanical speed, thermal state, and recovery separately, preserving untested conditions without copying reference-board ratings or inferring certification.

DC-Bus Voltage and Energy Paths

Bus voltage is an important energy-state observation, but interpret changes with input and load. Inadequate rectifier capacity, input sag, or heavy acceleration can lower it; regenerative braking can raise it; rectification ripple is a normal topology characteristic. For approximately constant capacitance C, stored energy is E=½CV², with C in farads, V in volts, and E in joules. This estimates capacitor energy rather than replacing ripple-current, loss, and lifetime analysis.

During braking, trace mechanical kinetic energy through the bus to the braking unit. With a nonregenerative front end, capacitors generally store it temporarily before a chopper and resistor dissipate it. Deceleration is jointly constrained by the resistor, switches, temperature rise, and control limits. Longer deceleration reduces instantaneous power but cannot guarantee controlled stopping for every load or power-loss case; gravity or externally driven loads may continuously supply energy.

Precharge completion, normal supply, braking, and discharge need different states and diagnostics. Software may monitor bus rise rate, bypass feedback, and post-braking trends, using design-specific criteria. Invalid bus measurements must not permit increased modulation or braking based on erroneous voltage. Save bus voltage, input state, operating stage, and braking duty to distinguish supply faults, excessive regeneration, and measurement errors rather than attributing every overvoltage to short deceleration time.

Debugging Checks

• Estimate energy in one deceleration and permitted capacitor-voltage change, checking front-end regeneration and braking-resistor pulse/continuous thermal capability.
• Cross-check precharge, bypass, braking, and discharge states, and inject invalid bus measurements to verify control does not use an incorrect available voltage.

Three-Phase Inverter Bridge

A three-phase two-level inverter comprises three half bridges whose midpoints connect to the motor. Average line-to-line voltage depends on duty-cycle differences and bus voltage. Motor neutral normally floats, so leg-to-bus and phase-to-neutral voltages differ. State measurement reference, peak, and RMS definitions rather than treating oscilloscope switching-pulse peaks as motor fundamental RMS voltage.

Upper and lower switches must not conduct simultaneously; complementary PWM and dead time must account for driver propagation, device turn-off, and asymmetric delay. Dead time changes output, while minimum pulse width and bootstrap supply restrict duty cycles. Higher modulation may shrink current-sampling windows, so mathematical voltage limits alone do not define feasibility. Overmodulation and discontinuous modulation require separate validation; do not silently change algorithms while retaining old sampling settings.

First check counting, phase sequence, polarity, and inhibit logic without power output, then validate actual gates and legs incrementally under prescribed conditions. For reversed motors, imbalance, or current spikes, compare PWM requests and hardware waveforms together; correct registers do not prove correct gate waveforms. Explain leg states and freewheeling paths after output stops too: all PWM low does not instantly remove motor current or bus energy.

Debugging Checks

• Check leg polarity, complementary relationships, dead time, and shadow loading, including bootstrap and minimum-pulse limits at extreme duty cycles.
• Compare final duty cycles, gates, and average line-to-line voltage, observing freewheeling and bus changes after disable rather than only software PWM flags.

Power Devices and Gate Drivers

Power-device selection must consider conduction, switching, voltage withstand, thermal behavior, and fault tolerance together. IGBTs, silicon MOSFETs, and silicon-carbide devices differ in gate voltage, turn-off method, and parasitic sensitivity and cannot be exchanged by current rating alone. Gate resistance, loop inductance, and layout determine slew rates and ringing. Faster switching may reduce some losses while increasing common-mode interference and overvoltage, so validate actual waveforms.

Gate drivers provide current amplification, isolation, and some protection. Undervoltage lockout, Miller clamps, desaturation detection, and soft shutdown each have trigger conditions and timing that require configuration from the selected datasheet. Excessive desaturation blanking/filtering delays real faults, while too little causes false trips. Soft shutdown changes current fall and voltage overshoot but does not automatically eliminate every short-circuit energy risk.

Firmware must understand driver ready, fault, reset, and enable interfaces rather than treating drivers as PWM conduits. Inhibit output before driver supplies stabilize, latch driver-fault causes, and check all leg states. Before resetting a driver fault, determine whether its cause is gone and whether restarting needs precharge or motor checks. Calibrate protection currents, gate voltages, and blanking times for actual devices and power boards.

Debugging Checks

• Check power-device and driver recommended conditions, fault paths, and reset requirements individually, retaining evidence of gate ringing and turn-off behavior.
• Cover driver undervoltage, desaturation, and disable inputs, measuring actual shutdown and fault-report times and assessing overshoot/false-trip tradeoffs.

Isolation and Signal Interfaces

Define isolation boundaries between accessible interfaces and power-reference ground. Communication, encoders, sampling, gate drivers, and auxiliary supplies may use different isolation methods; a high component withstand rating does not establish whole-board isolation. Working voltage, transients, creepage, clearance, pollution degree, and altitude jointly affect design and require review against applicable standards and product conditions.

Signal isolation also affects delay, defaults, and power-loss behavior. Check PWM propagation differences and output behavior under common-mode transients, analog-isolation linear range/gain/fault indication, and digital-communication direction and bus reference. Power isolation must match signal boundaries; a debug cable bridging the two sides may defeat intended isolation. Include measurement and debug connections in interface diagrams.

Ordinary electrical isolation and safe torque off are different functions. PWM inhibition is an operating-control action, but cannot be called STO without the corresponding architecture, diagnostics, and validation; isolator certification does not establish whole-system safety level. Firmware documents should accurately describe observable/controllable interfaces and defer isolation and functional-safety conclusions to formal design evidence. Preserve fault-default states during debugging rather than forcing abnormal indications to normal for communication convenience.

Debugging Checks

• Draw isolation boundaries for every signal, power, and debug connection, checking working conditions, layout distances, and default states after power loss.
• Verify output behavior under common-mode disturbances and interface-side power loss, distinguishing ordinary disabling, isolation performance, and safety functions supported by existing formal evidence.

PWM and ADC Synchronization

Synchronizing PWM and ADC in a variable-frequency drive aims to obtain interpretable current and voltage samples, not merely to give them the same frequency. Sample-and-hold must fall within a window allowed by the topology, avoiding switching transients and allowing sufficient amplifier settling. Center alignment, sectors, and duty cycles all change measurable intervals; sampling triggers must follow modulation or use a validated fixed region.

ADC conversion completion, DMA transfer, and control computation follow sampling, and new duty cycles still await a loading event. If bus-voltage sampling is asynchronous to current, define its age in voltage reconstruction. Multichannel scanning can introduce time differences between phase samples, affecting coordinate transforms at high speed or during fast current changes. Even simultaneous-sampling hardware requires verification of triggers and result association, not just configuration-option names.

Verify triggers, sampling, reads, and output activation on the actual counter timeline, covering low modulation, sector boundaries, and near-maximum duty cycles. Control interrupts need adequate margin before the next load; communication and diagnostic stress may delay only a few cycles. Insufficient sampling windows or incomplete conversions must produce validity flags and defined handling. Do not treat old ADC data as fresh current, amplifying errors in current limiting or observers.

Debugging Checks

• Sweep duty cycles and sectors. Measure window width, analog settling, sample-and-hold, and loading margin, checking that the shortest window meets configuration requirements.
• Correlate ADC and PWM by cycle number. Add communication stress and incomplete conversions, verifying stale-sample identification and specified timeout actions.

Phase Current and DC-Bus Current

Phase current and DC-bus current are different physical quantities. Phase-line sensors directly observe winding currents; low-side shunts measure during particular conduction states; a single bus shunt indirectly extracts phase information from switching states. Average bus current indicates power or input loading. It cannot replace instantaneous phase currents, and the ordinary arithmetic average of three phase currents cannot estimate DC input current.

Single-shunt reconstruction needs enough independent samples during active vectors, with signs mapped by sector and switching state. Short active vectors create unmeasurable regions. Pulse shifting or substitute samples change voltage and data age. Reconstructing the third phase from two requires an approximately zero three-phase sum, which may fail during ground faults or common-mode leakage. A reconstructed zero sum is not independent proof of hardware health.

Distinguish current use for control, protection, and power analysis. Control needs time-defined samples; fast overcurrent needs a shorter path; input-power estimation needs suitable averaging synchronized with bus voltage. Revalidate sampling triggers, amplifier ranges, protection coverage, and voltage observation after topology changes. Log raw samples, switching states, validity flags, and reconstruction together so filtered currents do not hide short windows or channel saturation.

Debugging Checks

• Label sensor locations and purposes separately. Check single-shunt mapping and unmeasurable-region handling; reconstruction identities do not prove healthy sensors.
• Use extreme modulation, saturation, and simulated ground faults to check control/protection coverage, comparing sample age, final reconstructed currents, and raw waveforms.

DC-Bus Voltage and Temperature Sampling

Bus voltage and temperature generally change more slowly than phase current, but sampling must still suit their purposes. Bus voltage supports modulation normalization and over/undervoltage decisions and may change rapidly during precharge or braking. Temperature supports derating and protection; measurement location, thermal inertia, and channel faults matter. Long averaging with only smooth values can misrepresent available voltage or slow protection.

High-impedance bus dividers require consideration of input impedance, isolation-amplifier range, and ADC sample-and-hold settling. Divider resistance and voltage-rating distribution are hardware design matters; software conversion must match actual resistors and gains. Temperature may come from module NTCs, heatsinks, or other sensors; location readings are not instantaneous junction temperature. Handle NTC nonlinearity, open/short circuits, and reference drift separately rather than treating every full-scale anomaly as hot or cold.

Data interfaces should expose raw values, engineering values, validity, and sample times, separately documenting filters for control estimates, display, and protection. Isolation-side power loss may produce a device-defined fault output; check validity before normalization. Validate multiple range points and transitions with controlled inputs, including lost updates. Product-specific requirements define thermal and bus thresholds; example-device values are not universal settings.

Debugging Checks

• Use known inputs to check bus scaling and NTC conversion across low, middle, and high ranges, open/short circuits, and isolation-side power loss, verifying validity-first handling.
• Measure control, display, and protection filter delays separately. Verify voltage-data age during precharge/braking and the policy for lost temperature updates.

Calibration, Filtering, and Measurement Error

Calibration distinguishes offset, gain, linearity, and dynamic errors. Internal ADC calibration may improve the converter but does not automatically remove shunt, amplifier, divider, or sensor errors. Acquire current offsets only at genuinely zero current; residual motor rotation or freewheeling current invalidates simple averaging as offset. Gain calibration needs a trustworthy reference and range coverage. Single-point zeroing does not establish full-range accuracy.

Filtering reduces random noise but cannot repair wrong scaling, saturation, or inadequate sampling windows. Match acquisition time to source impedance and ADC input characteristics; channel switching may need additional settling. Software averages spanning state changes mix precharge, operation, and braking meanings. Bind digital filter coefficients to task periods and include delay in current-limit and observer models.

Calibration parameters need versions, temperature, date, hardware association, and integrity checks. Replacing sampling boards, ADC references, or amplifier gains must invalidate old parameters or require explicit revalidation. Acceptance can cover static known inputs, PWM common-mode interference, and actual operation, recording raw/processed data and checking range clipping and low-amplitude offsets. Smooth filtered current alone does not prove correctness; connect error budgets and diagnostic evidence to control use.

Debugging Checks

• Check offset, gain, and linearity at genuine zero current and multiple known inputs, confirming calibration association with the correct board and reference voltage.
• Vary PWM common-mode disturbances and ADC acquisition time to check dynamic errors. Compare raw and filtered values and delay without letting filters hide invalid sampling windows.

Operating States and Start/Stop

A variable-frequency drive's start request must pass through the operating state machine before becoming a frequency or torque reference. Standby, precharge, ready, starting, running, decelerating, and fault states each need entry conditions and exit actions. Completed precharge alone does not permit power pulses: check gate-drive supply, sampling validity, contactor feedback, and command source. Share a consistent start-permission snapshot with the control interrupt so the fast loop cannot retain an old enable after background revocation.

Distinguish stationary motors from already rotating loads during startup. Airflow can backdrive fans, and backflow can rotate pumps. Applying a fixed initial frequency without identifying speed/direction can create current surges. Flying-start capability depends on motor type, measurements, and algorithms, not one universal delay. Induction-motor vector control requiring flux buildup also needs timeout and constrained exit paths during flux preparation.

Stop commands must at least distinguish controlled deceleration, coast stop, and fault shutdown. Controlled deceleration keeps the inverter active and needs a regenerative-energy path; coast-stop time depends on the load. Clearing a run bit proves neither an unenergized bus nor a stationary shaft. Report requested state, actual state, and stop reason separately. Decide restart permission independently after reset, preventing stored run commands from causing unexpected restart.

Debugging Checks

• Apply start requests with incomplete precharge, unready gate drive, and invalid samples separately. Confirm the prescribed state is maintained, output enable never appears briefly, and failure reasons are readable.
• Test command withdrawal during deceleration, restart before stopping completes, and old commands remaining after reset. Record actual output, bus changes, and state transitions against designed restart rules.

V/f Scalar Control

Scalar speed control of induction motors generally varies fundamental voltage amplitude with stator electrical frequency to maintain flux over a range. A constant ratio assumes approximately steady state and relatively small stator-resistance drops. Specify line-to-line RMS versus phase-voltage amplitude and frequency in hertz. Do not insert nameplate line-voltage numbers directly into modulation calculated from phase-voltage peaks.

At low frequency, stator-resistance drops become more significant, so linear voltage scaling may underexcite flux. Compensation can also overexcite and heat the motor, requiring validation against parameters and current limits. Above base frequency, the DC bus and modulation range limit voltage; further frequency increases generally enter field weakening and change continuous torque capability. Scalar control does not automatically guarantee low-speed full load or fast torque response.

Synchronous mechanical speed is n_s=60f_e/p in revolutions per minute, where f_e is stator electrical frequency and p is pole pairs. Actual induction-motor rotor speed also depends on slip and load. Normal displayed frequency with falling shaft speed is not necessarily a communication-reference error. Coordinate reference ramps, low-frequency compensation, bus normalization, and current limiting. Distinguish output frequency, estimated shaft speed, and measured shaft speed rather than confusing all three under one register name.

Debugging Checks

• Check nameplate connections, line/phase voltage conversion, poles versus pole pairs, and software voltage units. Check actual modulation amplitude at output limits so correct conversions are not obscured by clipping.
• Validate low-frequency compensation and base-frequency transitions under different loads. Record current, actual speed, temperature-rise trends, and current-limit state. Preserve load conditions with results; no-load running alone is insufficient.

FOC / Vector Control

First identify the motor type for vector control. Rotor-flux-oriented induction-motor control needs measured or estimated speed and a flux angle, with flux and torque components controlled by corresponding currents. Permanent-magnet motors rely on rotor electrical angle and their flux model. Both share transforms and current-loop structures, but parameters, startup preparation, and sensorless observer equations are not interchangeable.

For induction motors, the rotor-flux frame's electrical angular speed includes mechanical speed times pole pairs plus slip angular frequency, all in rad/s. Shaft speed is not directly the synchronous frame speed. Rotor time constant affects flux orientation, and winding temperature can shift parameters. Observe excitation current, torque current, and estimated flux together; good current tracking alone does not prove correct flux direction.

Schedule current loops, speed loops, flux buildup, voltage limits, and current limits on explicit sampling cadences. If estimated speed is invalid, select constrained reference hold, return to startup, or stopping according to stage; do not close the speed loop unconditionally. Low/zero-speed observability depends on algorithm and measurements. Sensorless vector control does not imply zero-speed torque holding under arbitrary loads. Speed-control products need torque/speed validation under specified conditions; positioning has additional feedback/mechanical constraints.

Debugging Checks

• Check motor model, pole pairs, speed units, flux-angle direction, and current signs. Confirm feedback direction in low-risk conditions with known rotation, rather than masking sign errors by adjusting gains.
• Cover flux preparation, closed-loop takeover, voltage limits, and speed-estimate failure. Record flux, both axis currents, and takeover state, verifying no extra reference jumps and valid exit rules.

Acceleration, Deceleration, Current Limits, and Loads

Acceleration/deceleration times describe reference changes; actual mechanical response also depends on inertia, load torque, and available current. For the shaft-side model J·dω_m/dt=T_e−T_L, inertia is in kg·m², mechanical angular speed in rad/s, and torque in N·m, with all quantities referred to the same shaft. This checks ramp plausibility but does not replace specific friction, transmission-elasticity, and process-load models.

Overly fast acceleration references may sustain torque-current limiting. Continued speed-error integration causes overshoot after limiting clears, requiring speed-loop coordination with current limits and implementation-consistent anti-windup. Scalar current limiting may adjust frequency slew or voltage, differing from vector torque limits. Expose readable limiting reasons and duration rather than merely indicating an unmet speed target.

During deceleration, motors may return mechanical energy to the bus. Braking resistors, regenerative front ends, or extended deceleration determine achievable stop trajectories. Relaxing overvoltage criteria does not dispose of energy. Evaluate high inertia, backdriven fans, and frequent starts separately; fan load laws do not apply directly to constant-torque conveyors. Define whether live ramp changes continue from the present reference or regenerate paths, avoiding abrupt frequency changes.

Debugging Checks

• Vary acceleration time for specified inertia/load combinations. Distinguish reference ramps, actual speed, and current-limit duration, checking integrator states and recovery after limiting clears.
• Cover deceleration with braking available, absent, and temporarily unavailable. Check bus trends, extended ramps, and stop reasons. Trajectory acceptance requires both electrical and mechanical constraints.

Run Commands and Reference Channels

Variable-frequency drives often offer panel, terminal, analog-input, and communication control. Run commands and speed references may use different channels, but the product must define valid combinations and authority to start, stop, and reverse. Form command objects with source and validity first, then submit through arbitration to the state machine. Multiple interrupts must not directly write run flags or frequencies, making the last write an implicit priority.

Reference channels also need dimensions, scaling, deadbands, and fault behavior. A broken analog input may appear out of range or fixed; communication registers must distinguish frequency, shaft speed, and proportional references. Centralize conversion and report the resulting actual target. Reading back the raw written value does not establish that it passed direction, maximum-frequency, and ramp constraints. Reversals must follow operating rules, not immediately swap phases or invert modulation angular speed.

Arbitration must define stop priorities, external inhibit effects, and local/remote takeover conditions. Publish control ownership separately from actual operation to explain accepted remote writes that are not executed. Communication acknowledgment proves protocol acceptance only; the interface contract must relate it to command application. Application stops and ordinary enables must not be independently labeled Safe Torque Off. Safety functions depend on actual system design and verification scope.

Debugging Checks

• Continuously issue opposing run requests and different references from two inputs. Check published priorities, rejection reasons, and actual targets, confirming no single-cycle ownership chatter.
• Check units, direction, and current ramps when switching panel, terminal, and communication references. For analog overrange or restricted remote writes, readback must explain the final adopted value and source.

Modbus Mapping and Write Permissions

A communication register table is a device-interface contract specifying addresses, types, units, scaling, valid ranges, access conditions, and activation stages. Modbus registers are 16 bits and the protocol defines multibyte transfer byte order. Devices must additionally define cross-register word order and sign interpretation for 32-bit application quantities. Distinguish documented numbering from frame addresses to prevent offsets caused by host numbering conventions.

Run commands, parameters, and status quantities need distinct permissions. Read-only feedback must not become writable merely because it shares an underlying array. Motor parameters restricted to stopped operation must not silently change while running. Validate length, addresses, ranges, and state conditions before committing an entire group. Mixed old/new multiregister references or parameters can form valid but wrong values; fast loops must read one generation's snapshot.

Distinguish protocol errors from application rejection: unsupported functions, invalid addresses, and disallowed values need interface-defined responses. Asynchronous actions also need processing, completed, or failed states. Serial broadcast writes have no per-device responses; silence does not prove nonexecution. New parameter fields need compatibility versions and default behavior. Do not reuse an old address with changed units, causing old hosts to assign another physical meaning to the same number.

Debugging Checks

• Use raw frames to check addresses, byte order, cross-word order, and signed boundaries, including physical readback. Test responses for read-only addresses, out-of-range values, and prohibited writes during operation.
• Interleave multiregister writes with control cycles, confirming that applications see complete versions only. Verify execution/response rules separately for broadcasts and unsupported functions, with diagnosable rejection logs.

Parameter Activation, Storage, and Recovery

Parameter changes have at least receipt, validation, application, and persistence stages. Real-time references usually need no per-update storage; motor models and power-stage settings may require stopped operation and coefficient rebuilding. Successful communication writes, algorithm adoption, and survival across reboot are separate facts. Expose parameter identifiers or versions and states so a power cut before saving is not mistaken for lost configuration.

Persistent records may use validity markers, versions, lengths, and checksums while retaining a recoverable previous complete configuration; atomic update methods depend on storage media and firmware. For internal-Flash EEPROM emulation, check erase/program granularity, endurance, interrupted-power behavior, and execution stalls. A library's power-loss recovery does not automatically guarantee application consistency. Related fields still need one validated commit unit.

Applying parameters also affects derived quantities and operating state. Rated-frequency changes may alter voltage curves; current-scaling changes affect display, control, and protection, not just UI fields. Factory reset must retain or explicitly reconstruct board calibration and hardware-type constraints; generic defaults must not overwrite dedicated measurement calibration. Unknown versions, corrupt records, or hardware mismatch at boot should report reasons and restrict startup, not interpret unexplained bytes as current configuration.

Debugging Checks

• Simulate reset or power loss during writing, validation, commit, and erase. Confirm boot adoption of complete, recognized versions only, checking backup records, error reporting, and startup restrictions.
• Repeatedly change related parameters, checking active, stored, and reboot-readback values. Monitor control cycles during erase/program operations to determine whether stopping or independent persistence scheduling is required.

Communication Timeouts and Control-Ownership Changes

Communication timeout is first a control contract, not a serial-error count. Frames for other devices, valid queries, or stale retransmissions do not necessarily renew the current controller's run permission. Define messages that refresh control leases or run heartbeats, calculate validity with monotonic time, and log reception, protocol validation, and command submission separately. Receive-interrupt activity alone must not preserve old run commands indefinitely.

Timeout actions depend on loads and product requirements: controlled deceleration, bounded holding of a limited target, or run revocation, accounting for deceleration energy and braking availability. Reconnection must not replay queued old start requests. Takeover validates the new channel, reasonable targets, and run permission before designed reference blending. Switching directly from a high remote reference to the panel value may create unacceptable speed jumps.

Serial gaps, checksum errors, and physical interference affect availability, but application timeouts need independent states/reasons. Stopping must not depend on timely background parsing; check command validity on an independently bounded cycle. Multimaster control, broadcasts, or local takeover after loss require explicit owner identity and revocation conditions if supported. Diagnostics should show active input, last valid command time, and invalidation action to distinguish link faults from ownership changes.

Debugging Checks

• Keep bus queries active while stopping control heartbeats, checking contractual command expiry. Inject retransmissions, delayed frames, and blocked parsing, verifying that validity is not refreshed incorrectly.
• Test reconnection, local takeover, and return of the original controller. Check reference transfer, renewed permission, and old-queue cleanup, recording maximum timeout-detection-to-output-change time.

Overcurrent Protection

Separate destructive fast faults, regulated current limiting, and longer overloads. Shorts or shoot-through can damage switches before a software cycle, so gate drivers, comparators, and timer fault paths must directly control outputs as designed. Display averages or slowly filtered current cannot replace this path. Fault interrupts record and coordinate subsequent states rather than serving as the sole shutdown mechanism.

Cycle-by-cycle timer handling and one-shot latching recover differently. Cycle-by-cycle limiting may release outputs at specified counter events; one-shot latching generally requires clearance conditions and explicit reset. Wrong modes can reenergize the bridge every cycle during persistent faults. Verify actual gate states through complementary outputs, dead time, and input polarity. Disabled registers do not prove correct external shutdown levels.

Derive criteria from selected power devices, measurement chains, and product conditions, considering detection error, blanking, and propagation. Distinguish noise trips from actual overlimits. Longer blanking reduces switching-transient trips but enlarges unprotected intervals; clean logs are not the optimization goal. Save trigger sources, sample saturation, operating stage, and reference changes. Use distinct codes for recoverable limiting and faults requiring explicit recovery, separating excessive load demand from hardware-path anomalies.

Debugging Checks

• Use prescribed low-risk signal injection to check comparator, timer, and gate-driver paths. Measure detection-input-to-gate delay, covering all bridge legs and persistent faults.
• Verify cycle-by-cycle limiting, one-shot latching, and restart after clearance separately, ensuring software does not clear faults prematurely. Analyze trips near switching noise and valid peaks instead of simply relaxing protection.

DC-Bus Undervoltage and Overvoltage

Interpret bus under/overvoltage by operating stage. Low voltage during precharge may be normal; a sudden running drop may arise from supply dips, rectification, or precharge-bypass faults. Deceleration rises may reflect regeneration. Log voltage changes, state, and braking requests in addition to range flags to distinguish energy imbalance from measurement faults.

Set thresholds, hysteresis, and confirmation times from actual voltage ratings, minimum operating voltages, measurement error, and conditions. DC-bus undervoltage, gate-supply undervoltage, and logic-supply reset are different observations and must not share recovery conditions merely because all are 'undervoltage.' Supply dips reduce available output voltage and may limit control; unchanged torque/high-speed demands affect current and stopping, requiring coordinated operating restrictions.

Overvoltage handling must check energy outlets. A braking request with overheated resistors, inactive choppers, or unavailable branches cannot justify normal-braking deceleration planning. After bridge shutdown, motor/bus behavior still depends on motor type and speed; voltage may not fall immediately. Diagnose stale samples, open dividers, and invalid isolation separately. Unknown bus voltage must not be treated as normal zero voltage permitting precharge.

Debugging Checks

• Apply identical voltage changes during precharge, steady operation, and deceleration. Check stage criteria, hysteresis, confirmation times, and event causes, ensuring running criteria do not falsely trip startup.
• Verify exit paths with unavailable braking, failed bus measurement, and restored supply. Record requests/feedback, ensuring recovery requires valid measurements and ready hardware.

Temperature Monitoring and Protection

Temperature protection starts with measurement location. Heatsinks, module thermistors, control-board ambient, and motor windings represent different thermal processes; none is automatically power-chip junction temperature. Thermal resistance and delay separate sensors from hotspots. Transient losses may raise junction temperature while slow readings look normal. Evaluate continuous-load limits jointly with losses and cooling.

Thermistor channels need nonlinearity, component tolerances, divider-reference, and ADC-error analysis, with tables/fits covering the actual range. Detect open circuits, shorts, and stale samples rather than mapping all to minimum temperature. Calibration reduces bias but not heat-transfer delay. If loss estimates assist derating, document model applicability and temperature-validation methods.

Protection may include warning, gradual derating, and fault stop, with hysteresis, minimum hold times, and reset conditions matching product requirements. Fan failure, blocked airflow, low-speed self-cooled motors, and high ambient temperatures change load capability; one ambient test cannot cover all conditions. Module thermistor monitoring and shutdown designs guide architecture, but their thresholds are not universal protection settings for another drive.

Debugging Checks

• Check physical locations, units, table ranges, and failure codes for every temperature value. Use known inputs for open/short and endpoint tests, ensuring abnormal inputs cannot appear as normal low temperature.
• Combine ambient temperature, load duration, and degraded cooling. Observe warning, derating, stop, and recovery order. Preserve measured temperature and thermal predictions separately, checking worst-case delay.

Fault Latching, Recording, and Reset

Track currently active faults, occurred but unacknowledged faults, and the first stop-causing event separately. A drive fault may lead to undervoltage, invalid speed feedback, and control timeouts; the last error is not necessarily the cause. Include monotonic time or control-cycle IDs, operating stage, and source. Add calendar time in background display if desired; unstable wall-clock time cannot order fast-loop events.

After faults, perform bounded output actions before freezing essential incident data. Flash logging, text formatting, and communication reporting must stay outside critical shutdown paths. Ring buffers retain pre/post-trigger current, voltage, references, and limits, with sample-loss and overwrite counts. Mark data invalid when faults also affect measurements, preventing saturated post-fault values from being mistaken for genuine pretrigger currents.

A vanished condition is not acknowledgment, and acknowledgment is not run permission. Control-library divisions into active faults, cleared-but-unacknowledged faults, and idle can guide design, but add product precharge, driver latches, and external permissions. Reset requests must check eligibility and report failure, not continuously clear flags to conceal persistent faults. Allowed retries need counts, intervals, and cumulative-fault policies; such logic is not evidence of functional-safety certification.

Debugging Checks

• Inject two faults and a later measurement failure in known order. Check first event, current bitmap, and history, ensuring the first cause is retained and frozen data includes validity flags.
• Issue reset/start requests with active faults, cleared but unacknowledged conditions, and missing post-acknowledgment permission. Check gate states, return reasons, retry limits, and log completeness.

Motor Parameters and Load Conditions

Start system integration with traceable motor, connection, and load configurations. Record type, nameplate voltage/frequency, rated current, pole pairs, connections, and cooling, matching software physical definitions. Nameplate current may differ from algorithm phase-current peak, while delta/star connections affect winding conversions. Copying another motor's working parameters can simultaneously change flux, current limits, and display scaling.

Define self-identification conditions and permitted actions. Algorithms may use stationary injection, rotation, or rotor restraint, requiring suitable mechanical permission and exits. 'Complete' status does not prove accuracy at every temperature, speed, and load. Preserve motor state, sampling calibration, and parameter versions; validate model/real response with independent conditions rather than using the same data to estimate and prove validity.

Load records need referred inertia, torque-versus-speed characteristics, breakaway resistance, backdriving potential, and continuous duration. No-load startup proves only that the sequence works in that condition, not high-inertia deceleration, low-speed cooling, or process peaks. Speed-control drives need specified-load startup, steady speed, limiting, and energy-handling evaluation. Accurate holding additionally requires feedback, brakes, and system capability; frequency accuracy alone is insufficient.

Debugging Checks

• Check every parameter against motor connections and measurement units. Link nameplates, board calibration, and software versions, and check startup restrictions for missing parameters or mismatched motor types.
• Validate identification at speed/load conditions excluded from estimation, comparing current, actual shaft speed, and limits. Record cold/hot and mechanically constrained conditions separately, stating coverage.

Startup, Speed Control, and Stopping

Integrate startup, speed control, and stopping as a complete event chain; separate successful jogs do not establish system acceptance. Begin from power-up, recording precharge feedback, driver readiness, sampling calibration, run permission, reference generation, and output order. Give each step observable success/timeout outcomes so early host commands or delayed contactor feedback still follow the designed progression.

Speed tests cover small changes, large ramps, direction requests, and load disturbances, preserving raw targets, constrained targets, and real shaft speed. Without shaft measurement, evidence proves only frequency or estimates, not mechanical-speed accuracy. Align communication times and control cycles to separate transport delay, ramp limits, and response. Slow host refresh can create stair-step plots that are not motor oscillation.

Stop tests examine both shaft and bus. Controlled deceleration checks braking availability, bus trends, and output exit timing; coast stops measure load-dependent mechanical stopping time. Repeated starts/stops accumulate resistor/motor heat, so one stop does not establish repeated operation. External inhibits or faults during startup, steady operation, or deceleration may use different exits. Check final states and renewed-request requirements after recovery.

Debugging Checks

• Apply identical start/stop sequences to first operation after power-up and repeated hot operation. Check state timing, bus voltage, and braking requests. Delay precharge feedback and run permission, confirming that commands cannot bypass preparation.
• Use one timebase for speed steps, ramps, and stop events. Preserve targets, constrained targets, measured or estimated shaft speeds, and states, specifying the feedback evidence used by each criterion.

Undervoltage, Overcurrent, and Limited States

Limited-state verification establishes what the device can deliver and when it must exit operation. Undervoltage reduces available voltage, overcurrent criteria may trigger fast shutdown, and regulating current limits may prevent target speed. These need different failure criteria. Predefine inputs, durations, expected states, and output constraints, observing unrestricted operation, limit entry, sustained limiting, and recovery.

First validate fault criteria/transitions in models, interface simulation, or controlled signal injection, then verify required hardware paths on the real device. Changing software measurements proves software branches only, not comparator, isolator, timer, or gate response. Fast overcurrent and control-current measurement may have different bandwidths/filters. State the triggered path so slow tests are not mislabeled short-circuit protection acceptance.

After limits clear, check internal controller state and target transfer. Sustained voltage/current limits can accumulate integration, invalidate observers, or retain stale references, creating recovery surges. Bus voltage may recover before gate supplies or measurements are ready. Wait for all prerequisites, then recover or remain stopped as defined. State injection levels and operating coverage; simulated passes do not establish product certification or complete fault coverage.

Debugging Checks

• Vary duration and operating stage for the same undervoltage waveform, checking differences in limiting, faults, and recovery. Preserve integrators, estimate validity, and reference transfer, checking abnormal post-limit peaks.
• List software-input injection, comparator-input injection, and actual output-chain verification separately, recording sources and response times. Limit conclusions to their tested paths without cross-layer inference.

Logs, Recovery, and Regression Verification

Repeatable integration requires saved test inputs and results. Logs need firmware IDs, hardware versions, motor settings, parameter IDs, command sources, and operating conditions; waveforms need sample periods, dimensions, and validity. Record serial packet loss or decimation with sequences and rules, or apparent curve differences may be logging artifacts. Correlate fast-loop buffers and slower state logs through event cycle IDs.

Recovery verification spans resets and power cycles, checking contractual retention/clearance of fault records, parameters, run permission, and ownership. After reconnection, hosts must read current states and decide actions rather than resend preinterruption commands solely because links recovered. Persistence busy states, corrupt records, and incompatible versions need reproducible inputs and observable outputs to distinguish configuration recovery errors from algorithm faults.

Build regressions around defined product behavior, preserving sequences, initial conditions, and criteria. Analog comparisons may use engineering-based numerical/time tolerances; state order, illegal output enables, and prohibited automatic restarts need independent checks. Do not merely replace baseline curves to hide new-firmware differences. Explain requirement changes or fixes and retain old baselines/reasons. Compare debug-enabled timing against normal operation.

Debugging Checks

• Replay baseline and new versions with identical configuration and inputs. Check waveform units, cycles, missing-sample flags, and event alignment. Ensure requirement-based tolerances and independent discrete-state criteria rather than curve comparison alone.
• Cover reset during storage, restart after faults, and control-link recovery. Check parameter versions, historical events, and run permission. Disable debug output and recheck key responses, recording tool-induced timing differences.