FAQ

[Matthias Schönberger]

Bei der Umsetzung des Energex Projektes für das Twike tauchen viele Fragen auf.
Dieser Thread ist auf Anregung von Markus Walser als FAQ gedacht.
==================================================================================
1. Wie robust ist die Kommunikation über SPI mit den Supervisors?
Ich hatte ursprünglich vor meine Rundzellen in 12er Blöcke zusammen zu fassen und jeweils einen Supervisor dazu zu packen.
Damit hätt ich dann etwa alle 8 cm einen Supervisor. Meinst du das geht? Ich mach mir sorgen, dass die Kommunikation über den SPI-Bus etwas anfällig ist. Viell. muss ich die Verbindungskabel so kurz wie möglich machen. Was ist deine Erfahrung?

2. Welche Blink-codes am Mediator gibt es?
Ich kenne die Fehlercodeausgabe, ein schnelles blinken der roten LED (mind. eine Zelle über VOV?) und ein langsames blinken der LED (etwa im Sekundentakt, Zellspannungen ok)

3. Wann wird der IGBT geschalten?

4. Supervisor.h und .c sind nicht aktiv, oder?

5. Ist es normal, dass die Ausgaben in der Debug Konsole etwas durcheinander sind, also Zeichen verloren gehen?

6. Kennst du das Problem keine Verbindung zum Supervisor zu haben (Error 2)? Seit ein paar Tagen hab ich dieses Problem.

7. Was sollte bei der Eingabe von 'u' Ausgegeben werden? Ich krieg da einen Wert den ich gar nicht einordnen kann. Wie läuft das mit der Kalibration des ADC?

8. Kannst du mir Tips zur Vorgehensweise bei der Inbetriebnahme geben? Was kann ich mit den Programmen TwikeAnalyzer, TwikeBMS und TwikeSimulator machen? (TwikeAnalyzer: Protokoll aufzeichnen und Mediator Programmieren)

9. Wie schaut die Kommunikation auf dem RS485-Bus des Twike aus?
Ich hab mein Notebook mit laufendem TwikeAnalyzer an die RS485 des Twikes gehängt und Protokoll Aufgezeichnet. Ich hab etwa im Sekundentakt ein Telegramm bekommen. Ist das ok? Kommt mir irgendwie langsam vor.

10. Ist mein Verständnis des Programmablaufs so richtig:
Es laufen 4 Threads.
Der Hauptthread (mediator.c) prüft, vom Wechselrichter ein neuer Betriebszustand über den RS485-Bus gesendet wurde und passt den Status des BMS dementsprechend an.
Der cmd_thread (command.c) horcht auf eingehende Telegramme auf dem RS485-Bus (Debug-Konsole oder Wechselrichter).
Der balancer_thread (balancer.c) prüft die Zellenspannungen und schaltet per Befehl an LTC's entsprechende Entladewiderstände über FET's parallel zur Zelle.
Über den Aufruf der Funktion balancer_switch_load() in der balancer loop werden die Entladewiederstände entsprechend den Werten im Array balancer_load[] geschalten.
Die Funktion wird nur aufgerufen, wenn balancer_state == BALANCER_ACTIVE ist.
Dann ist da noch der sensor_thread.

[Markus Walser]

Hallo Matthias

1. Wie robust ist die Kommunikation über SPI mit den Supervisors?

Also ich habe kurz nachgemessen wie lange der SPI-Bus bei mir ist und bin auf 1.7m gekommen, den Bus wird mit 250kHz betrieben (mediator.c:143)
Mit 1MHz hatte ich bereits im Labor Probleme, während ich mit 250kHz bis jetzt auch bei Fahrt mit Vollast keinen CRC Fehler bemerkt habe. Da du 10 statt wie bei mir 8 Supervisoren haben wirst, ist halt die Buslast dann auch etwas grösser. Also wäre es sicher gut, wenn du auch nicht gerade 1.7m Bus ziehen würdest.
Zum Buskabel noch zwei Bemerkungen: Bei mir ist der Bus (wie die Supervisoren auch) auf einer Aluplatte verlegt, die mit der Twikemasse verbunden ist. Sie sind also recht geschützt vor elektrischen Feldern verlegt und auch von den Batteriezellen abschirmt. Dann habe ich für dieses Flachbandkabel präventiv ein 3M™ High Flex Life Cable verwendet.
Also zur Frage ob das geht, ich denke du hast gute Chancen, wenn du die obigen Punkte beachten kannst.

2. Welche Blink-codes am Mediator gibt es?
Ich kenne die Fehlercodeausgabe, ein schnelles blinken der roten LED (mind. eine Zelle über VOV?) und ein langsames blinken der LED (etwa im Sekundentakt, Zellspannungen ok)

Das sind alle die mir noch in den Sinn kommen. Die Fehlercodes sind, wie du wahrscheinlich gesehen hast, in error.h:34-41.
Schnelles rotes Blinken ist Firmware Download vom Bootloader. Langsames grünes Blinken ist einfach Alive (resp.i.O.).
Ah der PLC wechselt beim Starten der Ladung von langsamen grünen Blinken auf schnelles grünes Blinken.

3. Wann wird der IGBT geschalten?

Hier ist wichtig, nicht wie im Schema einen IGBT sondern ein Mosfet einzusetzen. Ich habe gute Erfahrungen gemacht, mit einem STB25NM50N.
Mosfets sind viel toleranter gegenüber induktiven Überspannungen. Das gesagt, schaltet der Mosfet sobald direkt nach dem Booten des Mediators,
nachdem ein paar Dinge initialisiert sind und ein Offsetabgleich des ADCs stattgefunden hatte: mediator.c:131.

4. Supervisor.h und .c sind nicht aktiv, oder?

Kann entfernt werden. Stammt aus erstem Ansatz mit I2C Bus.

5. Ist es normal, dass die Ausgaben in der Debug Konsole etwas durcheinander sind, also Zeichen verloren gehen?

Jein, ich hatte zwar auch schon Verwürfelungen, aber da steckten jeweils Programmfehler dahinter.
Oder Zeichen schicken während der Ausgabe ist glaub auch nicht gut. Also wenn du mit "c" die Zellspannungen ausgibst, müsste schon eine
vollständige Tabelle kommen.

6. Kennst du das Problem keine Verbindung zum Supervisor zu haben (Error 2)? Seit ein paar Tagen hab ich dieses Problem.

Also CableBreak Error. Das kommt wenn die Busüberwachung einen unterbruch feststellt. Damit diese funktioniert, muss auf dem letzten
Supervisor am Bus der TOS (top of stack) Jumper gesetzt werden. Hast du das gemacht?

7. Was sollte bei der Eingabe von 'u' Ausgegeben werden? Ich krieg da einen Wert den ich gar nicht einordnen kann. Wie läuft das mit der Kalibration des ADC?

"u" sollte die Gesamtspannung messen. Hier ist dann noch wichtig, dass du den Spannungsteiler für die Spannungsmessung an deine höhere
Stackspannung anpasst. Aktuell liegt der Messbereich zwischen 5V - 405V o.ä.
Es gibt eine Offsetkalibration, der Strommesspfade, wenn kein Strom fliest (Mosfet und Relais offen). Der Spannungsoffset wird mit dem speziellen AtMega Kanal durchgeführt. Dann kann man via das Command prompt mit "r" die Zellspannungen via ltc auslesen und daraus eine Korrektur zum ATMega ADC rechen.

8. Kannst du mir Tips zur Vorgehensweise bei der Inbetriebnahme geben? Was kann ich mit den Programmen TwikeAnalyzer, TwikeBMS und TwikeSimulator machen? (TwikeAnalyzer: Protokoll aufzeichnen und Mediator Programmieren)

Als erstes würde ich jeden Supervisor mit Widerstandsspannungsteiler bestücken und schauen, ob Spannungsmessung geht "c", und ob Lastwiderstände
mit Command "f" geschaltet werden können. Dann solltest du mal prüfen, ob du Ströme von einem Labornetzteil eingespiesen via Command messen kannst mit "i", und zwar bidirektional. Dann auch mal eine Spannung mit Netzteil anlegen und schauen, ob etwas gemessen wird mit "u". Das Relais kann via Command mit "p full", mosfet mit "p save" und alles aus mit "p off". So solltest du mal ein Lämpchen von einem Netzteil schalten können und auch
gleich den Strom messen können.
Dann wirst du für LiFePO4 generell noch anpassungen machen müssen. Thomas Blaser hat da Änderungen dazu vorgenommen. Dabei kommt mir noch in den Sinn: Verifiziere, dass du die Verbindung zwischen AGND und DGND im Layout hats. Diese ist auf einem separaten Layer (51 oder 52) und muss bei der Produktion angegeben werden.


TwikeBMS brauchte ich zum Testen des Protokollsstacks gegen dieses TWIKE Dosprogramm. Ist wohl heute nicht sehr relevant.
TwikeSimulator war mein erstes Qt Programm während eines langweiligen Militärdienstes. Kann interessant sein, um Balanceralgorithmen zu testen.
TwikeAnalyzer ist sicher wichtig, zur Analyse und auch für Firmwaredownload zu Mediator oder PLC. (PLC braucht glab noch eine änderung beim
Bootloader Login.)

9. Wie schaut die Kommunikation auf dem RS485-Bus des Twike aus?
Ich hab mein Notebook mit laufendem TwikeAnalyzer an die RS485 des Twikes gehängt und Protokoll Aufgezeichnet. Ich hab etwa im Sekundentakt ein Telegramm bekommen. Ist das ok? Kommt mir irgendwie langsam vor.

Ja das sollte schneller gehen. Da ist eigentlich dauernd Traffic. Welche Version vom Twike Eprom hast du? Welche Änderungen hast du am QTwikeAnalyzer vorgenommen?

10. Ist mein Verständnis des Programmablaufs so richtig:
Es laufen 4 Threads.
Der Hauptthread (mediator.c) prüft, vom Wechselrichter ein neuer Betriebszustand über den RS485-Bus gesendet wurde und passt den Status des BMS dementsprechend an.

Richtig, plus U-Ladung, I-Ladung, Ausschalten des Twikes, etc.

Der cmd_thread (command.c) horcht auf eingehende Telegramme auf dem RS485-Bus (Debug-Konsole oder Wechselrichter).

Richtig. Eigentlich bedient er die RS485 Schnittstelle.

Der balancer_thread (balancer.c) prüft die Zellenspannungen und schaltet per Befehl an LTC's entsprechende Entladewiderstände über FET's parallel zur Zelle.
Über den Aufruf der Funktion balancer_switch_load() in der balancer loop werden die Entladewiederstände entsprechend den Werten im Array balancer_load[] geschalten.
Die Funktion wird nur aufgerufen, wenn balancer_state == BALANCER_ACTIVE ist.

Richtig.

Dann ist da noch der sensor_thread.

Der ist nicht aktiv. Der könnte für OneWire Temperatursensor für NiCd Delta-T Überwachung eingesetzt werden.
Generell ist dazu noch zu erwähnen, dass die Reihenfolge der Threaderzeugung die Priorität festlegt, und dass der zuletzt erzeugte (mit der tiefsten Priorität) kein sleep aufrufen darf. Sondern nur (loopende) delay.

Soviel für's erste. Viel Erfolg und Grüsse, Markus