4.6. Supervisory Algorithms¶

Supervisory algorithms include

Monitoring (including fault detection)
- Overvoltage/undervoltage detection
- Overcurrent detection
- Overtemperature detection
- Watchdog timer management
- Stall detection and recovery
Other supervisory algorithms
- Thermal management
- Saturation and antiwindup management (if not already present in the velocity and current controllers)
- Adaptive estimators (e.g. online resistance estimation)
- Field weakening
- Maximum torque per ampere (MTPA) controllers

4.6.1. Implementation Notes¶

4.6.1.1. Stall Detection¶

Stall detection consists of five methods intended to detect an overloaded or stalled motor:

Underspeed — If the motor velocity estimator remains accurate, a stalled motor can be detected if the magnitude of velocity estimate drops below a threshold.
Variance — In the event that a sensorless angle estimator loses synchronism with motor back-emf, the motor will tend to stall but the sensorless estimator may continue to estimate a nonzero electrical frequency. Under these conditions, voltages and currents exhibit oscillations at the estimated electrical frequency. Variance detection attempts to identify voltage and current oscillations.
Negative Ed — Spikes in negative d-axis estimated back-emf (\(E_d\)) can occur when a motor stalls and a sensorless angle estimator loses synchronism. This can be used as a detection method.
Torque angle — The angle between estimated back-emf and motor terminal voltage increases as the motor becomes more heavily loaded or stalls. This is equivalent mathematically to a ratio of back-emf magnitude to terminal voltage dropping below a speed-dependent threshold.
Software overcurrent — Heavily loaded motors may exceed acceptable levels of stator current.

Different motors present different symptoms of a stalled motor, which are detected by different algorithms of the ones listed above. All of the algorithms have some kind of filter or delay to avoid premature or false detection. (see errata)

More specific information is available on monitoring (including stall detection), and recovery in the corresponding documents.

4.6.1.2. Overtemperature Detection¶

MCAF provides an overtemperature detection fault for boards which provide bridge temperature measurement, added in MCAF R7.

A fault is triggered if the filtered bridge temperature exceeds a specified threshold. This provides some noise immunity from spikes in the raw temperature signal.

4.6.1.3. Other Algorithms¶

MCAF R1 – R5 do not include any of these algorithms:

Field weakening
Thermal management
Adaptive estimators
MTPA

4.6.1.4. Watchdog Timer Management¶

The watchdog module leverages the watchdog timer found in PIC^® microcontroller and dsPIC^® DSC devices. The hardware watchdog timeout is relatively simple, just a counter that automatically increments and causes a watchdog reset if it overflows; firmware prevents this by clearing the watchdog timer as a signal that it is operating normally, so that in the event that a blocking operation unexpectedly stops the firmware from being responsive, a reset will occur.

The MCAF uses the hardware watchdog timer to catch unresponsive code in both the main loop and the control ISR. It does this by requiring two simple tasks to run, one in the main loop and the other in the control ISR, in order for the watchdog timer to be reset. The function MCAF_WatchdogManageIsr() is the task that actually clears the watchdog timer from within the control ISR, but it also maintains a “software watchdog” counter isrCount which increments on each control loop update. It is the responsibility of the main loop task to call MCAF_WatchdogManageMainLoop(), which clears the software counter, often enough so that the software watchdog does not reach a timeout.

If the ISR becomes unresponsive, it will not clear the hardware watchdog timer, and upon the next watchdog timeout, a watchdog reset will occur.
If the main loop becomes unresponsive, it will not clear the software watchdog timer, and when that timer reaches a timeout threshold, the ISR will stop clearing the hardware watchdog timer. Upon the next watchdog timeout, a watchdog reset will occur. The main loop software watchdog timeout is essentially much longer than the hardware watchdog timeout, but it is also a much less critical task thread.

Cause of a watchdog reset can be determined by examining the value of the software watchdog counter; if it is above the timeout threshold then the main loop was unresponsive, whereas if the software counter is below the timeout threshold then the control ISR was unresponsive.

4.6.1.4.1. Errata¶

The torque angle detection method of stall detection is difficult to tune automatically. It works well for some motors, but can cause false detection faults in others. We have disabled this detection method by default since MCAF R3. It can be re-enabled by changing MCAF_StallDetectInit() to initialize the stall detection flag mask as follows:
```
pstallDetect->stallDetectFlagMask = MCAF_ALL_STALL_DETECT_METHODS_ENABLED;
```

4.6.1.5. Modules¶

Module	Files	Description
`fault_detect`	`fault_detect.c` `fault_detect.h` `fault_detect_types.h` `parameters/fault_detect_params.h`	Fault detection
`mcaf_watchdog`	`mcaf_watchdog.h`	Watchdog timer management
`monitor`	`monitor.c` `monitor.h` `monitor_types.h`	Fault-handling
`recover`	`recover.c` `recover.h`	Recovery from stall detection
`stall_detect`	`stall_detect.c` `stall_detect.h` `stall_detect_types.h`	Stall detection