Hallo an die Elektronikexperten hier im Forum!

Ist der Datenbus vom Umrichter im Twike eigentlich elektrisch irgendwie abweichend vom RS485 Standard verwendet oder sollte an den beiden Datenleitungen auch jeweils ein komplementäres Signal gegen Gnd zu messen sein?

 

Ich frage, weil ich von hier im Forum mal was über spezielle Modifikationen an einem RS485 Testadapter in Erinnerung habe (nur jetzt nicht mehr finde).

 

Hintergrund: Vor einiger Zeit ist mein gutes altes Twike leider mitten auf der Strecke stehengeblieben, weil der Umrichter laut Fehlermeldung die Kommunikation mit allen Batteriekontrollern verloren hatte. Jetzt bin ich endlich mal dazugekommen, die Bussignale mit dem Oszi anzuschauen, aber nur SIO+ vom Umrichter trägt ein Signal, SIO- bleibt konstant auf etwa +2V gegen GND.

 

Fehlt das SIO- Signal generell? Oder kennt vieleicht jemand dieses Kommunikationsproblem, und ich stehe nur mit meiner Messung auf der Leitung?

Hallöchen,

 

ich habe es zwar noch nicht ausgemessen bzw. weiß es auch nicht aus Erfahrung,

aber nach meinem Wissensstand mißt man beim RS485 nicht gegen Masse sondern die Kommunikation ist bei RS485 die Differenz der beiden Datenleitungen.

-> Wikipedia

 

Die Modifikaton des Twike-RS485 Adapters bezog sich darauf, dass es nur ein Kanal (vom Duplex-Adapter) genutzt und die beiden anderen Leitungen für die Versorgungspannung (+12V) für die DC/DCs auf der Twikeplatine genutzt wurden.

-> Beitrag aus dem alten Forum

Hallo Stefan,

 

das RS485 ist auch beim Twike das Differentielle Signal.

 

Ich habe es bei mir schon geschafft die Leiterbahnen an den 4 RS485 Steckern

auf der Anschlussplatine zu zerstören. Vielleicht ist das bei Dir auch der Fall ?

 

Ansonsten mal direkt am Wechselrichter messen.

Einen Adapter kann man mit einem Max485 (o.ä.) einfach selber bauen.

Das RS232 RTS wird für die Umschaltung verwendet.

 

Am besten erstmal alle Batterien abziehen (nur RS485, sonst fehlt der Saft ;-) )

und sehen ob dann der zweite Pegel da ist ...

 

Viel Glück,

 

Matthias tw514 (Zweittwike tw305 in Arbeit)

Hallo Berny, vielen Dank für die schnelle Antwort und vor allem auch fürs Raussuchen des alten Forumsbeitrags!

 

... mißt man beim RS485 nicht gegen Masse sondern die Kommunikation ist bei RS485 die Differenz der beiden Datenleitungen.

Das dachte ich erst auch, und beim Messen des Differenzzignals ist mir erst auch noch nichts ganz Falsches aufgefallen, die gemessene Differenz sieht brauchbar aus. Dennoch bekomme ich mit meinem RS485 Testadapter beim Mithöhren mit PC nur wenige gültige Nachrichten, über 90% haben Checksummenfehler.

Da weiß ich jetzt immer noch nicht, ob Umrichter, Battcontroller oder Kabel und mein Testadapter Blödsinn machen.

Ich habe eine allgemeine Testanleitung für solche Busse gefunden [url=]http://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CD8QFjAC&url=http%3A%2F%2Fwww.saia-pcd.com%2Fde%2Fabout_controls%2Flocations%2Fgermany%2FSchulungsangebot%2Fkommunikation%2FSaiaS-Net%2FDocuments%2FA-2FehlersucheinSeriellenNetzen_LAH.pdf&ei=ub2vUdmiOsqJtAbgloHwDQ&usg=AFQjCNHYe7y3sq7Bjhhcsj_FKkSeQilQuQ&bvm=bv.47534661,d.Yms[/url] und, der ensprechend, die beiden Signalleitungen gegen Gnd gemessen- das schau'n dann wirklich nicht mehr richtig wie üblich aus, da fehlt eben das Komplementärsignal.

Daher immer noch meine Frage, kann das Twike sonst mit Signalpegel nur auf der SIO+ Leitung alleine leben oder sollte auch SIO- wie üblich Signal tragen, d.h. dann ist wohl der Umrichter über den Jordan gegangen?

Hallo Berny, vielen Dank für die schnelle Antwort und vor allem auch fürs Raussuchen des alten Forumsbeitrags!

 

... mißt man beim RS485 nicht gegen Masse sondern die Kommunikation ist bei RS485 die Differenz der beiden Datenleitungen.

Das dachte ich erst auch, und beim Messen des Differenzzignals ist mir erst auch noch nichts ganz Falsches aufgefallen, die gemessene Differenz sieht brauchbar aus. Dennoch bekomme ich mit meinem RS485 Testadapter beim Mithöhren mit PC nur wenige gültige Nachrichten, über 90% haben Checksummenfehler.

Da weiß ich jetzt immer noch nicht, ob Umrichter, Battcontroller oder Kabel und mein Testadapter Blödsinn machen.

Ich habe eine allgemeine Testanleitung für solche Busse gefunden [url=]http://www.google.at/url?sa=t&rct=j&q=&esrc=s&source=web&cd=3&cad=rja&ved=0CD8QFjAC&url=http%3A%2F%2Fwww.saia-pcd.com%2Fde%2Fabout_controls%2Flocations%2Fgermany%2FSchulungsangebot%2Fkommunikation%2FSaiaS-Net%2FDocuments%2FA-2FehlersucheinSeriellenNetzen_LAH.pdf&ei=ub2vUdmiOsqJtAbgloHwDQ&usg=AFQjCNHYe7y3sq7Bjhhcsj_FKkSeQilQuQ&bvm=bv.47534661,d.Yms[/url] und, der ensprechend, die beiden Signalleitungen gegen Gnd gemessen- das schau'n dann wirklich nicht mehr richtig wie üblich aus, da fehlt eben das Komplementärsignal.

Daher immer noch meine Frage, kann das Twike sonst mit Signalpegel nur auf der SIO+ Leitung alleine leben oder sollte auch SIO- wie üblich Signal tragen, d.h. dann ist wohl der Umrichter über den Jordan gegangen?

Danke Matthias,

die ganze Busverdrahtung vom Umrichter bis zu den Batprints habe ich schon Ohmsch durchgeprüft, sieht eigentlich gut aus.

..das RS485 ist auch beim Twike das Differentielle Signal.

Nur sowas wie 120Ohm Abschlußwiderstände und Pullups messe ich zumindest in Ruhe nirgends, zwischen den Anschlüssen der Differenzleitungen sind überall mindestens 4,5KOhm oder mehr.:bang:

 

Dennoch danke für den Tipp, und so ein 'Zweittwike' :roll: währ´eventuell auch keine schlechte Idee.

Hallo edriver01,

Markus Walser, der Initiator des Energex Projekts (http://code.google.com/p/energex/) hat eine eigene Software geschrieben (QTwikeAnalyzer) , um den Datenverkehr des Twike-Buses aufzuzeichnen. Wenn einer sich jemand mit dem Twike RS485 Protokoll auskennt, dann er. Vielleicht kann er Dir weiterhelfen.

 

Viele Grüße,

 

Markus

Hallo TW174,

fein, daß du das Energex- Projekt von Markus Walser ansprichst, das finde ich auch so toll, dass ich bereits seit einiger Zeit mitten drin im eigenen Nachbau des Energex Mediator Prints bin. Leider bin ich auf dem Weg dazu (aber noch beim Fahren mit den verbastelten, alten Batteriecontrollern) aber eben mit diesem Kommunikationsproblem steckengeblieben.

 

Ich habe mir inzwischen die Umrichterplatine angesehen, das Send- Signal aus dem Microcontroller dort gehr auf einen Treiberchip, der nach einem LTC485 mit symetrischer Standardbeschaltung aussieht. Auch die restlichen Busteilnehmer verhalten sich etwa symetrisch wie erwartet, daher gehe ich inzwischen eigentlich davon aus, dass mein Umrichter wirklich defekt ist.

 

Hat jemand eventuell einen Umrichter(Print) übrig und günstig abzugeben oder schon Erfahrungen mit reparieren lassen?

Bei ebay UK werden gerade sehr günstig gebrauchte tbwoods angeboten, da währ` nur die Frage, ob ich dort mein Twike Eprom reinstecken kann oder die Dinger sonst anders auf die Twike Software programmiert werden können? <>

Vielleicht hilft Dir das:

ich habe jetzt mal den Schaltplan der Batterieprints nachgezeichnet. Nur ein winziges Stück davon, nur den Teil, der außerhalb der Optokoppler liegt. Auf dem Batterieprint befinden sich drei Optokoppler, zwei davon sind offenbar Empfänger, einer ist der Sender. Bei den Empfängern ist es wiederum so, dass einer von beiden beim Auftreten einer positiven Halbwelle ein Signal gibt, der andere beim Auftreten einer negativen Halbwelle. Wenn bei Dir also nur noch positive Halbwellen auftreten, könnte auf der Seite des Wechselrichters ein Teil ausgefallen sein.

Ich verstehe nicht viel von Elektronik und kann daher für nichts garantieren. Ich weiß auch nicht, ob es auf der Seite des Wechselrichters ebenfalls Optokoppler gibt, die zum Schutz der dahinter liegenden Bauteile dienen. Kannst ja mal nachsehen.

 

 

Gruß,

 

Markus

Teilerfolg- ein Statusupdate: meine Umrichterprint war recht eindeutig defekt. Ich habe jetzt dort einen neuen Treiberchip LTC485 reingelötet, jetzt kann ich schöne symetrische Signale auf dem Datenbus messen, auch ohne Abschlußwiderstände.

 

Jetzt gehts dann endlich mit Energex wieder weiter. Als nächstes muss ich meine Mediatorprint wieder fitt machen und anschließen, dann läuft hoffentlich langsam wieder was.

 

(Zusätzlich hat aber mein PC Testadapter aber auch noch einen Fehler, mit dem dran wird Signal wieder deutlich schwächer- den schließe ich erstmal nicht mehr an)

Hallo evdriver01,

super, herzlichen Glückwunsch! Kannst Du vielleicht genau erklären, was Du getan hast? (Vielleicht sogar mit Bildern?). Ich könnte mich im Gegenzug mit einem Teil des Schaltplans der Batterieprints revangieren. Ich habe denjenigen Teil von deren Schaltplan aufgedröselt, der außerhalb der Optokoppler liegt.

Ich habe derzeit ein ganz ähnliches Problem wie Du. Bei mir sind während eines Ladevorgangs alle drei Batterieprints ausgefallen. Es gab wohl einen Hochspannungspuls auf dem RS485 Bus. Danach konnten die Batterieprints weder Daten senden, noch welche empfangen. Einen der Prints habe ich mittlerweile wiederbelebt und ein zweiter kann immerhin wieder Daten empfangen und lässt sich programmieren. Nur senden kann er noch nicht. Ich vermute im dortigen RS485 Transceiver-Chip (Typ: DS3695AM) ist der Sendekanal ausgefallen.

Außerdem hat's bei mir wohl auch den Wechselrichter erwischt. Er startet zwar sein Programm normal und baut auch das 12 V Netz auf, aber er gibt auf dem RS485 Bus keinen Mucks mehr von sich. Kannst Du mir sagen ob auch im Wechselrichter der RS485 Bus mit Optokopplern vom Rest der Schaltung entkoppelt ist? Dann wäre hoffentlich auch nur dieser Teil betroffen.

 

Viele Grüße,

 

Markus

Hallo TangoWhiskey-174,

Kannst Du vielleicht genau erklären' date=' was Du getan hast? [/quote']

 

Das will ich natürlich gerne versuchen.

Der Umrichter hat selbst keine optische Trennung der RS485 Busleitungen, doch ein Kopplerchip ICL485 auf der oberen Umrichterprint macht aus den beiden komplementären Busleitungen die Umsetzung auf jeweils eine getrennte Send- und eine Reciveleitung, die dann recht direkt in den Microcontroller auf dieser Platine gehen. Masse ist gemeinsam, aber für das Differenzssignal am Bus nicht entscheident. So funktioniert der ICL wohl als Trennverstärker und ist, zumindest in meinem Fall, als Sicherung gegen Überspannung am Bus gestorben. Der Microcontroller dahinter scheint nichts abbekommen zu haben und schickt immer noch brav auf seiner Send Leitung Signale raus (die durch den Defekt nur noch zur Hälfte auf eine Busleitung getrieben wurden).

 

Nach Einlöten eines neuen ICL485 [url=]http://at.rs-online.com/web/p/line-transceiver/5455455/[/url] habe ich wieder symetrische Bussignale vom Umrichter und ich kann mit einem Simulator jetzt auf die Nachrichten des Umrichters antworten. Meine Antwortnachrichten kommen auf der Recive Leitung zum MC an und sporadisch auch als Anzeige bis auf das Twike Display durch (mein Timing passt vermutlich noch nicht ganz).

 

Meine Batterieprints antworten dennoch nicht mehr, die sind wohl ebenso defekt. Aber egal, vorrangig gehe ich jetzt wieder den Energex Mediator an. Wenn das klappt und der die richtigen Antworten auf den Bus schickt, dann brauche ich die Battprints nicht mehr reparieren (sonst sind die dann aber immer noch Plan B, da ist dein Schaltplan auf jeden Fall interessant...)

 

Ich hoffe, du kannst damit was anfangen, viel Erfolg auch bei deiner weiteren Fehlersuche!

Hallo edriver01,

vielen Dank für die Information. Genau derselbe Chip war bei mir auch durchgebrannt. Ich habe ihn ersetzt und jetzt können die Batterieprints wieder vom Wechselrichter programmiert werden. Also vom Wechselrichter zu den Batterien funktioniert die Kommunikation schon mal. Ich werde in den nächsten Tagen prüfen, ob der Wechselrichter auch wieder Daten empfangen kann.

Die Werte für den seriellen Bus von Windows zum Twike lauten 2400 Baud, 8 Databits, 1 Stopbit, Non-Parity. Aber das steht im Energex Code ohnehin drin. Hast Du vom QtwikeAnalyzer ein Windows-Binary-File? Ich versuche seit einer Woche die QT Umgebung zum Laufen zu bringen, aber ohne Erfolg. Ich könnte die EXE-Datei gut brauchen.

Du hattest auf die online-Auktion mit dem Woods Wechselrichter hingewiesen. Bist Du sicher, dass das der richtige ist? Die Dinger gab’s mit 3, 5 10 und 15 PS. Wobei 10 und 15 PS viel größere Gehäuse haben, als diejenigen, die im Twike verbaut sind. Bleiben also noch 3 PS und 5 PS. Von der Stromstärke her ist der 5 PS Wechselrichter eigentlich zu klein (der 3 PS aus der Auktion ist in jedem Fall zu klein). Aber vielleicht verstand Woods unter "Stromstärke" ja den Dauerstrom, wobei der Kurzzeitstrom auch mal höher sein darf. In diesem FAll wäre der 5 PS Wechselrichter passend.

Anbei sende ich schon mal den Schaltplan der Batterieprints, soweit ich ihn aufröseln konnte. Ich verstehe aber nichts von Elektronik und kann für nichts garantieren, Wenn also irgendwer offensichtliche Fehler entdeckt, bitte bei mir melden.

 

http://www.123upload.de/image.php?id=662c40a9847ed51a0a672bc8cf2512ea

 

Markus

 

P.S. Wie kann man hier eigentlich Bilder einstellen? Muss der Admin dazu was freischalten?

Hallo edriver01,

wie so oft: die gute und die schlechte Nachricht..... Die gute Nachricht ist, dass der Kommunikation in meinem Twike wieder läuft. Alle Bus-Teilnehmer können wieder Daten untereinander austauschen. Die schlechte Nachricht ist, dass der Wechselrichter offenbar Fehler auf dem Bus erzeugt.

Wenn ich nur die Batterieprints angeschlossen habe kommen die Daten über die Spannungen und die Temperaturen sehr rasch und hintereinander auf dem PC an. Aber sobald der Wechselrichter in Betrieb geht, kommen die Daten deutlich langsamer an und es gibt Aussetzer. Wenn ich mit dem Twike fahre, fällt es alle 2 Minuten mit dem Fehler 21 "Kommunikationsfehler" aus und muss neu gestartet werden. Sieht mir ganz so aus als wäre mein Fehler ganz ähnlich wie Deiner. Bist Du bei Deiner Fehleranalyse schon weitergekommen?

Ich versuche übrigens immer noch ENERGEX zu kompilieren, bislang erfolglos. Der Kompiler gibt mir ständig neue Fehlermeldungen. Bis Du da schon weiter?

 

Viele Grüße,

 

Markus

Hallo Tango Whiskey

 

Was ist denn die Fehlermeldung beim Compilieren? Mediator oder QTwikeAnalyzer?

Übrigens, damit die Mediator SW zuverlässig mit dem Umrichter kommuniziert, muss auf dem Umrichter die Version 5.3 (oder 6.3 für 3x3 Motor) vorhanden sein.

 

Weiterhin viel Erfolg beim Nachbau. Neben meinem TW214 fährt jetzt übrigens ein zweites Energex Twike mit 120LiFePO4 rum :D.

 

Gruss, Markus

Hallo HB9XCG,

es wäre schon viel gewonnen, wenn im Energex Projekt stünde mit welchen Versionen von QT, qwt, mingw und qexserialport das ganze gebaut wurde. Mit den aktuellen Versionen sind alleine im Modul QTwikeAnalyzer knapp 40 Änderungen am Code nötig, bis schließlich der Linker die Libraries von qexserialport doch nicht findet. Es kommt so eine Fehlermeldung wie "cannot find -lqextserialport". Ich werde jetzt nochmal ganz von vorne beginnen und die dabei die QT Version 4.7 einsetzen zusammen mit älteren Versionen von qwt und qextserialport.

Ich bin derzeit vor allem am QTwikeAnalyzer interessiert, weil ich ihn verwenden möchte, um möglichen Hardwarefehlern am Bus auf die Spur zu kommen. In der Folge möchte ich dann auch die Energex Hardware nachbauen.

Aber damit die Diskussion hier nicht zu sehr off topic wird, können wir das gerne per PN fortsetzen (m.guetlich[AT]web.de). Ich würde mich freuen von Dir zu hören.

 

Viele Grüße,

 

Markus

Hallo Markus,

 

schön daß du auch wieder Zeit für dieses Forum hast.

Übrigens, damit die Mediator SW zuverlässig mit dem Umrichter kommuniziert, muss auf dem Umrichter die Version 5.3 (oder 6.3 für 3x3 Motor) vorhanden sein.

Ich habe leider nur Version 5.25, weiß jemand, ob die Kommunikation zu den Batterien da umfangreicher war als bei V5.3? Ich bekomme vom Umrichter der Reihe nach die verschiedensten zusätzlichen Adressen angefragt, für die ich keine Antworten im Mediator Code protocol.c entdecke.

 

Darauf folgt dann auch bei mir nach etwa 2 Minuten immer F21 Kommunikation Error (gelegentlich auch F28- falsche Batt. SW Version)

Leider zieht sich's bei mir etwas, auf jedes gelöste Problem folgt wohl eine neuen Herausforderung...

Hallo Tango Whiskey

 

Normalerweise empfehle ich den Leuten einfach eine One-Click Installation auf einem OpenSuSE z.B. 12.3: [url=]http://software.opensuse.org/ymp/home:XCG/openSUSE_12.3/QTwikeAnalyzer.ymp?base=openSUSE%3A12.3&query=QTwikeAnalyzer[/url]) Dann werden alle Abhängigkeiten zu den Bibliotheken automatisch aufgelöst.

Aber wenn sich schon mal jemand, der ein Windows zur Hand hat, die Mühe nimmt, die Sache dort zu kompilieren, ist das natürlich auch schön.

 

Also zu den Versionen: Qt 4.x.x, QWT 6.x.x, qexserialport 1.2.x (ich habe hier ein alpha-snapshot aus dem Repository), gcc 4.x.x sollte passen. Minqw kannst du ja denjenigen vom aktuellen QtCreator nehmen.

 

Auf Qt 5 habe ich es noch nicht probiert. Ich warte da mal, bis das bei den Linux Distributoren eingepflegt ist. Theoretisch sollte es einfach gehen. Dann wird nach entsprechender Anpassung auch die qextserialport überflüssig werden, da Qt 5 etwas entsprechendes enthalten wird.

 

Zu deinem Linker Problem: Ja die qextserialport Bibliothek musst du wie die QWT Bibliothek separat builden und dann dazulinken. Wenn du QTwikeAnalyzer compilieren konntest, hast du sie ja scheinbar schon heruntergeladen und den Includepfad richtig gesetzt. Im QTwikeAnalyzer.pro file die Bibliothek von LIBS += -lqextserialport auf LIBS += c:/qextserialport/qextserialport.lib o.ä. ändern oder die Bibliothek in den Standardsuchpfad installieren.

 

Viel Erfolg, Markus

 

 

 

 

Hallo edriver

 

Das erwähnte LiFePo4 Twike hatte auch die Version 5.25. Der Ladeprozess hat dann aber erst mit der Version 5.3 richtig funktioniert.

 

Wenn du unbedingt mit der 5.25er Version testen willst, musst du in battery.c:250 und battery.c:251 die PROGRAM_REV und die PAR_TAB_REV von 630 auf 525 ändern.

 

Hast du ein EPROM Brenngerät zur Verfügung?

 

Gruss, Markus