p_pid_kd_proc config field is silently no-op for DC/BLDC motor types (only implemented in FOC position control) #932

Summary

p_pid_kd_proc is a mc_configuration field (a second, independent "process D-term" gain for position control, computed from raw position feedback rather than from PID error) that is serialized/deserialized identically for all motor types via the shared config struct, but is only read inside the FOC position-control code path. For MOTOR_TYPE_DC/MOTOR_TYPE_BLDC, setting this value from VESC Tool has zero effect — the field is silently ignored rather than rejected or flagged as unsupported.

Where it's used (FOC only)

foc_run_pid_control_pos() in motor/foc_math.c reads it into a local kd_proc and computes a distinct derivative term from the raw angle delta (not from PID error): foc_math.c:416-419

float kp = conf_now->p_pid_kp;
float ki = conf_now->p_pid_ki;
float kd = conf_now->p_pid_kd;
float kd_proc = conf_now->p_pid_kd_proc;

and applies it here: foc_math.c:453-460

motor->m_pos_dt_int_proc += dt;
if (angle_now == motor->m_pos_prev_proc) {
d_term_proc = 0.0;
} else {
d_term_proc = -utils_angle_difference(angle_now, motor->m_pos_prev_proc) * error_sign * (kd_proc / motor->m_pos_dt_int_proc);
motor->m_pos_dt_int_proc = 0.0;
}

Where it's absent (DC/BLDC)

run_pid_control_pos() in motor/mcpwm.c — the position-control PID function used for MOTOR_TYPE_DC/MOTOR_TYPE_BLDC — has no reference to p_pid_kd_proc anywhere in its body; it only computes a single error-based D-term via p_pid_kd/p_pid_kd_filter: mcpwm.c:1246-1283

Confirmation the field is generic, not FOC-scoped, in the schema

The field is defined in the shared mc_configuration struct in datatypes.h and is unconditionally serialized/deserialized in confgenerator.c, with no motor-type guard — i.e., nothing in the wire protocol or config schema indicates this field is FOC-only: datatypes.h:1

Impact

Users running MOTOR_TYPE_DC/MOTOR_TYPE_BLDC with position control (e.g. steering/actuator applications) who tune p_pid_kd_proc via VESC Tool expecting it to affect the D-term will see no behavioral change whatsoever, with no warning/error — the value is stored but never consumed.
This is a more severe case of the same class of problem as the previously reported p_pid_kd_filter divergence: rather than being implemented differently between motor types, p_pid_kd_proc is not implemented at all outside FOC.

Suggested fix

Either port an equivalent "process D-term" computation to run_pid_control_pos() in motor/mcpwm.c for DC/BLDC motor types, or
Hide/disable the p_pid_kd_proc field in VESC Tool's UI when motor type is not FOC, and/or document in the field's tooltip/description that it is FOC-only, so users don't waste time tuning a parameter with no effect.

Environment

Custom hw_410-based hardware (STM32F405/F407, VESC 4.x-class board), DC motor with A/B hall sensor, MOTOR_TYPE_DC, CONTROL_MODE_POS (position control) for a steering/trim state machine application. Related to a previously reported divergence in p_pid_kd_filter behavior between FOC and DC/BLDC position control.

--- foc_math.c:416-460 mcpwm.c:1246-1283