Hi all,
I could use some collective wisdom on a strange (and honestly a bit scary) behaviour I'm seeing, before I assume it's a firmware bug, it may well be my config or my understanding.
SETUP: MakerX Go-FOC G300 (300 A class VESC-based ESC), official VESC firmware 7.00 built from the `release_7_00` branch (also reproduced on the stock MakerX build), 14-pole 150 kV motor, PPM remote, tested on both 14S and 18S. Motor detection via the wizard, field weakening off, phase filters on. All tests unloaded, wheel off the ground.
SYMPTOM: in "PID speed" or "duty cycle" mode (both "no reverse"), slowly raising the throttle past a certain threshold makes the motor suddenly accelerate on its own ( a clearly audible step ) and settle at a stable speed. After that, the throttle input is completely dead: zero, partial, full, nothing changes anything. No fault code. The only way to stop it is to physically disconnect the battery. A few quick partial-throttle blips can trigger the same state.
What I've been able to rule out or observe so far:
- Not the remote/EMI: the PPM pulse decoded by the VESC (watched live over Bluetooth) stays a clean ~1.0 ms (zero throttle) during the whole runaway.
- Duty sits around 0.93; also reproduces with max duty limited to 0.85.
- ERPM reads 33 000 with my limit set to 28 000, the limiter is being bypassed.
- VESC Tool shows motor current jittering around 0 A, while a bench ammeter shows a real, steady ~4 A battery current. So the controller appears blind to the actual current.
- Current control mode (no reverse) is completely immune: I cannot reproduce it there at all.
My working theory, offered with all due humility: on a 300 A-class board the shunts are sized so that an unloaded ~4 A barely rises above the measurement noise floor. If the FOC observer effectively loses the current signal at high speed with near-zero commanded torque, the closed-loop modes (duty/speed) have no physical anchor left and can settle into a self-sustained "phantom drive" while current mode escapes because a 0 A setpoint simply switches the PWM off, outside of any feedback loop. That would also explain why no protection trips: they all act on the same (blind) measured current.
There are two older reports that look like cousins of this: GitHub issue #366 on vedderb/bldc ("stuck at full throttle", duty mode, FW 5.2) and a vesc-project thread (node/1084, duty stuck at full reverse, FW 3.x).
Questions:
1. Has anyone running duty or speed mode on oversized (high-current) VESC hardware with a small motor seen the input go dead like this?
2. Any config knobs worth trying — observer gain, current filter settings — that changed this kind of behaviour for you?
Safety note if anyone tries to reproduce: bench only, wheel off the ground, and keep a way to cut battery power within reach. Once latched it genuinely ignores the remote.
For now my practical workaround is simply to use Current No Reverse, which behaves flawlessly.
Thanks a lot for reading!
Yann
I could use some collective wisdom on a strange (and honestly a bit scary) behaviour I'm seeing, before I assume it's a firmware bug, it may well be my config or my understanding.
SETUP: MakerX Go-FOC G300 (300 A class VESC-based ESC), official VESC firmware 7.00 built from the `release_7_00` branch (also reproduced on the stock MakerX build), 14-pole 150 kV motor, PPM remote, tested on both 14S and 18S. Motor detection via the wizard, field weakening off, phase filters on. All tests unloaded, wheel off the ground.
SYMPTOM: in "PID speed" or "duty cycle" mode (both "no reverse"), slowly raising the throttle past a certain threshold makes the motor suddenly accelerate on its own ( a clearly audible step ) and settle at a stable speed. After that, the throttle input is completely dead: zero, partial, full, nothing changes anything. No fault code. The only way to stop it is to physically disconnect the battery. A few quick partial-throttle blips can trigger the same state.
What I've been able to rule out or observe so far:
- Not the remote/EMI: the PPM pulse decoded by the VESC (watched live over Bluetooth) stays a clean ~1.0 ms (zero throttle) during the whole runaway.
- Duty sits around 0.93; also reproduces with max duty limited to 0.85.
- ERPM reads 33 000 with my limit set to 28 000, the limiter is being bypassed.
- VESC Tool shows motor current jittering around 0 A, while a bench ammeter shows a real, steady ~4 A battery current. So the controller appears blind to the actual current.
- Current control mode (no reverse) is completely immune: I cannot reproduce it there at all.
My working theory, offered with all due humility: on a 300 A-class board the shunts are sized so that an unloaded ~4 A barely rises above the measurement noise floor. If the FOC observer effectively loses the current signal at high speed with near-zero commanded torque, the closed-loop modes (duty/speed) have no physical anchor left and can settle into a self-sustained "phantom drive" while current mode escapes because a 0 A setpoint simply switches the PWM off, outside of any feedback loop. That would also explain why no protection trips: they all act on the same (blind) measured current.
There are two older reports that look like cousins of this: GitHub issue #366 on vedderb/bldc ("stuck at full throttle", duty mode, FW 5.2) and a vesc-project thread (node/1084, duty stuck at full reverse, FW 3.x).
Questions:
1. Has anyone running duty or speed mode on oversized (high-current) VESC hardware with a small motor seen the input go dead like this?
2. Any config knobs worth trying — observer gain, current filter settings — that changed this kind of behaviour for you?
Safety note if anyone tries to reproduce: bench only, wheel off the ground, and keep a way to cut battery power within reach. Once latched it genuinely ignores the remote.
For now my practical workaround is simply to use Current No Reverse, which behaves flawlessly.
Thanks a lot for reading!
Yann
