Skip to main content
Firmware Stable

Motor driver: the motor does not turn, runs badly, or the driver reports an error

Applies to​

Every siliXcon motor controller (hwid starts with esc), whatever application runs on it. The application (LYNX, OPHION, ...) decides whether and how hard to drive and hands that to the driver as a drive command and a drive mode; the driver turns them into motor current. An application's playbook ends at that hand-off and this one starts there. When no application playbook matches the device, come here from the general method once the application's own mode shows nothing blocking, or as soon as /driver/error is not 0.

Before you start​

The rules of the general method apply. The one command this playbook may ask for is reinit (step 6): it needs emGUI's level at write, the user's go-ahead for that exact command, and the motor at standstill. It never runs run, stop or an identification itself. Motor identification is the motor identification playbook: it runs stop, identlin and identrun, each after the user's explicit yes and at the level the operator has set.

Steps​

1. What the application asks for​

read_variable /driver/cmd and /driver/mode: the last drive command (-1 ... 1) and drive mode the driver received (drive command, drive modes). Also /driver/iqmult and /driver/uqmult (imult and umult in BLDC builds): the application's scaling of the current and voltage references.

  • Mode 0 (freewheel), or cmd 0, while the user demands torque: the application is not asking. Go back to the application's playbook, or its mode page.
  • Mode and cmd ask for torque: step 2. A mode number the table does not list makes the driver freewheel.

2. /driver/error​

  • 0: step 3.
  • 65535: the driver is de-initialised - it did not start, or it was stopped. Step 6 (motor sensor) first, then the start-up self-test in step 8.
  • 65534: a service such as motor identification is running. Wait for it.
  • Anything else: decode it with the driver error decoder; the start-up values (over- or undervoltage, powered from the motor, ...) are under trivial values. A "phase ... CM" or "CM diff" error: CM error causes and check.

The error stays set until the driver starts again (a power cycle, or reinit), even after the cause is gone.

3. /driver/stat: protections active now​

Over-current, under-voltage, over-temperature, over-voltage, motor sensor and more (protection state). These clear by themselves and are held for at least a second, so read twice. Motor sensor bit: step 6. Voltage or temperature: step 8.

4. /driver/enable​

0 means the power stage is off. That is normal at standstill and in freewheel, even with the motor spinning (enable). If it stays 0 while step 1 asks for torque and steps 2 and 3 are clean, check step 5 (a limiter at zero) and step 6.

5. Limiters​

/driver/limit: each bit is an active limiter (limiter word); /driver/totallimit 1 means no limitation (totallimit). A limiter acting is behaviour, not a fault. It is the cause when it holds the output near zero; then read the parameters behind that bit: battery current, voltage and power under /driver/limiter (battery limiter), speed and motor temperature (motor limiters), and the current references /driver/iref and /driver/ipeak (iref and ipeak). Bit 14 alone (16384, with iqmult below 1) is the application's own scaling, for example a LYNX map's torque level.

6. Motor sensor​

There are numerous motor sensors, and the configured one has to pass three checks, in this order:

  1. Configured. /driver/prest is the sensor the driver uses (prest; BLDC builds: BLDC sensor selection).
  2. Supported by the hardware. Every controller comes in hardware variants, and the variant decides which sensor inputs the board has. decode_hwid with the device address returns them as motor_sensors. It is the same decoder a person opens with the HWID, for example https://docs.silixcon.com/mpn?hwid=esc5-ax1d_61kxa0810-A80.
  3. Supported by the firmware. Each application has firmware builds (mods) with different sensor support; the build is part of the swid (for example VECTOR_OPHION_resolver). The application's Mods page lists it: LYNX, OPHION, ECHO, FALCON, IGNIS. For another application, search_docs with "<application> mods".

Last check: reinit. It restarts the driver with the configured sensor and prints what it configures, for example configuring motor sensor mode 2: hall. When the line ends in unsupported, this firmware build does not contain that sensor. That answer is final: the configured sensor has to change to one that both the hardware and the firmware support, or the controller needs another firmware build. The return value is the resulting /driver/error (0 = the driver runs, 65535 = still de-initialised), not a success code, so read the printed text (reinit). Never use reinit <prest> to try sensors out: a sensor that has not been identified can make the motor spin.

Supported sensor, but the motor twitches, vibrates, runs rough or draws a high current at low speed: check the readings. Ask the user to turn the shaft slowly by hand while you read /driver/rest/mangle and /driver/rest/eangle; with Hall sensors, /driver/rest/hall must step through 1-6, and 0 or 7 means a missing or shorted sensor line (sensor states). The sensor mapping (hvar, rangle, offsets) comes from motor identification, step 7; hinv is set by hand (hinv).

7. Motor identification​

list_variables kind: param, path: /driver/motor. Resistance and inductances (Rt, Ld, Lq) at 0 mean the motor was never identified; a changed prest needs a new identification as well. Without it the driver cannot drive the motor properly, or at all. To identify it, go through the motor identification playbook with the user; the motor must be free to turn (identification commands, how to configure the controller for a motor).

8. Supply, temperature and the start-up self-test​

  • /driver/supply/voltage (supply) against the controller's working voltage range. That range is not the voltage in the hardware id: take voltage_variant from decode_hwid, follow its page to the edition's Product Specification (for example SX controller) and read that row of the "Maximum input voltage" and "Minimum input (supply) voltage" tables. The maximum working voltage there is the highest battery voltage allowed - lower than the hardware id's voltage, which is the transistors' rating. Never tell the user a battery of the hardware id's voltage can be connected (why). What happens between those limits: operating voltage.
  • /driver/temp (controller) and /driver/ptctemp (over-temperature); the motor temperature from /driver/motor/Rthermistor (NaN: no thermistor fitted) and its limiter (motor temperature limitation).
  • The driver tests the power stage and the motor at every start (diagnostic mechanisms); reinit prints the result. motor is disconnected: no motor on the phases, or a broken phase lead. motor is rotating: it started with the motor turning. init error N: decode N as a driver error (step 2).

9. History​

execute_command log (it can return -1 while printing entries - use the output). Compare each entry's run with the current run permanent (read_variable /permanents/run): a smaller run is an earlier power-up, history rather than the present cause; a larger one means the counter was reset since, so the entry is older still (error log format). An error that repeats in the current run is the lead.

10. Symptoms without an error​

11. Fix, one change at a time​

Propose a single change, cite the page, say which variable goes from what to what. Parameter writes and save need the operator to raise emGUI's level to write. A changed prest needs reinit (or a power cycle) and then a new motor identification: the motor identification playbook. Read the chain again afterwards.

12. Report​

  1. Device: name, serial number, hwid, swid.
  2. /driver/cmd and /driver/mode; /driver/error, /driver/stat, /driver/limit, quoted.
  3. Cause, with the values that show it (for the sensor: prest -> the board's motor_sensors -> the build's sensors -> what reinit printed).
  4. Fix, and which part needs a write or the user.
  5. URLs used; old log entries named as history.

13. Escalate​

Cause not found, a driver error that returns after a power cycle, or suspected hardware: ask for a diagnostic report.

Worked example​

Example unit (OPHION, swid VECTOR_OPHION_resolver ...), reported "does nothing":

  • /mode 0 (OPHION's error state, entered because /driver/error is not 0), /driver/cmd 0, /driver/mode 0. /driver/error = 65535: de-initialised.
  • /driver/prest = 2: Hall sensors.
  • decode_hwid: motor_sensors "Analog inputs (Sin-Cos), Hall sensors" - the board has no resolver input.
  • OPHION Mods: the resolver build supports resolver, SSI (ESC5) and sensorless - neither Hall nor Sin-Cos.
  • reinit printed motor is disconnected, configuring motor sensor mode 2: unsupported and rest initialization error, and returned 65535.
  • /driver/motor: Rt, Ld, Lq at 0 - never identified.

Diagnosis: the firmware build and the board have only sensorless mode in common, so the Hall sensor configured cannot start. To use the motor's Hall sensors, the controller needs the generic OPHION build (Hall and Sin-Cos); otherwise prest 1 (sensorless) is the only choice with this build. In both cases, connect the motor (the self-test found none) and identify it (motor identification playbook).