Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
leider versuche ich den ganzen Abend, Lisp für das G30D-Display zu installieren. Nach dem Tutorial von Izuna konnte ich den Motor einstellen und alles, aber wenn ich das Skript aktualisieren möchte, bekomme ich immer diesen Fehler in Zeile 47...
Ich habe gesehen, dass ein anderes Mitglied im Forum das gleiche Problem hatte, aber ich weiß nicht, wie er es gelöst hat. Er schrieb nur "gelöst", aber bei mir ist der Packet Storage auch leer, und deshalb kann ich das Update in der VESC-PC-Software nicht durchführen.
leider versuche ich den ganzen Abend, Lisp für das G30D-Display zu installieren. Nach dem Tutorial von Izuna konnte ich den Motor einstellen und alles, aber wenn ich das Skript aktualisieren möchte, bekomme ich immer diesen Fehler in Zeile 47...
Ich habe gesehen, dass ein anderes Mitglied im Forum das gleiche Problem hatte, aber ich weiß nicht, wie er es gelöst hat. Er schrieb nur "gelöst", aber bei mir ist der Packet Storage auch leer, und deshalb kann ich das Update in der VESC-PC-Software nicht durchführen.
Ich habe das Update erfolgreich durchgeführt, das Display funktioniert. Wenn ich das Rad drehe, zeigt es die Geschwindigkeit in km/h an.
Aber egal, wie viel Gas ich gebe, der Motor startet nicht... Wenn ich jedoch überprüfe, in welche Richtung sich das Rad dreht (vorwärts oder rückwärts), dann dreht es sich.
Ich konnte das gesamte Tutorial durchgehen, aber der Motor reagiert nicht auf das Gasgeben. Woran könnte das liegen?
Wo sollte ich nachsehen?
Welches Script nutzt du? Meins oder das von Izuna?
Der Motor startet nicht aus dem Stand (das ist so gewollt) du brauchst mindestens 1 km/h für die “Freigabe” vom Motor.
Code:
(def min-speed 1) ; minimum speed in km/h to "activate" the motor, you can also set this to "0"
Schau dir außerdem nochmal das Video von Izuna langsam an, ob du alle Schritte durchführst! Ich hab beim ersten Mal auch übersehen ADC auf “Throttle no Reverse…” zu stellen.
Welches Script nutzt du? Meins oder das von Izuna?
Der Motor startet nicht aus dem Stand (das ist so gewollt) du brauchst mindestens 1 km/h für die “Freigabe” vom Motor.
Code:
(def min-speed 1) ; minimum speed in km/h to "activate" the motor, you can also set this to "0"
Schau dir außerdem nochmal das Video von Izuna langsam an, ob du alle Schritte durchführst! Ich hab beim ersten Mal auch übersehen ADC auf “Throttle no Reverse…” zu stellen.
Super, danke für deine Hilfe! Ich habe das Skript von Izuna installiert, aber diese Einstellungen hatte ich vorher nicht gemacht. Jetzt läuft es endlich!
Allerdings zeigt das Display S mit 16 km/h an. Ich weiß nicht, ob das eigentlich 20 km/h sein sollte und einfach falsch angezeigt wird, oder ob es wirklich nur 16 km/h sind.
Ich habe auch den Secret Mode ausprobiert, aber dort erreiche ich maximal 23 km/h im Leerlauf. Der Akku ist noch der originale 36V, aber selbst damit sollte das Rad im unbelasteten Zustand eigentlich mit ca. 30 km/h drehen.
Meine zweite Frage wäre: Wie kann ich schnell vom Secret Mode zurück in den normalen Betriebsmodus wechseln?
Hallo, mein BMS ist kaputt geworden und jetzt wollt ich mal fragen was für eines ihr benutzt. ich habe ein 20s 60A jetzt von jbd, jetzt dachte ich das gleiche zu kaufen mit aktiven balancer
Hallo ich weiß nicht ob ich hier richtig bin.
Ich habe einen Ninebot f2 D und würde gerne einen besseren Controller einbauen.
Der originale hat ja nur 25A und ich habe gerade gemerkt dass er bei 40A Last in der SHCFW abschaltet wenn er extrem gefordert wird.
Er gibt zwar nach ein paar Sekunden wieder frei aber ein besserer,mehr A, Controller wäre super.
Lg und much Respekt für eure Initiative und Hilfe für die Scooter Enthusiasten
Hallo ich weiß nicht ob ich hier richtig bin.
Ich habe einen Ninebot f2 D und würde gerne einen besseren Controller einbauen.
Der originale hat ja nur 25A und ich habe gerade gemerkt dass er bei 40A Last in der SHCFW abschaltet wenn er extrem gefordert wird.
Er gibt zwar nach ein paar Sekunden wieder frei aber ein besserer,mehr A, Controller wäre super.
Lg und much Respekt für eure Initiative und Hilfe für die Scooter Enthusiasten
Ich möchte von meiner traurigen Erfahrung mit der Script-Version 6.06 auf der Firmware 6.06 berichten.
Ich habe einen Flipsky 75100 als Hauptcontroller und einen Makerbase 75200 als sekundären Controller am CAN-Bus.
Ich habe das Script installiert, und BLE begann den Fehler „10“ anzuzeigen – es funktioniert nicht, selbst nach einem Neustart des BMS sowie nach einem kompletten Neustart der Controller. Der Fehler verschwand erst, nachdem ich „LispBM neu starten“ gedrückt hatte. Und das muss ich nach jedem Einschalten des Controllers machen.
Aber das Gas macht trotzdem nichts, obwohl die ADC-Einstellung die Stellung des Gashebels sieht und die Geschwindigkeit, bei der ich Gas gegeben habe, auch über dem Wert lag, der im Parameter „min-adc-throttle“ angegeben ist.
Ich habe einige Änderungen im Code vorgenommen, um das Gas zu „öffnen“ (siehe Datei vesc 6.06 throttle always.lisp). Danach hat auf dem Prüfstand/ohne Last alles wie gewünscht funktioniert (aber ich musste LispBM weiterhin neu starten).
Änderungen:
Die Unterschiede betreffen nur die Logik zum Freigeben von Gas/Bremse:
min-speed: In vesc 6.06 orig.lisp (Zeile 13) liegt die Schwelle bei 1 km/h, in vesc 6.06 throttle always.lisp (Zeile 13) wurde sie auf 0 km/h abgesenkt, sodass Gas/Bremse auch bei 0 Geschwindigkeit verfügbar sind.
handle-features: In vesc 6.06 orig.lisp (Zeilen 113–136) werden bei off/lock oder bei einer Geschwindigkeit unter min-speed Gas/Bremse auf 0 gesetzt, der Ausgang deaktiviert (app-disable-output -1) und der Strom zurückgesetzt; die Aktivierung erfolgt erst wieder nach Wegfall der Bedingungen. In vesc 6.06 throttle always.lisp (Zeilen 113–122) wurden diese Prüfungen entfernt – unabhängig vom Zustand wird bei Bedarf nur der Ausgang erneut aktiviert (app-disable-output 0), der Rest bleibt aktiv. Der übrige Code ist identisch, inklusive der Verarbeitung von Schloss/Alarmanlage. Das bedeutet: Die Version throttle always hält die Gas-/Bremsdurchleitung immer aktiv (sogar wenn off=1 oder Geschwindigkeit 0), und Sperre/Bremse hängen jetzt nur noch von handle-lock ab.
Aber es gibt einen Haken: Der zweite Controller (75200) ist schnell durchgebrannt. Vermutlich beim Gasgeben im Stand auf dem Scooter (ich habe nicht gemerkt, wann genau der Hintermotor aufgehört hat zu funktionieren).
Ich dachte, das Problem läge an einer unaufmerksamen VESC-Konfiguration, habe den Controller ersetzt und anschließend sehr sorgfältig alles so angepasst, dass es genau den Einstellungen entspricht, die ich bei Version 6.05 benutzt habe. Aber auch der neue Controller ist sofort wieder durchgebrannt – ebenfalls sehr schnell, und ich habe wieder nicht genau mitbekommen, wann das passiert ist.
Vermutlich sind bei beiden der Prozessor bzw. die CPU betroffen, gemessen daran, wie stark er sich beim Einschalten des 75200 erwärmt. Gleichzeitig ließen sich die Räder frei drehen (wahrscheinlich sind die FETs noch in Ordnung).
Warum ist das passiert? Alle Einstellungen sind korrekt, die Motorerkennung ist frisch, mechanisch gibt es keinerlei Probleme. Mit Version 6.05 hat alles über lange Zeit perfekt funktioniert.
Ich möchte von meiner traurigen Erfahrung mit der Script-Version 6.06 auf der Firmware 6.06 berichten.
Ich habe einen Flipsky 75100 als Hauptcontroller und einen Makerbase 75200 als sekundären Controller am CAN-Bus.
Ich habe das Script installiert, und BLE begann den Fehler „10“ anzuzeigen – es funktioniert nicht, selbst nach einem Neustart des BMS sowie nach einem kompletten Neustart der Controller. Der Fehler verschwand erst, nachdem ich „LispBM neu starten“ gedrückt hatte. Und das muss ich nach jedem Einschalten des Controllers machen.
Aber das Gas macht trotzdem nichts, obwohl die ADC-Einstellung die Stellung des Gashebels sieht und die Geschwindigkeit, bei der ich Gas gegeben habe, auch über dem Wert lag, der im Parameter „min-adc-throttle“ angegeben ist.
Ich habe einige Änderungen im Code vorgenommen, um das Gas zu „öffnen“ (siehe Datei vesc 6.06 throttle always.lisp). Danach hat auf dem Prüfstand/ohne Last alles wie gewünscht funktioniert (aber ich musste LispBM weiterhin neu starten).
Änderungen:
Die Unterschiede betreffen nur die Logik zum Freigeben von Gas/Bremse:
min-speed: In vesc 6.06 orig.lisp (Zeile 13) liegt die Schwelle bei 1 km/h, in vesc 6.06 throttle always.lisp (Zeile 13) wurde sie auf 0 km/h abgesenkt, sodass Gas/Bremse auch bei 0 Geschwindigkeit verfügbar sind.
handle-features: In vesc 6.06 orig.lisp (Zeilen 113–136) werden bei off/lock oder bei einer Geschwindigkeit unter min-speed Gas/Bremse auf 0 gesetzt, der Ausgang deaktiviert (app-disable-output -1) und der Strom zurückgesetzt; die Aktivierung erfolgt erst wieder nach Wegfall der Bedingungen. In vesc 6.06 throttle always.lisp (Zeilen 113–122) wurden diese Prüfungen entfernt – unabhängig vom Zustand wird bei Bedarf nur der Ausgang erneut aktiviert (app-disable-output 0), der Rest bleibt aktiv. Der übrige Code ist identisch, inklusive der Verarbeitung von Schloss/Alarmanlage. Das bedeutet: Die Version throttle always hält die Gas-/Bremsdurchleitung immer aktiv (sogar wenn off=1 oder Geschwindigkeit 0), und Sperre/Bremse hängen jetzt nur noch von handle-lock ab.
Aber es gibt einen Haken: Der zweite Controller (75200) ist schnell durchgebrannt. Vermutlich beim Gasgeben im Stand auf dem Scooter (ich habe nicht gemerkt, wann genau der Hintermotor aufgehört hat zu funktionieren).
Ich dachte, das Problem läge an einer unaufmerksamen VESC-Konfiguration, habe den Controller ersetzt und anschließend sehr sorgfältig alles so angepasst, dass es genau den Einstellungen entspricht, die ich bei Version 6.05 benutzt habe. Aber auch der neue Controller ist sofort wieder durchgebrannt – ebenfalls sehr schnell, und ich habe wieder nicht genau mitbekommen, wann das passiert ist.
Vermutlich sind bei beiden der Prozessor bzw. die CPU betroffen, gemessen daran, wie stark er sich beim Einschalten des 75200 erwärmt. Gleichzeitig ließen sich die Räder frei drehen (wahrscheinlich sind die FETs noch in Ordnung).
Warum ist das passiert? Alle Einstellungen sind korrekt, die Motorerkennung ist frisch, mechanisch gibt es keinerlei Probleme. Mit Version 6.05 hat alles über lange Zeit perfekt funktioniert.
zwei verschiedene controller sind bestimmt auch nicht gewöhnlich. Aber ganz wichtig, ein Geheimtipp, der gold wert ist, den viele leider nicht wissen:
Speziell bei diesen günstigeren Vescs, ist es absolut wichtig, direkt beide Controller - also Negativ, mit einem Kabel zu verbinden, wo KEINE Leistung drüber geht. Das nennt sich Potenzialausgleich und haben auch viele Controller wie Dualtrons zb serienmäßig!
Warum? Wenn ein Controller mehr zieht als der Andere, fällt die Spannung dort in den Kabeln mehr ab (VDrop) und dann sucht sich der Strom den kürzestem Weg , nämlich via Can Kabel, um die Spannung auszugleichen, wobei dann zu viel Strom über die Platine fließt, die Gate Driver stören und ein Kurzschluss der Mosfets daraus resultiert! Es reicht auf keinen Fall wenn beide Controller einfach nur am selben Negativ bzw - der Batterie hängen! Unbedingt einen direkten Ausgleich herstellen!
Hmmmm.... Klingt echt gut, kann man natürlich machen, bringt aber leider nichts .
Bei zwei Controllern, die am selben Minuspol (GND) des Akkus angeschlossen sind, entsteht automatisch ein gemeinsamer Bezugspunkt für die Stromkreise, so dass ein separater Potentialausgleich nicht notwendig ist.
Warum kein extra Ausgleich?Der gemeinsame Minuspol des Akkus dient bereits als zentrale Masse, über die beide Controller ihre Referenzspannungen teilen. Gerade dadurch werden ja Potentialunterschiede zwischen den Controllern vermieden.
Der Potentialausgleich bleibt auch bei CAN-Verbindung erhalten– CAN ist differential und benötigt keine explizite GND. Ein ungleicher Stromfluss (z. B. ein Controller zieht mehr) verursacht zwar, wie du korrekt gesagt hast, VDrop in den Power-Kabeln, aber CAN-Leitungen tragen keinen Ausgleichsstrom, da sie keine Power-Signale leiten.
Daran kann es also nicht gelegen haben - es sei denn, CAN wäre aus einem nicht nachvollziehbaren Grund ebenfalls an GND gehängt worden....
Hmmmm.... Klingt echt gut, kann man natürlich machen, bringt aber leider nichts .
Bei zwei Controllern, die am selben Minuspol (GND) des Akkus angeschlossen sind, entsteht automatisch ein gemeinsamer Bezugspunkt für die Stromkreise, so dass ein separater Potentialausgleich nicht notwendig ist.
Warum kein extra Ausgleich?Der gemeinsame Minuspol des Akkus dient bereits als zentrale Masse, über die beide Controller ihre Referenzspannungen teilen. Gerade dadurch werden ja Potentialunterschiede zwischen den Controllern vermieden.
Der Potentialausgleich bleibt auch bei CAN-Verbindung erhalten– CAN ist differential und benötigt keine explizite GND. Ein ungleicher Stromfluss (z. B. ein Controller zieht mehr) verursacht zwar, wie du korrekt gesagt hast, VDrop in den Power-Kabeln, aber CAN-Leitungen tragen keinen Ausgleichsstrom, da sie keine Power-Signale leiten.
Daran kann es also nicht gelegen haben - es sei denn, CAN wäre aus einem nicht nachvollziehbaren Grund ebenfalls an GND gehängt worden....
Da bist du falsch informiert. Das habe ich eben auch extra ausgeführt, warum dies nichts hilft, wenn die Negativen Kabeln nur am Akku verbunden sind, da genau hier zu stark unterschiedliche Leistung drüber laufen.
Wenn du zB sagen wir 20kw fährst und hinten vollen Grip hast, während du vorne durchdrehst, also wheelspin hast, reden wir von einer gewaltigen Differenz vom Controller bis zum Akku in den Kabeln von sagen wir 9KW!!!
Da brauchst du unbedingt eine neutrale Verbindung! Potentialausgleich direkt von Controller zu Controller! Die Vesc sind mit + - und zwei Datenkabel verbunden! Ist der Unterschied zu groß kriecht er über die Platinen. Kannst mir glauben habe kistenweise Controller hier mit abgebrannter Platine und alles ausgiebig gestestet, jedes Bauteil ersetzt und andere probiert, aber genau dies war der Grund. Damit ist niemandem geholfen, wenn du sagst das stimmt nicht, denn es ist so, darum macht das eben zB Dualtron ab Werk so.
Wenn du zB sagen wir 20kw fährst und hinten vollen Grip hast, während du vorne durchdrehst, also wheelspin hast, reden wir von einer gewaltigen Differenz vom Controller bis zum Akku in den Kabeln von sagen wir 9KW!!!
Und wo genau willst du die Verbindung setzen? Wie gesagt, wenn die beide an GND hängen, bringt es gar nuchts, einfach eine zweite Leitung zu ziehen ( es sei denn, die originalen Leitungen sind bereits viel zu dünn gewählt).
Ändert aber auch nichts daran, dass die Aussage zum Can-Bus falsch war und ist-darüber KANN nichts laufen.
Und wo genau willst du die Verbindung setzen? Wie gesagt, wenn die beide an GND hängen, bringt es gar nuchts, einfach eine zweite Leitung zu ziehen ( es sei denn, die originalen Leitungen sind bereits viel zu dünn gewählt).
Ändert aber auch nichts daran, dass die Aussage zum Can-Bus falsch war und ist-darüber KANN nichts laufen.
Am besten direkt auf die Busbars löten, jeweils auf beide Controller! Du sagst es ist dir klar, aber was genau irritiert dich dann? Das Thema hat auch nichts damit zu tun, ob die Leitungen zu dünn gewählt wären, denn die zusätzliche Leitung ist nur dazu da, um die Spannung beider Controller auszugleichen, was natürlich nicht geht wenn da eben 100A, oder 200A drüber fließen, drum nutzt es nichts, wenn sie nur über denn Akku verbunden sind. Es gehört von beiden Controllern die Busbar DIREKT verbunden, glaub es mir, oder nicht. Bei dem Design ist es nunmal so, wenn die Spannung zu unterschiedlich ist, dann raucht dir die Platine durch, nicht weil die Leistung zu viel wäre, sondern weil die Mosfets sich gegenseitig kurzschließen, da der Gate Treiber die Probleme mit abbekommt und der gesamte Controller ist im Eimer! (Strom sucht sich immer den kürzesten Weg)
Das nächste Thema ist, dass beim Schalten Spannungspitzen bis zu 25V entstehen können. Somit sind die Controller auch nicht für 20s ausgelegt, sondern maximal für 18s, da die Mosfets bis max 100V gehen. Das kann man aber so nicht messen, dafür braucht du ein Osziloskop und musst die Peak Werte messen. Habe ich natürlich gemacht und bin auf über 110V gekommen bei 20s. Ich habe so dermaßen viele Controller und Setups gebaut, ich rede keinen Schwachsinn, das kannst du mir tatächlich glauben.
ich weiß nicht ob ich hier richtig bin.
Enthusiasten
