Twizy Virtual BMS

Hallo zusammen, hi Dexter,

also ich komme (mal wieder) nicht weiter. Kann mir jemand auf die Sprünge helfen?
Ich habe zur Zeit ein 15S (LFP) System am Laufen, Standard-Config lt. Example Wiring, halt mit eigener Platine. Keine Extras (16-Bit-ADC...), um den Fehler einzugrenzen.
Es läuft alles soweit, aber den T in "GO" bringen funktioniert nicht. Die "N"-Leuchte blinkt, siehe Bild. Kein Error, kein Service oder Stop.
Die Laststromkreise habe ich gerde außer Betrieb, d.h. Buchsen aus dem Akkugehäuse ausgebaut und auf die Stecker am T gesteckt, mit den Interlocks gebrückt.
Ich bin kurz davor, die Platine nochmal auseinanderzureißen und nochmal mit dem Breadboard anzufangen...


Wo ist das fehlende Puzzleteil... ?

Hier meine CAN-Dumps:

twizy.debugInfo:
- twizyState=Ready
- clockCnt=0
- id423: 00 00 00 00 00 00 00 00
- id597: 00 00 00 00 00 00 00 00
- id599: 00 00 00 00 00 00 00 00
- id155: 01 97 D0 54 9A AF 00 6F
- id424: 11 40 03 13 39 64 00 3A
- id425: 24 1F 44 FF FE 00 01 00
- id554: 39 39 39 39 39 39 39 00
- id556: 2C 62 C6 2C 62 C6 2C 6A
- id557: 2C 62 C6 2C 62 C6 2C 60
- id55E: 2C 62 C6 2C 62 C6 0C F9
- id55F: FF FF 73 00 00 1F 11 F1
- id628: 00 00 00
- id659: FF FF FF FF
- id700: 03 00 FF FF FF 00 00 00

*** CALIBRATION INFO [10s interval] ***
< c00 = 3.325 [ 3.325 ]
< c01 = 6.671 [ 3.347 ]
< c02 = 9.967 [ 3.296 ]
< c03 = 13.271 [ 3.303 ]
< c04 = 16.578 [ 3.307 ]
< c05 = 19.912 [ 3.334 ]
< c06 = 23.269 [ 3.357 ]
< c07 = 26.548 [ 3.279 ]
< c08 = 29.913 [ 3.365 ]
< c09 = 33.187 [ 3.273 ]
< c10 = 36.537 [ 3.350 ]
< c11 = 39.802 [ 3.265 ]
< c12 = 43.135 [ 3.333 ]
< c13 = 46.510 [ 3.375 ]
< c14 = 49.847 [ 3.338 ]
< curr = 0.0
< temp_f = 18
< temp_r = 18


Eine kleiner Antwort würde mir echt helfen


Grüße,
Richard

P.S: sobald alles läuft, update ich natürlich mein GitHub Repo, sodass andere die Platine nachbauen können und den Code 1:1 draufladen können...

Richie schrieb: - id423: 00 00 00 00 00 00 00 00
- id597: 00 00 00 00 00 00 00 00

Das sieht aus als wäre das Ladegerät nicht aktiv oder nicht am CAN-Bus. ID 597 steuert den Statuswechsel.

Hm ja, da hätte ich auch selber draufkommen können.
Bit 5 hätte ja gerade eben mindestens kommen müssen, als ich ihn ans Stromnetz angeschlossen habe.
Na dann schau ich mal, ob ich in der Richtung was rausfinden kann... irgendwelche Hinweise? Ich würde jetzt mal mit den Sicherungen anfangen. Der Lüfter läuft jedenfalls los, wenn ich ihn anmache und er zeigt nach dem Schlüsseldrehen auch den Ladestand an (98%).

Vielleicht ist es doch das letze CAN-Bus-Leitungsstück (30cm) zum MCP2515-Modul .. das ist nämlich parallel zu 12V/GND und den anderen Signalen verlegt.

In den letzen Tagen hab ich rumgesucht.
- Ladegerät ausgebaut und von innen angeschaut => keine erkennbaren Defekte (Brandspuren etc.)
- Mit Pyren dran => "BCB" wird nicht angezeigt, siehe Bild.
- 12V Batterie wird zuverlässig geladen, wenn Fzg. an und am 230V Netz hängt.

Wird wohl nur eine Reparatur über sender oder ein Neukauf bleiben...

Richie schrieb: - Mit Pyren dran => "BCB" wird nicht angezeigt, siehe Bild.

Hallo Richie

In diesem Beitrag ist für Gäste nicht alles sichtbar. Bitte melde dich an, oder registriere dich.

@+

Hallo zusammen,

@ThM -- ja, der Schlüssel ist beim Auslesen gedreht.

Die Fehlersuche geht in die nächste Runde... leider bisher weniger erfolgreich.

Stand: Batterie inkl. Arduino-Platine im Wohnzimmer und der T vor der Tür davor; Kabel alle verlängert (Twisted Pair Kabel) inkl. orange Stecker separat.

Der T geht mittlerweile "fast" in den GO-Modus. Jedenfalls wird schonmal 0km/h angezeigt und die Leistungsrelais in der Akkubox klacken.

Problem: Beim ersten Schlüsseldrehen 0-1 leuchtet die Service Indicator und Stop Indicator jeweils zusammen kurz auf und gehen dann wieder aus; im ca. 3s-Takt.
Wenn ich von 1-Zündung gehe, bleibt Stop Indicator an. Für mich sieht das so aus, als quittiert die KlausBMS-Software den Fehler periodisch weg, eher er wieder kommt.

Keine Ahnung wo ich noch suchen soll... Der Ladegerät war mittlerweile bei Sender.de: Keine Mängel.
CAN-Bus habe ich mir mit dem Oszi angeschaut => alles im normalen Bereich. Interlocks gesteckt.

Die CAN-Dumps sehen gut aus (soweit ich das beurteilen kann), wenn ich mit Pyren drangeh, wird immer noch kein BCB und Armaturenbrett angezeigt, siehe Bild. Etwas schade ist, dass Pyren keinerlei Diagnosemöglichkeit bietet.
Die Pyren-Anzeige beim Starten im Anhang.

Hier noch meine CAN-Dumps:

twizy.debugInfo:
- twizyState=Driving
- clockCnt=1000
- id423: 03 37 FF FF 00 E0 00 E7
- id597: 00 95 28 41 2B 00 01 31
- id599: 00 01 27 01 FF 19 00 00
- id155: 01 97 50 54 99 60 00 6F
- id424: 11 40 00 11 35 64 00 34
- id425: 2A 1F 44 FF FD FC 00 FE
- id554: 34 34 34 34 34 34 34 00
- id556: 2C 22 C2 2C 22 C2 2C 2A
- id557: 2C 22 C2 2C 22 C2 2C 20
- id55E: 2C 22 C2 2C 22 C2 1D 80
- id55F: FF FF 73 00 00 1E E1 EE
- id628: 00 00 00
- id659: FF FF FF FF
- id700: 05 00 FF FF FF 00 00 00

Interessant ist, dass bei Object 423 Byte #8 sehr unkonstant ist, d.h. mal steht es auf 00, mal auf EC, mal EB, mal E8, E9, EA....
Noch eine Frage: Muss der 120Ohm-Abschlusswiderstand gesetzt sein oder nicht?

Naja, vielleicht hat ja jemand eine Idee... Gruß Richard

Würde dir gerne helfen, da du ein sehr interessantes Projekt betreibst.
Bin in diesem Bereich aber völlig frei von Wissen.
Ich drück dir die Daumen, dass es dir gelingt die Probleme zu lösen.

Vielen Dank für die moralische Unterstützung ja, es ist nicht einfach, weil ich einfach über Monate hinweg einfach so vor mich hin bastle ohne viel Feedback. Toll wäre ein kleiner Verein diesbezüglich...

Richie schrieb: ja, es ist nicht einfach, weil ich einfach über Monate hinweg einfach so vor mich hin bastle ohne viel Feedback.

Ich kann dich gut verstehen, aber das Forum hat seine besten Zeiten hinter sich.
Nahezu alle Kompetenzträger sind inzwischen abhanden gekommen.

Nochmal ein Update, vielleicht hat Dexter ja Zeit, sich das kurz anzuschauen.

Der Fehler ist "eingegrenzt": Das Stop+Service+Beep kommen immer dann kurz, wenn mir auf dem Serial Monitor die Daten ausgegeben werden. Nach langem Suchen im Code konnte ich mir aber keinen Reim drauf machen (bin kein ausgebildeter Programmierer, eher ein Code-Schnipsler)
Bei ID628 steht ja auch 00 00 00 = kein Fehler;


twizy.debugInfo:
- twizyState=Driving
- clockCnt=0
- id423: 03 34 FF FF 00 E0 00 EA
- id597: 00 95 06 41 2B 00 01 38
- id599: 00 01 27 01 FF 19 00 00
- id155: 01 97 BC 54 99 76 00 6F
- id424: 11 40 04 11 35 64 00 34
- id425: 2A 1F 44 FF FD FA 00 FD
- id554: 34 34 34 34 34 34 34 00
- id556: 2C 12 C1 2C 12 C1 2C 1A
- id557: 2C 12 C1 2C 12 C1 2C 10
- id55E: 2C 12 C1 2C 12 C1 1D 80
- id55F: FF FF 73 00 00 1E D1 ED
- id628: 00 00 00
- id659: FF FF FF FF
- id700: 05 00 FF FF FF 00 00 00

Nach einer Neuinstallation von PyRen werden übrigens alle Steuergeräte angezeigt... da muss man erstmal draufkommen
Failflags gibt es noch, aber leider zeigt er mir im Untermenü keine Details zu den Fehlern an.


Grüße,
Richard

Kurzes Update:

System läuft - Fahrzeug fährt!

jetzt stehen noch ein paar Testfahrten und Probeladen an.
Für eine Projektzusammenfassung inkl. Fotos auf github habe ich Mitte des Monats Zeit.