Hallo zusammen, ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das ganze mit CAT5 Kabel verdrahten. Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P < 1W. Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves (und damit auch die RS485 Transceiver) liegen dann um diese Spannung über dem GND des Masters. Nun meine Frage: Würdet ihr das trotzdem noch mit normalen RS485 Transceivern machen (laut Datenblatt müssen sie ja einen CM-Bereich von -7V bis +12V vertragen)? Oder wäre es sinnvoller auf galvanisch getrennte RS485 Slaves zu gehen (auf Kosten der Komplexität)? Viele Grüße, Manuel
Manuel R. schrieb: > Hallo zusammen, > > ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das > ganze mit CAT5 Kabel verdrahten. > > Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves > verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P < > 1W. > > Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen > mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves > (und damit auch die RS485 Transceiver) liegen dann um diese Spannung > über dem GND des Masters. > > Nun meine Frage: > Würdet ihr das trotzdem noch mit normalen RS485 Transceivern machen > (laut Datenblatt müssen sie ja einen CM-Bereich von -7V bis +12V > vertragen)? > > Oder wäre es sinnvoller auf galvanisch getrennte RS485 Slaves zu gehen > (auf Kosten der Komplexität)? > > Viele Grüße, > Manuel Je nach RS485 Transceivertyp sind üblicherweise Common Mode Spannungsabfälle bis zu +12 bis zu - 7V zulässig. Da machen Deine Stromversorgungsspannungsabfälle weitgehend nichts aus. Galvanische Trennung ist bestimmt nicht notwendig wenn Du innerhalb der vorgegebenen Grenzen bleibst. Siehe auch hier: https://ecee.colorado.edu/~mcclurel/max485ds.pdf "-7V to +12V Common-Mode Input Voltage Range" - Seite 1 Ausprobieren halt. Bevor ich es vergesse: Nimm einen Slew Rate begrenzten Transceiver wie den MAX483 o.ae. 10Mbit Transceiver machen nur Probleme.
:
Bearbeitet durch User
Manuel R. schrieb: > ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das > ganze mit CAT5 Kabel verdrahten. > Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves > verwenden (mit Step-Down an jedem Slave). Such dir eine Belegung aus, bei der der Netzwerktrafo deines Laptops nicht kaputtgeht, wenn du ihn mal zufällig an dieses "Netzwerk" anschließt. Denn das ist die Gefahr bei Buchsen, die weltweit vorrangig für eine ganz bestimmten Sache verwendet werden: keiner rechnet damit, dass da was ganz anderes rauskommen könnte. > Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen > mit Spannungsabfällen im Bereich 1-5V rechnen. Du solltest da übrigens unbedingt auch die vielen Übergangswiderstände in den vielen Steckverbindungen berücksichtigen...
Manuel R. schrieb: > Hallo zusammen, > > ich möchte für eine Hausautomatisierung auf RS485 zurückgreifen und das > ganze mit CAT5 Kabel verdrahten. > > Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves > verwenden (mit Step-Down an jedem Slave). Pro Slave rechne ich mit P < > 1W. > > Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen > mit Spannungsabfällen im Bereich 1-5V rechnen. D.h. die GNDs der Slaves > (und damit auch die RS485 Transceiver) liegen dann um diese Spannung > über dem GND des Masters. 1. Nimm 48V, wie es sonst überall (PoE, ISDN,...) gemacht wird. Damit kannst Du mehr Leistung übertragen, und die Verlustleitung viertelt sich. 2. Wenn Du Power GND und Signal GND trennst, hast Du das Problem nicht mehr. Signal GND ist die Referenz für den Bus, und hier wirst Du kaum nennenswerte Ströme haben. Und für die Stromversorgung nimmst Du isolierte DC-DC-Wandler. Exemplare mit Eingangsspannungen von 36-72V und Ausgangsspannung 5V gibts genügend. Der Spannungsabfall auf Power GND spielt dann keine große Rolle mehr. fchk
Ich würde für neue Projekte CAN bevorzugen. Der Master muß dann die Slaves nicht mehr pollen, sondern sie können antworten, wann ihnen danach ist. Die CAN-Hardware kümmert sich automatisch darum, daß Kollisionen aufgelöst und Fehler korrigiert werden. Die Firmware wird also erheblich einfacher und die Übertragung sicherer. Kämpfen 2 RS-485 Transceiver gegeneinander, können bei hohen Leitungswiderständen beide MCs der Meinung sein, daß sie erfolgreich gesendet haben.
fchk schrieb: > für die Stromversorgung nimmst Du isolierte DC-DC-Wandler. > Exemplare mit Eingangsspannungen von 36-72V und > Ausgangsspannung 5V gibts genügend. Durch den großen Eingangsspannungsbereich muss die zentrale Versorgung nicht geregelt sein. Ich würde wahrscheinlich Ringkerntrafo/Gleichrichter/Elko verwenden; hält 100 Jahre, im Gegensatz zu billigen Schaltnetzteilen. Bonus: wenn ein Step-Down defekt wird, kommen evt. 48 statt 5 Volt raus. Bei einem getrennten Wandler ist das eher unwahrscheinlich. Lothar M. schrieb: > Du solltest da übrigens unbedingt auch die vielen Übergangswiderstände > in den vielen Steckverbindungen berücksichtigen... Sooo viele sollten in einer Hausinstallation nicht vorkommen. Klar, einer pro Slave, aber da geht auch nur "ein Strom" drüber. Lothar M. schrieb: >> Die freien 4 Adern möchte ich für eine 24V Versorgung für die Slaves >> verwenden (mit Step-Down an jedem Slave). > Such dir eine Belegung aus, bei der der Netzwerktrafo deines Laptops > nicht kaputtgeht, wenn du ihn mal zufällig an dieses "Netzwerk" > anschließt. Wäre GND auf 7 und 8, Plus auf 4 und 5 in Ordnung? Peter D. schrieb: > Ich würde für neue Projekte CAN bevorzugen. Normale CAN-Tranceiver können nur -2 bis +7V common mode. Die SN65HVD233 schaffen -7 bis +12V und vertragen ±100V Transienten und Kurzschlüsse gegen 24V. Mit Kabeln quer durchs Haus ist das durchaus ein Argument. Das bringt uns zum SN65HVD1785, der verträgt auch Kurzschlüsse gegen 48V und kann -20 bis +25V common mode. Damit wäre die ursprüngliche Frage auch beantwortet.
:
Bearbeitet durch User
Bauform B. schrieb: > Das bringt uns zum SN65HVD1785, der verträgt auch Kurzschlüsse gegen 48V > und kann -20 bis +25V common mode. Damit wäre die ursprüngliche Frage > auch beantwortet. Da ja eh 5V vorhanden sind, kann man auch zu einem MAX13054 greifen, der +-80V an den Busleitungen verträgt. fchk
Bauform B. schrieb: > Normale CAN-Tranceiver können nur -2 bis +7V common mode. TJA1050: Common Mode: +/-12V Max: -27V/+40V, no time limit Transient: +/-200V ESD (HBM): +/-4000V An unpowered node does not disturb the bus lines. https://www.nxp.com/docs/en/data-sheet/TJA1050.pdf Manuel R. schrieb: > Trotz der hohen Versorgungsspannung muss ich bei meinen Leitungslängen > mit Spannungsabfällen im Bereich 1-5V rechnen. Sind also auch für CAN kein Problem.
Peter D. schrieb: > Der Master muß dann die > Slaves nicht mehr pollen, sondern sie können antworten, wann ihnen > danach ist. Das macht aber die Programmierung für einen Anfänger nicht unbedingt einfacher. Georg
georg schrieb: > Das macht aber die Programmierung für einen Anfänger nicht unbedingt > einfacher. Doch.
H.Joachim S. schrieb: > georg schrieb: >> Das macht aber die Programmierung für einen Anfänger nicht unbedingt >> einfacher. > > Doch. Nein, wirklich nicht. Zähl einfach mal die Bits, die im CAN-Controller richtig gesetzt werden müssen und vergleiche mit einem UART. Von der Beschreibung ganz abgesehen: welche 10% der Funktionen braucht man eigentlich? Allerdings verursacht CAN wesentlich weniger Umweltverschmutzung als Pollen, gerade in dieser Anwendung. Wie oft muss ein Lichtschalter sich melden? Und dann der Stromverbrauch: die Abschlusswiderstände brauchen bei RS-485 dauernd Strom, die bei CAN brauchen genauso viel, aber nur, wenn jemand sendet! Jedes Milliwatt zählt ;)
georg schrieb: > Das macht aber die Programmierung für einen Anfänger nicht unbedingt > einfacher. Der Master schickt z.B. 3 Anfragen an 3 Slaves. Und irgendwann hat er 3 Interrupts gekriegt und es stehen die 3 Antworten in 3 Empfangpuffern, ohne jedes Zutun. Er muß sie nur noch auswerten und die Empfangspuffer wieder freigeben. Sich mit Kollision, Timeout, Retry, CRC usw. rumärgern war gestern.
Zur ewigen Diskussion CAN versus RS485 - bei langen Leitungen die auch mal Stiche oder Stich am Stich verdrahtet sind, tut man sich mit slew rate limited RS485 viel leichter als mit CAN. Also in diesem Anwendungsfall ist kann schon RS485 besser geeignet sein. RS485 braucht im Gegensatz zu CAN keine niederohmigen Abschlusswiderstände. Die hochohmigen in den Treibern bzw. zusätzlich einer irgendwo, reichen. Bei RS485 kann man auch je nach belieben extern noch die slew rate verringern um auch bei mega lange Leitungen und Abzweigen keine nennenswerten Reflexionen zu bekommen. Wer mal versucht hat bei CAN die slew rate extern einzustellen weiß, dass geht nicht gut mit den niederohmigen CAN Abschlusswiderständen. Und CAN Treiber mit slew rate Einstellung sind leider sehr selten. @Manuel R. - ich weiß nicht wie du auf die 1-5V Spannungsabfall kommst. Aber da würd ich mir mit RS485 keine Sorgen machen. Die -7 - +12V die reichen da. Mehr wäre natürlich gut. Die vorgeschlagenen Alternativbausteine mit höherem CM würde ich mir auf jeden Fall ansehen. Als Belegung würde ich 1/2 und 6/8 für die Versorgungsleitungen nehmen und 4/5 für RS485. Wenn du auf "fälschlich LAN anstecken" keine Rücksicht nehmen musst, kannst auch 1-3 und 5-8 für die Versorgung nehmen. Die Anzahl deiner Teilnehmer und warum die nicht viel weniger als 1W brauchen sollen, wären auch noch interessant.
Peter D. schrieb: > Der Master schickt z.B. 3 Anfragen an 3 Slaves Das ist ja auch nicht das Problem, das ist genauso Master-Slave wie bei RS485 usw. Aber er muss ja auch jederzeit auf Messages reagieren die er nicht veranlasst hat - jedenfalls theoretisch. Georg
Bauform B. schrieb: > Ich würde wahrscheinlich > Ringkerntrafo/Gleichrichter/Elko verwenden; hält 100 Jahre, im Gegensatz > zu billigen Schaltnetzteilen. Das ist ein bisschen schwer auf eine Hutschiene zu bekommen wie sie gerne bei Hausinstallationen genommen werden. Innerhalb von 100 Jahren wird bei den heutigen Elkos auch der ein oder andere Elko-Wechsel fällig. Das Netzteil muss ja nur ähnlich lang halten wie der Rest der RS485 Haussteuerung. Der gebe ich keine 100 Jahre. Daher würde ich mir ein Hutschienen-Schaltnetzteil aussuchen. Wenn es nicht zu teuer sein soll was passendes von MeanWell. Die haben eine ziemlich breite Auswahl und sind nicht ganz schlecht.
Ich hab einen 25kbit CAN schon über 400m und mit >über 150m Stichleitungen aufgebaut. Überhaupt kein Problem.
CAN_Nutzer schrieb: > Ich hab einen 25kbit CAN schon über 400m und mit >über 150m > Stichleitungen aufgebaut. Überhaupt kein Problem. 400m und >150m StichleitungEN? Kannst du das mal aufzeichnen? Wenn du in deinem speziellen Aufbau "kein Problem" mit Reflexionen hattest, bzw. diese vielleicht gar nicht an den entsprechenden Stellen gemessen hast, hilft das dem TO wahrscheinlich nicht viel. Das Stichleitungen mit den bei CAN obligatorischen Abschlusswiderständen am Anfang und am Ende nicht gut zusammengehen, sollte dir schon klar sein, oder? Aber vielleicht hat ja der TO diese gar nicht....
250m Hauptleitung vom Master zum letzten Sensor, dazwischen 10 Abzweigungen mit je 15m zur Hauptleitung. Terminiert war der Master und der letzte Slave. Die Buslast war nie über 15%, aber mehr ist bei Hausautomatisierung auch nicht zu erwarten
@Andi B. Ich rechne mit < 10 Teilnehmern. Die Last ist so klein, weil es meist nur Sensoren etc. sind. Der Spannungsabfall ergibt sich aus dem DC Widerstand der Leitung und Übergangswiderständen. @alle Danke für die zahlreichen Tipps, wie immer sehr hilfreich. Da ich kein Multimaster plane, bleibe ich lieber bei RS485. Das mit dem Stromverbrauch durch den Nullpegel ist tatsächlich ein Punkt (hat mich überrascht, als ich das bei der ersten Inbetriebnahme gesehen habe). Um das zu vermeiden plane ich die Transmitter bei Inaktkvität ausschalten, damit ist es dann vergleichbar zu CAN. Oder spricht da etwas dagegen? Noch eine Frage zum Thema Stichleitungen. Wieviel Meter sind bei 115kbit/s und slew rate Limitierung denn akzeptabel? Viele Grüße, Manuel
Bauform B. schrieb: > Zähl einfach mal die Bits, die im CAN-Controller > richtig gesetzt werden müssen und vergleiche mit einem UART. Nur ist eine UART einfach nur ein Schieberegister, das ein Byte senden oder empfangen kann. Zu einer sicheren Datenübertragung ist es dann noch ein ganz weiter und steiniger Weg. Anfänger unterschätzen oft den nötigen Aufwand für ein zuverlässiges Protokoll. RS-485 würde ich nicht für viel Geld programmieren wollen. Bei CAN schreibt man ganz einfach Adresse + Daten in ein Messageobjekt und setzt das Sendebit. Der andere Teilnehmer kriegt einen Empfangsinterrupt und liest die Daten aus einem Messageobjekt. Fertig.
:
Bearbeitet durch User
Manuel schrieb: > Noch eine Frage zum Thema Stichleitungen. Wieviel Meter sind bei > 115kbit/s und slew rate Limitierung denn akzeptabel? Mit z.B. MAX3082 oder MAX3072 (weiß nicht mehr genau mit welchem ich getestet hab) insgesamt >>100m. Stiche völlig egal. Ohne extra Abschlusswiderstände. Leichte Verzugswiderstände sind ev. empfehlenswert. Aber CRC und ein Protokoll welches Störungen unterdrückt, sind sowieso obligatorisch. Nur so als grober Anhaltspunkt -> 5ns/m Ausbreitungsgeschwindigkeit, auf 100m Hin- und 100m Rückleitung würde die erste Reflexion, wenn's eine nennenswerte geben würde, nach ca. 1us ankommen. Also weit früher als das einen typischen UART bei 115200 auch nur kratzen würde. Aber mit slew rate limited Treiber, wirst wohl da kaum eine messen können. 5V Spannungsabfall - 0,4A bei 10x1W, da die Teilnehmer ja nicht alle am Ende der Leitung sitzen sondern eher gleich verteilt, denke ich du rechnest mit > 200m. (AWG24 = CAT5 = < 90 Ohm/km bei zwei Adern je Versorgung also nur 1x zu rechnen, bei 3 Adern wär's noch besser), korrekt? Aber warum ein Teilnehmer 1W verbraten soll, verstehe ich nicht. Der sollte doch eher schlafen. Selbst mit einem einfachen hintergrundbeleuchtetem Display, darf der nicht mehr als 0,1 - 0,25W verbrauchen (PIC24 mit 128x64 Display ohne sleep mode, ein EFM32 kann das viel besser und ohne Hintergrundbeleuchtung sowieso). Ich denke da hast du einige Reserven eingerechnet. Nochmal zu den CAN Fanatikern - der physical layer von CAN ist für sowas nicht wirklich gut geeignet. Erklärung siehe oben. Und die CAN Treiber die slew rate einstellbar sind, haben üblicherweise wieder kein 3V3 Interface. Also entweder 5V uC oder nochmal level shifter dazu. Und Strom saufen die auch ganz schon. Für sowas nimmt nur jemand CAN, wenn er nichts anderes kennt bzw. unbedingt einen uC einsetzen will, der eh schon CAN integriert hat. Da kommen wir zum 2. Nachteil von CAN in dieser Anwendung, begrenzte Controllerauswahl. Ein UART hat fast jeder, CAN nur die teureren komplexeren, und nicht sehr effizienten. Aber wenn man so einen uC kennt und beherrscht, den Preis und Stromverbrauch akzeptieren kann, dann ist CAN schon eine feine Sache. Aber eher für kürzere Kabel und wo man die Busstruktur einigermaßen einhalten kann.
Btw. das der Transmitter beim RS485 nach dem Senden den letzten Bytes deaktiviert wird, sollte klar sein. Das können die meisten Controller automatisch mit CTS gesteuert. Und wie gesagt, bei RS485 (fail safe und slew rate limited Treiber, deiner Geschwindigkeit und <100m pro Einzelstich) brauchst gar keinen extra Abschlusswiderstände. Da baue ich eher ~10k Verzugswiderstände am Master, gegen Störungen in den Kommunikationspausen, ein.
Andi B. schrieb: > Nochmal zu den CAN Fanatikern - der physical layer von CAN ist für sowas > nicht wirklich gut geeignet. Nö, die CAN-Entwickler waren ja nicht dumm. Oftmals sehe ich beim Kunden, daß nur auf einer Seite ein Terminator steckt, weil es läuft ja. Mit Fanatismus hat das nichts zu tun, sondern wieviel Mannjahre Manuel für die Entwicklung des RS-485 Stacks opfern will. Nicht umsonst benötigen fertige RS-485 Stacks viele kB an Flash und einem Anfänger fällt es schwer, sie zu verstehen. Natürlich bastelt sich keiner einen CAN-MC selber. Z.B. der AT90CAN128 wird gerne genommen und ist gut verfügbar. Mit 15 MOBs kann der ne Menge Nachrichten puffern. Man kann also durchaus den CAN-Interrupt längere Zeit sperren, ohne daß es kracht. Eine UART mit 3 Byte Puffer ist dagegen ein Witz. Ein CAN Slave muß auch nicht ständig auf dem Sprung sein, ob der Master ihm einen Sendeslot freigibt. Er nimmt sich ihn, sobald er Lust dazu hat. Die zeitliche Abfolge spielt bei CAN einfach keine Rolle. Aber es bleibt jedem natürlich selbst überlassen, wie schwer er sich die Programmierarbeit machen möchte. Man kann auch Bestückungsoptionen mit RS-485 und CAN vorsehen. Und wenn man dann von RS-485 Aussetzern die Nase voll hat, auf CAN umschwenken.
@ Peter D. - vielleicht solltest du auch mal versuchen den pyhsical layer etwas genauer zu betrachten. Du würdest du vielleicht auch draufkommen, CAN ist z.B. für Stichleitungen nicht gut geeignet. Ich denke ich hab das oben schon differenzierter dargelegt. Es hilft nix wenn du immer auf der Stelle verharrst und nur auf den Vorteil der einfacheren Integration in dein SW-Framework verweist. Es gibt viele Gründe warum man nicht überall CAN nehmen kann und soll (gilt genauso für jedes andere Übertragungsverfahren). Übrigens, nicht nur die CAN Entwickler waren nicht dumm. Viele andere Entwickler waren und sind es auch nicht.
Andi B. schrieb: > CAN ist z.B. für Stichleitungen nicht gut geeignet. Man sollte vielleicht nicht gerade eine Sterntopologie aufbauen, aber Stichleitungen sind kein Problem. Man darf ruhig die Baudrate runtersetzen, wenn es Reflexionen gibt. Da immer einer die Arbitration gewinnt, darf CAN bis nahe 100% Buslast arbeiten. Es sind keine zusätzlichen Wartezeiten notwendig, wo der eine Sender abschaltet und bis der andere Sender anfängt. Wir hatten schon mehrfach Geräte mit RS-485, bei denen man zusätzliche Wartezeiten einlegen mußte. Manche verschluckten nur Pakete, manche stürzten komplett ab. Der Master muß also zusätzlich Däumchen drehen, damit es funktioniert. Jeder SW-Entwickler haßt solche Protokolle, die mit Wartezeiten arbeiten. Oft sind diese Wartezeiten nicht dokumentiert oder nur durch mehrfaches Nachfragen zu erfahren. Manchmal wird auch stur geleugnet, daß der RS-485 Stack buggy ist und es hilft nur Trial&Error. Dann war das auch das letzte Gerät, was wir bei diesem Hersteller gekauft haben. Unsere Erfahrungen mit RS-485 sind daher gelinde gesagt gemischt, ganz im Gegensatz zu CAN. Daß bei CAN alles kritische schon die Hardware macht, ist doch ein großer Vorteil und läßt wenig Spielraum für SW-Bugs.
:
Bearbeitet durch User
Peter D. schrieb: > Man sollte vielleicht nicht gerade eine Sterntopologie aufbauen, aber > Stichleitungen sind kein Problem. Man darf ruhig die Baudrate > runtersetzen, wenn es Reflexionen gibt. Was aber nicht die Reflexionen verringert, sondern nur soweit kaschiert, dass sie ev. nicht mehr so auffällig und direkt die Kommunikation stören. Das ist genauso Pfusch wie die SW die du in einigen Geräten kritisierst, die du offenbar von irgendwen zugekauft hast.
Andi B. schrieb: > Das ist genauso Pfusch CAN benutzt wie die UART eine 3-Fach Abtastung in der Mitte der Bitzeit. Wenn man die Baudrate so wählt, daß dann die Reflexionen abgeklungen sind, ist das kein Pfusch. Man kann aber auch die Abtastzeitpunkte näher am Ende der Bitzeit wählen.
Peter D. schrieb: > Andi B. schrieb: >> Das ist genauso Pfusch > > CAN benutzt wie die UART eine 3-Fach Abtastung in der Mitte der Bitzeit. > Wenn man die Baudrate so wählt, daß dann die Reflexionen abgeklungen > sind, ist das kein Pfusch. Man kann aber auch die Abtastzeitpunkte näher > am Ende der Bitzeit wählen. Du hast offensichtlich den Sinn von "slew rate limited" und die Physik dazu bezüglich Reflexionen noch immer nicht verstanden. Es geht nicht darum nach den Reflexionen zu bewerten, sondern erst gar keine entstehen zu lassen. Ich schreib mir hier schon die Fingern wund um verständlich darzulegen, dass slew rate begrenzen bei CAN nicht so einfach ist und deshalb das verhindern von Reflexionen mit z.B. RS485 vieeeel einfacher geht. Aber offensichtlich ohne Erfolg :-(
Andi B. schrieb: > Es geht nicht > darum nach den Reflexionen zu bewerten, sondern erst gar keine entstehen > zu lassen. Wer schreibt denn sowas vor? Es reicht völlig, wenn die Verbindung zuverlässig ist und die Datenrate ausreichend. Immer nur so gut wie nötig entwickeln und nicht wie maximal möglich. Auch bei den alten PCA82C251 habe ich den Widerstand für Slope control immer auf 0 Ohm gesetzt und keine Probleme mit CE gehabt.
:
Bearbeitet durch User
Beitrag #6420249 wurde vom Autor gelöscht.
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.