VESC FW 7.00 on Go-FOC G300: motor latches into runaway and ignores all throttle input (duty & speed modes, unloaded) anyone seen this?

[ponp33]

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

 

[A-DamW]

Hi ponp33,

I was reading the Vesc Development Discord a few days ago, and someone named Jakob found a bug related to fault codes clearing and current setpoints:
Fix motor not stopping on repeated faults by clearing fault code on the same tick as the stop time expires- #926

I don't know if the fix itself is related to your issues, but it looks like BenjaminV cherry-picked the fix into FW 7.00.
So maybe try downloading the latest tool and update your FW?

Also note, the FW will still appear to be ver. 7.00, but the GIT Commit hash will be different.

Hope that helps,
Adam

 

[ponp33]

Hi ponp33,

I was reading the Vesc Development Discord a few days ago, and someone named Jakob found a bug related to fault codes clearing and current setpoints:
Fix motor not stopping on repeated faults by clearing fault code on the same tick as the stop time expires- #926

I don't know if the fix itself is related to your issues, but it looks like BenjaminV cherry-picked the fix into FW 7.00.
So maybe try downloading the latest tool and update you FW?

Also note, the FW will still appear to be ver. 7.00, but the GIT Commit hash will be different.

Hope that helps,
Adam

Thanks you very much for your answer Adam, I will try it.

 

[Gika]

Ciao a tutti,

Mi farebbe comodo un po' di saggezza collettiva per capire un comportamento strano (e onestamente un po' inquietante) che sto riscontrando, prima di presumere che si tratti di un bug del firmware, potrebbe benissimo dipendere dalla mia configurazione o dalla mia comprensione.

CONFIGURAZIONE: MakerX Go-FOC G300 (ESC basato su VESC classe 300 A), firmware VESC ufficiale 7.00 compilato dal ramo `release_7_00` (riprodotto anche sulla build standard di MakerX), motore a 14 poli da 150 kV, controllo remoto PPM, testato sia su 14S che su 18S. Rilevamento del motore tramite la procedura guidata, indebolimento del campo disattivato, filtri di fase attivati. Tutti i test a vuoto, ruota sollevata da terra.

SINTOMO: in modalità "velocità PID" o "ciclo di lavoro" (entrambe "senza retromarcia"), aumentando lentamente l'acceleratore oltre una certa soglia, il motore accelera improvvisamente da solo (un gradino chiaramente udibile) e si stabilizza a una velocità costante. Dopodiché, l'input dell'acceleratore è completamente bloccato: zero, parziale, massimo, nulla cambia. Nessun codice di errore. L'unico modo per interrompere il fenomeno è scollegare fisicamente la batteria. Alcune rapide accelerazioni parziali possono innescare la stessa condizione.

Ecco cosa sono riuscito a escludere o osservare finora:

- Non si tratta di un problema di interferenze elettromagnetiche/telecomando: l'impulso PPM decodificato dal VESC (monitorato in diretta tramite Bluetooth) rimane stabile a circa 1,0 ms (acceleratore zero) durante l'intera fase di accelerazione incontrollata.
- Il duty cycle si attesta intorno a 0,93; il problema si riproduce anche con un duty cycle massimo limitato a 0,85.
- L'ERPM indica 33.000, mentre il mio limite è impostato a 28.000; il limitatore viene aggirato.
- VESC Tool mostra una corrente del motore che oscilla intorno a 0 A, mentre un amperometro da banco mostra una corrente reale e stabile della batteria di circa 4 A. Quindi il controller sembra non essere in grado di rilevare la corrente effettiva.
- La modalità di controllo corrente (senza retromarcia) è completamente immune: non riesco a riprodurre il problema in alcun modo.

La mia teoria di lavoro, offerta con tutta la dovuta umiltà: su una scheda di classe A 300, gli shunt sono dimensionati in modo che una corrente a vuoto di circa 4 A superi appena il livello di rumore di misura. Se l'osservatore FOC perde effettivamente il segnale di corrente ad alta velocità con una coppia comandata prossima allo zero, le modalità a circuito chiuso (duty/velocità) non hanno più un punto di ancoraggio fisico e possono stabilizzarsi in un "azionamento fantasma" autosostenuto, mentre la modalità corrente sfugge perché un setpoint di 0 A semplicemente disattiva il PWM, al di fuori di qualsiasi anello di retroazione. Ciò spiegherebbe anche perché nessuna protezione interviene: tutte agiscono sulla stessa corrente misurata (ciecamente).

Esistono due segnalazioni precedenti che sembrano simili a questa: il problema n. 366 su GitHub relativo a vedderb/bldc ("bloccato a pieno regime", modalità di lavoro, FW 5.2) e una discussione sul progetto vesc (node/1084, modalità di lavoro bloccata a piena retromarcia, FW 3.x).

Domande:

1. Qualcuno che utilizza hardware VESC sovradimensionato (ad alta corrente) in modalità duty cycle o speed con un piccolo motore ha mai riscontrato un'interruzione dell'alimentazione di questo tipo?
2. Ci sono delle impostazioni di configurazione che vale la pena provare, come il guadagno dell'osservatore o le impostazioni del filtro corrente, che hanno modificato questo tipo di comportamento?

Nota di sicurezza per chiunque tenti di riprodurre il problema: utilizzare solo su un banco da lavoro, sollevare la ruota da terra e tenere a portata di mano un modo per interrompere l'alimentazione della batteria. Una volta bloccato, ignora completamente il telecomando.

Per ora la mia soluzione pratica è semplicemente quella di utilizzare Current No Reverse, che si comporta in modo impeccabile.

Grazie mille per la lettura!

Yann

Ciao... sulla mia bici uso un G300 ed è di gran lunga il miglior controller che abbia mai provato... dopo la procedura guidata non ho dovuto cambiare nulla, a differenza dei controller Flipsky 75200... uso il firmware 6.06 che ho scaricato dal sito di Maker X (file personalizzato) e la stessa versione del VESC Tool e non ho avuto alcun problema... durante la procedura guidata, quando ti ha chiesto se volevi ripristinare i parametri predefiniti, hai cliccato su "Sì" come consigliato?

 

[ponp33]

Hello,


I tested the latest update with firmware v7, but unfortunately, the issue is still present.


I cannot say exactly what triggers the issue. It seems to happen either after several motor startup attempts or when the motor is already running at full speed.


When the issue occurs, the motor suddenly accelerates even further and keeps running, completely ignoring the throttle input.


I’m still trying to identify the exact conditions that trigger it.

 

[AdR]

Have you checked to make sure its not the throttle that's faulty?
No issue with my spintend 250 with vesc 7 upgrade.
Did you do a clean install?

 

[ponp33]

Hello AdR, thanks for your message. Unfortunately yes I'm sure this is not faulty throttle. I verified it by looking at throttle value seen by the ESC (input ppm mapping tool) during the fail and it is correctly interpreted by the ESC. My next step will be to test with old firmware version and see if it works.

 

[ganzey]

are you using field weakening?