Hallo Leute! Ich brauche Eure Hilfe Bei der seriellen Kommunikation zweier Geräte gibt es manchmal (!) Probleme. Drum denke ich über einen Daten-Sniffer/Logger nach, finde aber nicht den richtigen Ansatz. Zum Problem. Zwei Geräte von 2 Herstellern reden über Frage/Antwort-Spiel über RS232 miteinander. Manchmal versteht der Slave aber scheinbar den Master nicht richtig und der Master wartet nun ewig auf die Antwort des Slaves - sprich die Kommunikation ist im Eimer. Einziger Behelf bisher: Reset des Masters, damit er die ausstehende Antwort des Slaves vergisst. Das kann aber keine Lösung sein. Meine bisherigen Analysen: - Master sendet per Bit-Banging mittels Z80 mit 1200,8n1 - Slave empfängt per UART auf einem STM32 (ARM) Die Vermutung, das das Bit-Banging des Masters das eigentliche Problem ist, scheint plausibel, da die Bit-Breite teilweise schwankt. Master-Hersteller: Nö, das kann nicht sein - das läuft ja seit Jahren bei x Kunden. Slave-Hersteller: An uns kann es nicht liegen, funktioniert ja weltweit. Toll! Nun würde ich da gern einen Sniffer/SD-Card-Logger in die Anlage mit einbauen bauen um den Herstellern etwas unter die Nase halten zu können. Bisheriger Ansatz: Rx und Tx-Leitung müssten mit min. 24kHz (20x 1200Baud) abgetastet werden um die schwankende Bitbreite deutlich zu machen. Die Daten müssten in einer Art Ringspeicher (32kB?) permanent mitgeschrieben werden. Wenn die Kommunikation zum Erliegen kommt (Timeout), dann Ringspeicher auslesen und mit Zeitstempel auf SD-Card schreiben. Die Realisierung stellt mich aber vor Probleme. Wie gehe ich da ran? (Oder gibt es dafür eventuelle etwas fertiges?) Z.Z. fällt mir nur ein TTL-Grab ein. - Taktgenerator (min. 24kHz) betreibt einen Adresszähler - SRam liest die Zustände der Rx/Tx-Leitung ein - jedes Gezappel auf Rx oder Tx setzt ein Monoflop zurück - sollte Monoflop auslösen, so gab es ein Timeout und Taktgenerator stopt - µC kann nun SRAM auslesen und die Daten mit Zeitstempel aus einer I2C-RTC auf SD-Card schreiben. Mit AVR-µC's habe ich schon etwas rumgespielt, aber nie etwas Ernstes gemacht - Schaltung aufbauen, PCB herstellen und SMD-Löten ist kein Problem - Programmierung aber. Notfalls kann ich aber den Entwickler bei uns in der Firma damit belästigen. Dazu muss aber das Konzept erstmal stehen und durchdacht sein. Ich möchte nicht mit halbgaren Ideen für Unruhe sorgen. Dazu brauche ich aber erstmal einen Realisierungs-Ansatz. Könnt Ihr mir da etwas auf die Sprünge helfen? Gruss...Peter
Peter S. schrieb: > Könnt Ihr mir da etwas auf die Sprünge helfen? Einen Protokoll-Analysator kaufen. Peter S. schrieb: > Z.Z. fällt mir nur ein TTL-Grab ein. Wieso das denn, das schafft ein µController doch leicht. Georg
Peter S. schrieb: > Master-Hersteller: > Nö, das kann nicht sein - das läuft ja seit Jahren bei x Kunden. Wer baut denn eine Protokoll-Implementierung, die keine Timeouts verwendet und bei dessen Auftreten einfach nochmal versucht... Selbst bei perfekter UART-Umsetzung auf beiden Seiten kann es ja wegen Störungen zu Nachrichten-Verlusten kommen, daher sind Prüfsummen und Timeout/Retry onehin Pflicht. Das könnt ihr dem Hersteller vielleicht ja mal erklären, vielleicht ist es bei euch ja ein solches Hardware-Problem... Wie wäre es mit Data Acquisition Systemen wie von NI o.ä.? Die sind doch dafür gemacht, mit wenig Aufwand derartige Messungen durchzuführen. Manche Oszilloskope können bei niedriger Abtastrate auch kontinuierlich an den PC schicken, damit der speichert. Peter S. schrieb: > Bisheriger Ansatz: Viel zu kompliziert... Wenn du es wirklich selber basteln willst: Ein STM32F4 beispielsweise hat 192 KB internen SRAM. Da kannst du einfach per Software ständig reinschreiben, mithilfe des internen Timers den Ausfall der Kommunikation feststellen, und in diesem Fall auf eine SD-Karte schreiben, oder die Daten einfach im RAM behalten bis sie jemand per UART->PC ausliest. Eine RTC brauchts überhaupt nicht, du kannst dazu die Timer des Mikrocontrollers nehmen. Der STM32F4 hätte aber auch eine RTC eingebaut. Im Endeffekt brauchts also nicht mehr als den Controller.
Es gibt btw auch die Möglichkeit per Computer und 2 seriellen Schnittstellen dazwischen zu hängen. Software wie Docklight sollte sowas können. Benutzen unsere Servicetechniker hin und wieder. Evtl gibts auch was freies. Ansonsten kann man auch mit Python oder einer anderen Scriptsprache schnell was machen.
Hallo in die Runde! Erstmal Danke für die Antworten. Ich habe Euch gestern (23:45) die Hälfte des Problems unterschlagen, weil ich dachte, das sei nicht so wichtig. Sorry! Also hier mal die ganze Geschichte. Die Geräte (Master+Slave) sind teil einer vollautomatischen BetriebsTankanlage bei einem Bauern. -> also outdoor -> keine Möglichkeit da einen PC oder Oszi daneben zu stellen -> da unweit der Autobahn, können da auch LKW's 24/7 tanken -> meine Firma hat die Geräte hingestellt und ist für Wartung zuständig -> beide Hersteller haben schon ihre Rechner getauscht -> Altgeräte eingeschickt -> jeder Hersteller sagt "Alles io! An uns kann's nicht liegen!" -> im Log-File des Masters steht "Start Entnahme" -> und danach steht alles, da er wohl auf das Ende der Tankung wartet -> Wieviel da getankt wurde, oder ob es erst nicht dazu kam ist unbekannt. Entweder hat der Master etwas falsch geschickt, oder die Tanksäule hat es nicht verstanden. Und genau diesen Zustand würde ich gern sichtbar machen. Das serielle Protokoll nennt sich ER3 (falls das jemandem etwas sagt). Wie die Kommunikation da genau abläuft ist geheim. :-( (Tante Google schweigt sich da aus.) Mir ist nur bekannt, das es mit 1200,8n1 läuft. Im Netz habe ich HTerm gefunden, aber da ist alles rot -> fehlerhafte Kommunikation. (Oder ist das normal, weil ER3 eben kein 232-Standard ist??) Sicher gibt es da irgendwelche Prüfsummen, aber da ich keine Unterlagen zum Protokoll habe (und wohl auch nie zu Gesicht bekommen werde) kann ich nur jeden Flankenwechsel auf der Datenleitung so hochauflösend wie nötig/möglich mitschreiben und z.B. auf SD-Card schreiben. Die gesammelten Daten will ich dann den beiden Herstellern in die Hand drücken, damit die dann etwas zum analysieren haben. Wie oft passiert es, das nichts mehr geht? Der erste Ausfall war nach 5 Wochen, der 2., 3. und 4. im Abstand von ~2 Wochen. Im Schnitt tanken bei dem Bauern etwa 40-50 LKW's auf 2 Spuren pro Tag. Die Ausfällige Spur ist die neue 3. Spur, um den teilweisen Rückstau zu verhindern. Der Bauer ist zum Glück ein recht gemütlicher Mensch, aber er erwartet Fortschritte um den Fehler zu beheben. Soviel zum Drumherum. - ja, es muss ein µC und kein PC sein - jeder Flankenwechsel muss dokumentiert werden - normale serielle Schnittstelle funktioniert nicht - 1200Baud = 1,2kHz (richtig?) - Abtastung mit min. dem 20-fachem (also 24kHz) um Bitbreitenfehler zu finden - da wird der Speicher IM µC schnell eng - drum auslagern auf SD-Card - Datenaufkommen sehr gering (Master an Slave = "Lege los mit Preis X,YZ" nach x Minuten Slave an Master "xxxLiter, habe fertig") - darum die Idee mit RTC-Zeitstempel die Pakete abzulegen Aber wie und womit? Für jegliche Ideen bin ich sehr dankbar. Gruss... Peter
Interessant! Wenn das Problem allerdings so schwierig und verzwickt ist, würde ich sehr wohl in eine PC + Logikanalysator Lösung investieren. Wenn du es nirgendwo unterbringen kannst, lohnt sich vermutlich auch ein temporärer "Schrank" daneben. Das eigentliche Messen sollte mit einem dieser Geräte kein Problem sein: www.saleae.com Falls doch einer der Hersteller schuld ist, könnt ihr eventuell sogar die Kosten abwälzen. Am teuersten ist wohl sowieso eure Arbeitszeit. Gruß Max
Hallo Max! Danke für Deine Antwort. Die Tankanlage ist vollkommen autonom und ohne jegliche menschliches Personal. Die Tankkunden halten ihren RFID-Chip an den Automaten und tanken dann. Abrechnung monatlich per Lastschrift. Ein PC mit Logic-Analyser ist also nicht machbar, da keiner da ist, der den LA auswertet bzw. neu startet. Im Grunde gebe ich Dir jedoch Recht. Es läuft also auf einen autonomen LA mit Log-Funktion hinaus. Gibt es sowas käuflich? Jegliche Datenlogger, die ich bis jetzt gesehen/gefunden habe können die angestrebten 24kHz nicht, oder haben zu wenig Speicher um bis zum nächsten Ausfall durchlaufen zu können. Gruss... Peter PS: Mit LA und PC habe ich schon zusammen gerechnet 2h da gehockt. Der Fehler trat dann aber nicht auf. :-( Sehr frustrierend!
:
Bearbeitet durch User
Hallo, 1. ER3 ist eine Schnittstelle von Kienzle. 2. Dass das Problem durch zeitlich verschobene Flanken verursacht wird, ist nur eine Vermutung mit, meiner Ansicht nach, eher geringer Wahrscheinlichkeit. Und selbst wenn, i.d.R. zeigen sich die Auswirkungen eines solchen Fehlers erst zu einem ganz anderen Zeitpunkt, der Zusammenhang ist schwer herzustellen, auch für die anderen Beteiligten. Wahrscheinlich endet das ganze wie das berühmte Hornberger Schiessen. 3. Für Schnittstellen gilt im besonderen der Satz Shit happens, es muss daher jede Übertragung gesichert sein gegen Übertragungsfehler und Timeouts, das was du beschreibst darf also ohne Fehlermeldung überhaupt nicht passieren. Andrerseits glaube ich eigentlich nicht, dass erfahrene Firmen so einfache Regeln nicht beachtet haben. 4. Bei solchen Zeiträumen (Wochen) müsste ein Protokollanalysator auf das Auftreten des Fehlers getriggert werden und die Aufzeichnung beenden. Ohne Verständnis der ausgetauschten Daten halte ich das für kaum machbar, egal ob gekauft oder gebastelt. Wie soll sich denn der Zustand "Anlage reagiert nicht mehr" vom Zustand "es tankt keiner" unterscheiden, wenn man nur Flanken zählt? Das geht nur wenn man das Protokoll versteht, dann kann man einen PA so programmieren. Du musst auch bei einer eigenen Lösung den Fehler automatisch erkennen, sonst steht die Anlage, aber dein Sniffer läuft weiter, und bis du nach ein paar Stunden kommst ist nichts mehr im Speicher. Du müsstest sonst schon 10 Wochen oder so komplett aufzeichnen und auswerten. Wenn ich micht nicht verrechnet habe landest du da im TByte-Bereich. Georg
Georg schrieb: > Hallo, Hallo Georg! > 1. ER3 ist eine Schnittstelle von Kienzle. Richtig! Der Rechner in der Säule stammt aber von einer anderen Firma, die das Protokoll in Lizenz integriert hat. Vom Hersteller habe ich aber keine brauchbare Informationen erhalten - weil ER3 "geheim" ist (einen Blackbox-Protokollsniffer konnte er mir auch nicht geben -> also selber bauen). > 2. Dass das Problem durch zeitlich verschobene Flanken verursacht wird, > ist nur eine Vermutung mit, meiner Ansicht nach, eher geringer > Wahrscheinlichkeit. Naja, zur Zeit meine einzige Hoffnung und Ansatzpunkt. > Und selbst wenn, i.d.R. zeigen sich die Auswirkungen > eines solchen Fehlers erst zu einem ganz anderen Zeitpunkt, der > Zusammenhang ist schwer herzustellen, auch für die anderen Beteiligten. > Wahrscheinlich endet das ganze wie das berühmte Hornberger Schiessen. Deshalb ja auch der Versuch so viel wie möglich aufzuzeichnen. Vielleicht kommt es ja relativ häufig zu Fehlern, die von den Anlagen aber erkannt und ausgebügelt werden können. > 3. Für Schnittstellen gilt im besonderen der Satz Shit happens, es muss > daher jede Übertragung gesichert sein gegen Übertragungsfehler und > Timeouts, das was du beschreibst darf also ohne Fehlermeldung überhaupt > nicht passieren. Andrerseits glaube ich eigentlich nicht, dass erfahrene > Firmen so einfache Regeln nicht beachtet haben. So die Theorie. Die Realität zeigt aber, das der Tankautomat (=Master) einen Tankbeginn geloggt hat. Die Säule steht stumm ohne jegliche Fehlermeldung da. Das Kabel zwischen beiden ist nicht länger als 6m und ist durchgemessen. Einen Zusammenhang von Fehler zu Witterung (Regen oder pralle Sonne) konnte bis jetzt auch nicht hergestellt werden. > 4. Bei solchen Zeiträumen (Wochen) müsste ein Protokollanalysator auf > das Auftreten des Fehlers getriggert werden und die Aufzeichnung > beenden. Ohne Verständnis der ausgetauschten Daten halte ich das für > kaum machbar, egal ob gekauft oder gebastelt. Wie soll sich denn der > Zustand "Anlage reagiert nicht mehr" vom Zustand "es tankt keiner" > unterscheiden, wenn man nur Flanken zählt? Das geht nur wenn man das > Protokoll versteht, dann kann man einen LA so programmieren. Missverständnis: Ich möchte die Flanken nicht zählen, sondern Aufzeichenen - ohne jeglichen Versuch die Daten zu deuten. Die Analyse überlasse ich denen, die sich damit auskennen - also den Herstellern. > Du musst auch bei einer eigenen Lösung den Fehler automatisch erkennen, > sonst steht die Anlage, aber dein Sniffer läuft weiter, und bis du nach > ein paar Stunden kommst ist nichts mehr im Speicher. Du müsstest sonst > schon 10 Wochen oder so komplett aufzeichnen und auswerten. Wenn ich > micht nicht verrechnet habe landest du da im TByte-Bereich. > > Georg Und genau deshalb will ich ja nur die Flankenwechsel bzw. deren Pakete aufzeichnen. Wenn keine Kommunikation läuft, dann wird auch nix aufgezeichnet. Irgendwo in den letzten aufgezeichneten Datenpaketen muss der Fehler liegen - so meine Hoffnung. Die Datenpakete sind nie länger als ~5-6s (bis jetzt habe ich jedenfalls nichts längeres gesehen). Es müßte also pro Start der Datenpakete der Zeitstempel mit abgelegt werden. Die Zeit, in der keine Kommunikation läuft, könnte somit ausgeblendet werden. Aber das automatisiert zu gestalten ist eben das Problem (für mich). Gruß... Peter
Georg schrieb: > Du müsstest sonst > schon 10 Wochen oder so komplett aufzeichnen und auswerten. Wenn ich > micht nicht verrechnet habe landest du da im TByte-Bereich. Na ja, so ein kleiner LA von Saleae liefert trotz einer Abtastrate von mehreren MHz (max. 24) nur wenige kByte, wenn sich am Eingang nichts tut. Es zwingt einen doch keiner, die Langweiligkeit des Warten Bit für Bit einzeln in Form von Endlosen Kolonnen von 0en auf den Massenspreicher zu schieben. Und 6 Mio Sekunden, ist nun nicht so unendlich lang. Trotzdem würden man wohl gerne einen Event-Trigger haben und lieber eine Serie von kürzeren Aufzeichnungen machen, damit das Ganze handhabbar bleibt.
Wie wäre es damit die Verdrahtung einfach zu verbessern: Auf beiden Seiten einfach RS485-Transceiver dazwischen schalten und somit eine differentielle Übertragung verwenden und ein gutes geschirmtes Kabel mit 2 Twisted-Pairs. Vielleicht löst sich das Problem so schon ohne endlose Analysiererei.
Programmierer schrieb: > Vielleicht löst sich das Problem so schon ohne endlose > Analysiererei. Den Herren der beteiligten Firmen sollte man trotzdem mal bezüglich ihrer Error Recovery Strategien in der Software auf die Finger klopfen und dabei auf eine handfest, stichhaltige Antwort pochen.
Erst hatte ich dieses gelesen: Peter S. schrieb: > Die Geräte (Master+Slave) sind teil einer vollautomatischen > BetriebsTankanlage bei einem Bauern. Dann erinnerte ich mich an das: Peter S. schrieb: > Meine bisherigen Analysen: > - Master sendet per Bit-Banging mittels Z80 mit 1200,8n1 Beim Stichwort "Bauer" ist mein nächster Geanke immer: schlechte Stromversorgung, weggegammelter Schutzleiter, starke Spannungsschwankungen beim Schalten grosser Verbraucher. Wenn beim Z80 die Betriebsspannung von 5V einbricht ohne auf 0V zu gehen, dann bleibt der einfach stehen. Stichwort Brown out. Einer meiner Kunden hatte das Problem in asiatischen Ländern mit schlechter Stromversorgung. Abhilfe schaffte der Einsatz einer Reset-Beschaltung mit TL7705.
Hallo Peter! Du hast da schon zwei Stunden vorgesessen? Das ist ja sehr ärgerlich. Teurer Spaß, bestätigt mich allerdings in meiner Idee ;-) Peter S. schrieb: > Ein PC mit Logic-Analyser ist also nicht machbar, da keiner da ist, der > den LA auswertet bzw. neu startet. Eben doch! Die Produkt von Saleae sampeln einfach fröhlich so lange, wie du eingestellt hast oder dein Arbeitsspeicher ausreicht. Die digitalen Signale werden komprimiert, du kannst also sehr (!!!) lange sampeln. Die von dir benötigte Samplerate ist ebenfalls überhaupt kein Problem. Du lässt das Teil einfach laufen und guckst dir das Ergebnis an, nachdem der Fehler aufgetreten ist. Hier ein Artikel der passen könnte: http://support.saleae.com/hc/en-us/articles/200591395-I-need-to-take-really-long-captures-hours-to-days-What-is-the-best-way-to-do-this- Ansonsten ist der Support immer sehr fix und hilfsbereit! Gruß Max
Was mir da noch eingefallen ist: Rüste den PC mit einer UMTS-Karte/Stick aus, dann kannst du auch aus der Ferne darauf zugreifen, die Daten analysieren, neu starten oder was auch immer. Gruß Max
Das spricht von Inkompetenz. Er3 ist ein 12V/25mA current loop Protokoll. Wenn da kein Protokoll Konverter zwischengeschaltet Oder bei der Erweiterung von zwei auf 3 Tankstellen gepfuscht wurde, Sind Fehle vorprogrammiert.
Hallo Mitstreiter! Heute ist es nach ~2,5 Wochen wieder passiert. Grrrrrrrrr!!! :-( Aber trotzdem DICKES DANKE an Euch alle! Das gibt mir irgendwie Hoffnung. :-) @Max B. Deine Idee mit dem LA + PC ist meinem Chef (Zugegeben... geile Geräte! Hatte das mit der "Endlos"-Aufzeichnung erst nicht gerafft.) A: Zu teuer! B: "Wir haben alles so gemacht wie sonst auch!" "Wir haben uns nix vorzuwerfen!" "Das kann nicht unser Problem sein!" etc. Ne Lösung ist das aber trotzdem nicht. :-( @Tom Die Stromversorgung scheint nicht das Problem zu sein. Die beiden anderen Säulen laufen ohne dieses Probleme. Der Tankautomat selbst hat ein LCD und da läuft die Zeit fröhlich weiter. Der Service-Techniker von der Automaten-Firma hat mir auch versichert, das der Automat selber eine ext. Watch-Dog-Schaltung hat, aber der Automat keinen Reboot protokolliert hat. @Programmierer Die Verdrahtung ist wie bei den anderen beiden Säuelen - geschirmtes, ölfestes Erdkabel. Daran sollte es also nicht liegen. Da der Fehler bei irgendwo 1% der Tankungen auftritt, denke ich, das Fehler nicht beim Übertragungsmedium sondern beim Protokoll liegt. @Chris Beim Mitschneiden per PC bin ich mit nem TTL-232-Wandler an die Pin's der Optokopplern im Säulenrechner rangegangen (Für den Tankautomat habe ich leider keinen Schlüssel - für die Säule aber schon) :-). Die Leitung zwischen Tankautomat und Säule habe ich also nicht angezapft/verfälscht. So, zurück zum Thema "2-Kanal-Datensniffer/Logger" Ich habe nochmal meine e-Rumpelkammer durchforstet und bin auf ein Olimexino-STM32 gestoßen (damit wollte ich mal C für µC's lernen und dann kam "...schwanger..."). Auf dem Schlepptop habe ich auch die "Mpale-IDE" gefunden (eine Arduino-Version für STM32-µC's von www.Leaflabs.com) Das Olimexino-STm32-Board hat einen STM32F103RB mit 72Mhz drauf und zusätzlich auch noch einen µSD-Card-Slot. Bink-Test-, SD-Test-, Timer-Interrupt- und ext-Interrupt-Testprogramm funktionieren - ach ja die unbesch(w)erten Zeiten. Hardware zum Loggen ist also vorhanden. Im SäulenRechner habe ich auch 2 3mm-LED's gefunden, die in der Stromschleife zwischen Tankautomat und Säulenrechner hängen. Jedes gesendete und empfangene Bit wird da angezeigt. Da will ich mit 2 Fototransis (also eine Art Optokoppler) und Schrumpfschlauch ran. Da kann mir keiner vorwerfen, ich hätte die Übertragung durch meine Schaltung verfälscht. Jetzt die Frage welcher Weg ist zum Loggen der 1200Baud besser? Version A: Per Timer-Interrupt wird permanet auf 1/20 der Bitbreite der Zustand der Sende und Empfangsleitung abgefragt (also polling). Gibt es eine Änderung, dann wird nur diese geloggt. Jetzt startet ein Zähler per Timer-Interrupt und beim nächsten Zustandswechsel wird die Zeit zwischen den Änderungen und der neue Zustand der Leitung geloggt. Version B: Beide Rx/Tx-LED's werden per ext. Interrupt überwacht und auch hier nur der Status der entsprechenden LED und die Zeit zwischen deren Zustandsänderungen geloggt. Unterm Strich sollte das Gleiche auf der SD-Card zu finden sein. Z.Bsp.: "Rx-High";890µs;"Rx-Low";1234µs;"Tx-High" etc. Daraus kann dann vom µC eine CSV-Datei für die 2 Leitungen erzeugt werden, die dann wiederum von beiden Herstellern in Exel-Dateien umgewandelt werden. Wäre das ein brauchbarer Ansatz? Oder verrenne ich mich da grad? Gruss...Peter
Ich wuerde im 20 uS Intervall Pollen. Worst case kommen dann 2GB Daten je Woche zusammen. Temperatur würde ich auch mitloggen. Es wundert mich aber dass uebertrahungsfehler mit hterm auftreten. Protokoll ist ohne checksum, es werden die Daten so über tragen: D ~D C ~C B ~B A ~A
Peter S. schrieb: > Deine Idee mit dem LA + PC ist meinem Chef (Zugegeben... geile Geräte! > Hatte das mit der "Endlos"-Aufzeichnung erst nicht gerafft.) > > A: Zu teuer! > B: "Wir haben alles so gemacht wie sonst auch!" "Wir haben uns nix > vorzuwerfen!" "Das kann nicht unser Problem sein!" etc. > > Ne Lösung ist das aber trotzdem nicht. :-( A: Du kannst ja mal aufschreiben was diese Fehleinschätzung deinen Chef am Ende gekostet hat ;-) B: Wenn ihr diejenigen seid die das ausbaden müssen ist das doch völlig egal. Zudem würde ich die kosten eiskalt an den Verursacher weiterreichen. Tut mir Leid für dich! Ich drücke die Daumen und halt uns auf dem Laufenden! LEDs klingen ja schonmal vielversprechend. Gruß Max
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.