Hallo zusammen, ich bräuchte eure Hilfe. Ich habe GRBL auf einen AT32UC3 portiert und spiele nun damit ein bisschen rum. Ich will die X und Y Achsen so umbiegen, dass ich direkt Galvos ansteuern kann. Um den G-Code an den Controller zu senden verwende ich LaserGRBL. Funktioniert auch soweit, bis auf eine Kleinigkeit. Original ist die Achsauflösung auf 1256 steps/mm eingestellt. Bei den Galvos bin ich aber bei etwa 400 steps/mm unterwegs. Kann man einstellen, kein Problem, aber die Rückmeldung auf dem Bildschirm stimmt dann nicht mehr mit der Geometrie überein. Es scheint als sein die Geometrie auf dem Bildschirm größer als das, was der Controller zurück schickt. Diese Problem hatte ich auch schon, als die Software noch Schritte ausgegeben hat. Das hat also mit den Galvos nichts zu tun. Nun finde ich die Stelle nicht, wo die Position an den PC zurück gesendet wird. Oder liegt das eventuell an LaserGRBL? Hat das jemand von euch auch schonmal beobachtet? Ich hoffe mir kann jemand einen Tipp geben. Grüße, Jens
:
Verschoben durch Moderator
Jens W. schrieb: > Ich will die X und Y Achsen so umbiegen, dass ich direkt Galvos > ansteuern kann. Was sind denn Galvos? Ich hab mit CNCjs ganz gute Erfahrungen gemacht. Da kann man auch alles über die Weboberfläche einstellen. Normalerweise werden die Positionsdaten regelmäßig mit einem "?" gepollt, siehe auch https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl
Hallo Christopher, Galvos sind analoge, absolut positionierende Spiegelmotoren. Das kennt man von den echten Laserbeschriftern oder Laserprojektoren. Schau mal hier: https://www.youtube.com/watch?v=vGYbbFLWTGU Da siehst du den Aufbau. Ist aber nicht meiner! Sondern da will ich hin! Und die Anwendung: https://www.youtube.com/watch?v=7nVMRmfJnZg So etwas stelle ich mir vor. Hier lasert er auf Thermopapier. Ich möchte das halt gerne mit G-Code ansteuern, damit man möglichst flexibel ist. Zum Problem: Wenn die Position von LaserGRBL gepollt wird, dann muss es ja doch an meinem Controller liegen, wenn die Position nicht passt. Hast du dich da schon näher mit beschäftigt? Ich werde wohl nochmal von vorne anfangen müssen: Ich habe mir einen Arduino bestellt und implementiere das erstmal dort. Und dann, wenn das da richtig läuft, dann portiere ich das wieder auf meinen AT32UC3. Den brauche ich halt wegen der Rechenleistung. Da die Galvos sich so schnell bewegen lassen, muss der Controller auch die Daten schnell genug bereit stellen können. Grüße, Jens
Hallo Jens, danke erstmal für die Erklärung mit den Galvos. Man lernt ja nie aus ;) Um Missverständnissen vorzubeugen: Ich kenne LaserGRBL nicht und habe es auch noch nie benutzt. Hab mir aber gerade mal kurz ein Youtube-Video dazu angeschaut und es sieht so aus als würde da nichts gepollt und direkt der G-Code für die aktuelle Position hergenommen. Vielleicht wird aber auch im Hintergrund ab und zu gepollt und man sieht es nur nicht in der Konsole. GRBL selber kenne ich jedoch ganz gut. Habe damit mit einem STM32 mal ein Projekt an der Uni durchgeführt. Als Benutzeroberfläche hatten wir CNCjs, wobei wir damals auch über LaserWeb gestolpert sind, was ich mir an deiner Stelle mal ansehen würde. Selbst wenn es nur dazu ist um zu schauen ob die selben Probleme dort auch auftreten: https://github.com/LaserWeb/LaserWeb4/wiki
Hallo Jens, du kannst bei GRBL die Rückmeldung in mm oder Inch einstellen. Könnte sein, dass das dein Problem ist. $13= 0 mm $13=1 Inch Grüße Klaus
Angehängte Dateien:
-
GRBL-Plotter.png
21 KB
Beim GRBL-Plotter kannst Du dir die gepollten Daten direkt angucken im COM-Fenster - siehe Screenshot - evtl. hilft es ja. https://github.com/svenhb/GRBL-Plotter
Hallo, danke euch beiden! Ich habe natürlich auch ein bisschen weiter gemacht. Ich habe mir einen Arduino besorgt, um mal zu sehen wie das Original funktioniert. Und es sieht so aus, dass bei der Portierung was schief gelaufen ist. Mit dem Arduino läuft alles gut und so wie es soll. Das Projekt von oben ist ja auch nicht auf meinem Mist gewachsen, sondern das habe ich im Internet gefunden und habe dann damit weiter gemacht. Was ich jetzt mache ist, dass ich die Portierung von Arduino auf den AT32UC3C nochmal selbst mache. USB läuft. Das externe EEPROM läuft (das wollte ich mit Absicht nicht mit dem Flash des Controllers machen. Ich will extra das EEPROM nehmen). Jetzt bin ich dabei GRBL soweit zu verschlanken (auf dem Arduino), dass die Portierung leichter geht. Soweit bin ich im Moment. Wie sieht es denn aus? Gibt es hier noch mehr, die mit aufspringen wollen? Dann müsste man hier mehr machen und posten. Was verwendet ihr für ein Board? Grüße, Jens
Jens W. schrieb: > Galvos sind ... ... kaputtgesparte Galvanometer https://de.wikipedia.org/wiki/Galvanometer
Hallo zusammen, ich habe den Fehler von oben gefunden. Der ist echt tückisch. Es liegt an den Compiler Einstellungen. Wenn man nicht nur die FPU sondern auch die Fast Math Option einschaltet. Dann scheint er sich zu verrechnen. Natürlich nicht wirklich. Ich vermute, dass bei den Fast Math Operationen früher gerundet wird und dann wird die Position zunehmend ungenauer. Wenn ich den Haken weg nehme läuft das super. Auch mit FPU aktiv. Zusätzlich die Fast Math Optionen braucht man vermutlich nicht unbedingt. Das Teil läuft richtig schnell! Unglaublich was man da für Geschwindigkeiten erreicht! Grüße, Jens
Hallo jens, Bin gerade auch dabei mit einem galvo herum zu spielen und bin auf deinen Beitrag gestoßen. Ich wollte es auf einem mega2560 zum laufen bringen und dich bitten mir mit dem Code etwas unter die Arme zu greifen. Hast du den für den Arduino zur hand? Liebe Grüße Julian
Hallo Julian, für den Arduino habe ich den nicht, aber unter die Arme greifen kann ich dir. Bei mir läuft jetzt alles. Kannst du beschreiben was du machen willst und wie? Welche DACs nimmst du? Davon ist es abhängig, wie die Implementierung für die Galvos sein muss. Grüße, Jens
Hi Jens, danke für die rasche Rückmeldung, Ich fange gerade an mit dem MCP4725 und habe mir noch den SPI DAC TDA1543 16bit DAC bestellt. Ich habe mich schon mit Visuino (grafisch) versucht und auch schon mit pronterface Gcode zu den Galvos übertragen. leider zappelt es sehr stark und ich würde mir die GRBL Funktionen zu Nutze machen wollen. Das verfahren von pPunkt x0 zu x1 ist ja gerade das interessante daran:-) Ich habe versucht den Quellcode zu verstehen, leider ohne Erfolg...GRBL läuft ohne Probleme auf meinem mega2560, jetzt fehlt "nur noch die DAC Implementierung an der richtigen Stelle...
Hallo Julian, für die ersten Tests kannst du die DACs schon nehmen, aber richtig geil sind die beide nicht. Der MCP4725 hat nur 12bit Auflösung, das wirst du deutlich sehen können, dass sich die Spiegel in Schritten bewegen. Der TDA1543 ist von der Auflösung gut, aber das Interface ist nicht so ohne. Das ist I²S. Das ist eigentlich für Audiodaten gemacht. Da hat dein Controller kein HW-Modul drin, dass du die Daten schnell rüber bekommst. Aber, jetzt kommt das Wichtigste, beide DACs haben keine richtige Referenzspannung drin. Die verwenden die Versorgungsspannung. Und die driftet in der Regle schon. Und wenn du da auch noch den Controller dran hast, dann kann der während des Betriebs die DAC-Ausgabe stören. Für meine ersten Versuche habe ich mir mit zwei 8bit Schieberegistern einen DAC selbst aufgebaut mit einem R2R-Netzwerk. Das könntest du mit SPI betreiben und das liefert für die ersten Gehversuche recht gute Ergebnisse. Aber auch da ist die Linearität nicht gut. Das liegt an der Toleranz der Widerstände. Aber wie das so ist, dass bekommst du aus der Bastelkiste am Sonntagmorgen zusammen. Und, gleiches Problem mit der Referenzspannung. Danach habe ich mir DACs (DAC8562)von Texas Instruments besorgt (Anhang). Und die sind echt gut. Die haben eine interne Referenz, lassen sich über SPI betreiben, bieten 16bit und sind billig. Da sind in einem Chip auch gleich zwei Kanäle drin. (Ich müsste noch welche haben, da kann ich dir was von abgeben). Zur Implementierung: Bei GRBL gibt es die Haupt-Interrupt-Routine. Da werden die Portbits für den Takt und die Richtung gesetzt. Da kommentierst du die Zeilen für die X- und die Y- Achse aus und schreibst deine Funktion für die DACs rein. Sowas wie "write_DAC_value(uint8_t channel);" Die Zuordnung bei mir ist so, dass jeder Schritt ein Digit vom DAC ist. Da wird also nichts umgerechnet oder so. Einfach die Koordinate als DAC Wert übertragen. Um den Spiegel dann zu verfahren benutze ich LaserGRBL. Ich such mal ein paar Fotos von meinem Aufbau raus. Grüße, Jens
Hallo Jens, danke schon mal für den Input, ich versuche gerde eine einfache Wire.Transmission zu gestalten mit dem 12bit DAC von Adafruit aber ich bekomme beim compilieren von GRBL ständig fehlermeldungen da diese wohl in C und nicht cpp geschrieben sind und Klassen oder Members nicht funktionen. Hast du da eine Idee?
Hallo Julian, beim Mischen von C und C++ wird es wohl schwierig. Ich mache alles in C. Da hätte ich auch sicher noch code für dich, der funktioniert. Du kannst dein Projekt hier mal hochladen, dann schau ich mal rein. Was willst du denn eigentlich machen? Vielleicht gibt es ja eine Lösung, die dich schneller ans Ziel bringt. Ich vermute, du willst einfach erstmal Signale aus dem DAC bekommen, stimmts? Grüße, Jens
Hallo Jens, ich habe etwas andere Probleme. Ich nutze einen Atmega328 am seriellen Interface. G-Code wird über RS232 mit Laserweb übertragen. Das Ganze funktioniert in den ersten Schritten auch recht gut. Leider verrechnet sich der der ATMEGA nach den ersten Zeilen, dann stimmen die anzusteuernden Punkte gar nicht mehr. Wenn ich ein File mehrfach ausplotte, sieht das Ergebnis jedes Mal etwas anders aus. Die Motorsteuerung hatte ich geprüft und mehrfach Linien gezogen nur X, nur y und beides(schräg) , alles ohne Probleme, die Genauigkeit hat dabei gepasst. Das nächste größere Problem ist, das die Parameter ($0-$132) die intern gespeichert werden, ab und zu plötzlich komplett versaut sind. Ich habe das mit einem Uno Nachbau-Bord getestet und einem AtMega328 in DIL , ohne das weitere Technik an den Port's hängt getestet, immer wieder ohne Symptomatik der Datenverlust. Compiliert habe ich das mit AVRGCC. Hast du evtl. eine Idee? Grüße Klaus Ich hab ein kleines File angehängt, selbst dabei kommt nur Mist raus.
Hallo Klaus, da kann man nur genauere Infos geben mit dem Sourcecode von deinem Atmel-Controller. Bei mir war es so, dass ich GRBL auf den AVR32 portiert verwendet habe. Dabei wurden die Kreisinterpolationen in float gerechnet und die waren bei Compiler deaktiviert (also die HW Unterstützung der Floating Point Unit). Da gab es dann Probleme. Wenn bei dir direkt nach der ersten Zeile die Koordinaten nicht mehr stimmen würde ich als erstes auf einen Variablenüberlauf tippen. Das hatte ich auch schon. Da muss man ein bisschen aufpassen. Auch bei der Berechnung kann es zu unerwarteten Effekten kommen, wenn der Compiler Variablen zusammenfasst. Aber wie gesagt, genau kann man das nur eingrenzen, wenn du deinen Code postest. Wenn bei dir Daten verloren gehen, könnte das mit den Interrupts zusammen hängen. Dein Schreibvorgang ins EEPROM könnte durch einen anderen Interrupt unterbrochen werden (Kommunikation zum Beispiel). Dann sind deine Daten Schrott. Von welcher Basis von GRBL bist du denn abgesprungen? In der Regel funktioniert das sehr gut. Möglicherweise ist es am Einfachsten du fängst nochmal mit einem frischen System an und fügst danach (wenn das richtig läuft) deinen eigenen Teil mit dazu. Was soll es denn werden? Verwendest du auch Galvos oder Schrittmotoren? Viele Grüße, Jens
Hallo Jens, die Bilder sehen vielversprechend aus! Also ich bin bislang nicht all zu weit gekommen, habe mir von Github die GRBL Source gezogen und in der Haupt Interrupt Routine versucht eine DAC Ausgabe zu machen, aber es gibt da wohl Probleme mit Klassen bzw. dem MCP4725 Library im Code. Ich bekomme da nichts compiliert. Ich habe mir jetzt einen Due bestellt da ist dein Code vlt kompatibel. Hast du deine Source vlt zur Hand? Habe auch noch was wie OpenMGSLS gefunden was für Atmel Due aber auch vereinfacht für mega2560 geht. Dein System wäre allerdings was Geschwindigkeiten angeht , äußerst interessant und ich hoffe es irgendwie zum laufen zu bekommen. ich woltle ersteinmal fähig sein in einer Ebene zu zeichnen und damit dann Leiterplatten zu belichten oder zu gravieren. Später dann um eine Z-Achse erweitern.
Hallo Julian, ich hatte als Absprungbasis den Arduino Mega 2560 genommen. Dazu habe ich mir die Source gezogen und erstmal laufen lassen. Danach hatte ich das erst portiert. So würde ich dir das auch vorschlagen. Das für den Arduino Mega habe ich noch. Besorg dir doch auch so ein Teil und von da aus geht es weiter. Meine Basis war auch nicht in Klassen gemacht. Ich such dir das heute Abend zusammen. Von der Geschwindigkeit brauchst du dir keine Gedanken machen. Wenn du was belichten willst, oder in Holz brennen, dann schafft der Arduino Mega das noch ohne Probleme. Ich meld mich. Grüße, Jens
Hallo Julian, angehängt sind die GRBL Implementierungen, mit denen ich gearbeitet habe. Ich habe die Version mit 5 Achsen auf den 32bitter portiert. Ich würde dir die erste Version mit 3 Achsen empfehlen. Das reicht für deine Galvos aus. Du hast ja nur zwei. Das nimmst du und legst dir ein Projekt im Atmel Studio an. Fügst alle Dateien hinzu und dann sollte das schonmal kompilieren. Das ist alles in C. Also keine Klassen. Wenn das läuft kümmerst du dich um eine Funktion, die einen Wert auf den DAC raus schmeißt. Und wenn die auch funktioniert baust du diese in deine Implementierung von GRBL mit rein. Wenn was nicht will, dann poste das Atmel Studio Projekt. Dann kann ich mit rein schauen. Grüße, Jens
Hi Julian, kommst du voran? Funktioniert dein DAC jetzt? Gruß, Jens
Hallo Jens ich bin noch nicht dazu gekommen die grbl Software zu portieren habe zwischendurch einen Quellcode gefunden von einem GitHub Projekt namens openmgsls was auf einem die läuft und auch die Umrechnung von kartesisch auf polar integriert. Werde am Wochende versuchen das grbl zum laufen zu bringen und dann die beiden in der Performance vergleichen
Hallo Jens, ich hatte damals… das Ganze von Github kopiert und die Einstellungen für das Homing XY gemacht. Compiliert und wieder auf die Atmel’s. Es wurde nichts geändert, nur die Homing-Einstellungen auf 2 Achsen nach Anleitung. How do I configure my homing cycle to just do 2-axes? Or I have a pen plotter and don't have a Z-axis. Configuring Grbl for a 2-axis CNC machine is easy. The config.h file contains a lot of compile-time options that you can enable or disable based on particular needs, including altering the homing cycle to only perform it on the X and Y axes. There are instructions and descriptions for each option available, but some users may not be familiar with C programming, comments, and macros. So, here's how to do it. You'll see two lines in the config.h file like so: #define HOMING_CYCLE_0 (1<<Z_AXIS) // REQUIRED: First move Z to clear workspace. #define HOMING_CYCLE_1 ((1<<X_AXIS)|(1<<Y_AXIS)) // OPTIONAL: Then move X,Y at the same time. Change these two lines to look like: #define HOMING_CYCLE_0 (1<<X_AXIS) #define HOMING_CYCLE_1 (1<<Y_AXIS) Wie schon gesagt, auch wenn ich nur das Bord am USB hängen habe nichts mit mache, sind die Einstellungen nach einiger Zeit komplett verdreht. Grüße Jens
Hallo ihr beiden, da mir die Einstellungen immer wieder um die Ohren geflogen sind, habe ich mir dazu mal ein kleines Progrämmchen geschrieben. Es können die Parameter in einer GUI geändert werden und auch mit dem click auf das $-Zeichen einzeln oder im Block hochgeladen werden. Ein Testmodus ist auch mit dabei. Das spart die $xx= tippelei in igendwelchen Terminalprogrammen ;-) https://sourceforge.net/projects/grbl-controller-einstellungen Grüße Klaus
Hallo Klaus, die Homing Cycles habe ich noch gar nicht verwendet. Da ich ja keine Schrittmotoren, sondern die Spiegel ansteuere brauche ich das Homing nicht. Die Spiegel positionieren absolut. Das heißt jedes Digit in dem 16bit Wert für den DAC entspricht einem Pixel auf der Zeichenfläche. Länge und Breite entsprechen also etwa 65000 Pixel. Über die Verstärkung der Spannung stelle ich dann die Größe der Projektion ein. Bei mir etwa 200mm x 200mm. Wenn man also die Spiegelmotoren verwendet kann man das Homing komplett deaktivieren. Sollte man auch, da man ja keine Endschalter an den Achsen hat und somit in einer Endlosschleife landet. Wenn die Daten nach einiger Zeit für die Parameter nicht mehr stimmen, dann passiert da aber was ganz komisches oder? Entweder irgendeine Funktion mörsert dir den Speicherinhalt aus dem EEPROM oder dir funkt vielleicht ein Interrupt rein, wenn du es gerade nicht gebrauchen kannst. Schwer zu sagen aus der Ferne. Ich bin gerade dabei ein Board zu machen, dass im Grunde die Zeitkritische Interrupt-Routine in einem FPGA ausgelagert hat. Das sollte einiges an Geschwindigkeit bringen. Klar, für Schrittmotoren braucht man das nicht, aber für die Spiegel sind Schrittfrequenzen von 250kHz kein Problem. Und das schafft der Atmega nicht und mein AVR32 auch nicht. Da muss was leistungsstärkeres her. Aber das Board ist noch nicht so weit. Ich kämpfe noch mit ganz anderen Sachen rund um das FPGA. Grüße, Jens
Hallo Jens, ich habe die GRBL nun zum compilieren gebracht für den atmega 2560. Leider geben die Dacs sowohl spi als auch I2c nichts aus. ich habe vor allem das Problem, dass er meinen gcode nicht versteht. Welches programm ist denn empfehlenswert für gcode Erstellung mittels GRBL?
Hallo Julian, ich verwende das hier: http://lasergrbl.com/download/ Du müsstest aber so langsam genauer beschreiben was du gemacht hast und wo das Problem ist. Auch wenn du deinen gesamte Code postest hilft das. Es ist im Moment sehr schwer zu helfen ohne dass man nähere Infos hat. Da können 1000 Dinge falsch sein oder schief gehen. Grüße, Jens
hallo Jens, ich habe nuun den DAC per I2C in der Stepper.cpp eingefügt an der Stelle, wo ich dachte es macht Sinn. Schaue mal rein, den Dac initiiere ich in der grblmain.cpp aber das System hängt und friert ein. wenn ich den DAC in der Stepper.cpp auskommentiere funktioniert alles in der Lasergrbl software. Hast du eine Iddee woran es liegen kann? Ich habe eine komplett andere source verwendet, welche gut mit dem Mega kompilierbar ist.
Hallo Julian, für die Erstellung von Gcode verwende ich Incscape mit dem Jtech Plugin. Incscape funktioniert wie Coreldraw. Das Plugin findest du hier : https://jtechphotonics.com Ein Problem gibt es in Incscape mit dem Laserplugin, bitte keine Kurven über den Knoten ziehen. Das wird nicht richtig umgewandelt. Solltest du da Hilfe brauchen, kann ich dich Remote schulen. Grüße Klaus.
Heisst das Programm wirklich Incscape oder vielleicht Inkscape?
Hallo Helmut, Ja. Da hatte sich ein Fehler eingeschlichen. Vielen Dank an die Autokorrektur von Android ,-) Grüße
Hallo Julian, die fehlt doch noch die Library für den DAC oder? Die ist in deinem Packet nicht mit drin. Du musst beim Compilieren auf die Warnungen auch achten. Wenn er die warnt, dass er eine Datei nicht findet, dann musst du schauen, dass du die mit ein bindest. Es ist etwas verwirrend: Der DAC, den du verwendest ist der MCP4725. In deinem Code lese ich das so, als ob du SPI verwenden willst. Der DAC wird aber über I2C angesprochen. Das würde auch die Endlosschleife erklären, in der er hängt. Das Init, das du machst, ist wahrscheinlich nicht richtig. Ich sehe nichts, dass das TWI Modul und die Portpins entsprechend gesetzt werden. Wenn du das nicht machst kommt am Pin nichts raus. Dann hast du das Problem, dass bei I2C/TWI, der Sender auf das ACK des Empfängers wartet. Ohne Signal am Pin keine Reaktion, also endet das in einer Endlosschleife. Ich empfehle dir die Library für den DAC in einem kleinen extra Projekt zum Laufen zu bringen. Dann gibst du nur einen Sägezahn aus. Also so etwas:
1 | for (uint16_t i=0; i<4095; i++) |
2 | {
|
3 | dac.write(i); |
4 | _delay_ms(1); |
5 | }
|
Wenn das läuft und du ein schönes Signal am Oszi siehst, dann baust du das entsprechend in dein GRBL ein. Für den G-code verwende ich LaserGRBL. Funktioniert bei mir problemlos. Grüße, Jens
Hi Jens, also ich habe GRBL lauffähig auf dem ESP32 mit Webinterface...die Galvos bewegen sich auch mit jedem Schritt ein digit. Ich verwende noch den internen DAC mit nur 8bit aber zum testen des codes ok. (der I2C ist irgendwie defekt:-) und der SPI DAC8532 noch unterwegs) Ich stelle mir nun die Frage, wie die Transferfunktion von kartesisch ins Polarkoordinatensystem umgesetzt werden kann. Ich lenke den Spiegel ja um +-15° aus und das soll dann in eine Linearen BEwegung von -100-100mm resultieren. Ich hänge mal den Quellcode fürs ESP32 an:-) Was mir ebenfalls auffällt ist, dass im Idle Zustand der DAC zappelt, das muss irgendwie an den Interrupt Routinen liegen. Was sind denn deine Erfahrungswerte für die GRBL config einstellung? also Delays, accelleration etc.
Hallo Julian, das klingt doch schonmal gut soweit! Wenn die Spiegel zappeln, dann kann es auch an den Endstufen liegen. Nur wenn der DAC auch eine "zappelnde" Spannung ausgibt liegt das an denen. Würde mich aber wundern. Ich habe mir an den Ausgang des DACs noch einen Opamp geschaltet, der aus dem single-ended Signal ein Differenz-Signal macht. Das ist deutlich weniger empfindlich auf Störungen. Wenn du tatsächlich mit den 16bit DACs arbeiten willst, dann ist das ein MUSS. Auch wenn du einen Rippel auf der Versorgungsspannung hast (und die verwendest du ja als Referenz -> siehe oben), dann haut der natürlich auch voll auf dein Signal rein. Und ja, die Spiegel sind so empfindlich, dass man das sieht. Die Umrechnung von den Koordinaten findest du im Netz oder in jedem guten Mathebuch. Auswendig weiß ich das auch nicht mehr. Sicher funktioniert das mit sin, cos und tan. Ich habe einfach mal ein Dreieck aufgezeichnet. Oben in der Spitze sitzen die Spiegel, unten habe ich die Breite der Objektebene und habe dann über den tan und den Winkel die Höhe ausgerechnet, die das dann haben muss. Da macht man noch einen Fehler, da der Laser auf einer Kreisbahn abgebildet wird und die Ebene unten eben flach ist. Das führt, dann zur Kissenverzerrung. Das ist eigentlich das, was du brauchst, damit das funktioniert. Ich habe das bei mir gar nicht mehr fertig gemacht bis jetzt, da der Fehler so klein ist, dass es nicht auffällt. Wenn du aber Leiterplatten belichten willst brauchst du das zwingend. Da müsste ich noch ein paar Links raussuchen was ich so gefunden haben. Mal sehen ob ich die gespeichert habe. Mach mal deine DACs soweit, dass die laufen. Bis dahin habe ich meine Baustelle auch soweit und beschäftige mich wieder damit. Dann können wir das gemeinsam machen. Am besten in einem eigenen Thread, da man zur Kissenverzerrung und deren Korrektur nur ganz wenig findet. Da habe ich sehr lange gesucht bis ich was brauchbares gefunden hatte. Alles in Allem, geht doch gut voran bei dir! Gratuliere! :-) Grüße, Jens
Hallo zusammen, es gibt Unterschiede zwischen Laser-GRBL und Inkscape+ den Plugin‘s. Laser-GRBL und Co wandeln eine Grafik (bmp, jpg oder ähnlich) in ein Linien-basierten G-Code um. Dabei muss die Laserstärke(Durchmesser des Punktes) angegeben werden. Die Graustufen werden, so mir bekannt, mit mehr Geschwindigkeit gelöst. Inkscape ist ein vektororientiertes Zeichenprogramm. Dabei werden die zu zeichnenden Dinge als Objekte dargestellt. Skalierungen können im Gegensatz zu Pixelgrafiken immer wieder durchgeführt werden. Der daraus resultierende G-Code wird nur die Linien abfahren, die in Inkscape gesetzt und als G-Code umgewandelt wurden. Wenn du also ein Jpeg mit einen Quadrat von 10 x 10 mm hast und das Jpeg 20x20 mm groß ist wird Laser-GRBL das Bild zeilenweise abtasten und das so an den Laser senden. Inkscape macht da nur das draus: M05 S0 G90 G21 G1 F800 G1 X5.0 Y15.0 G4 P0 M03 S190 G4 P0 G1 F160.000000 G1 X15.0 Y15.0 G1 X15.0 Y5.0 G1 X5.0 Y5.0 G1 X5.0 Y15.0 G4 P0 M05 S0 G1 F800 G1 X0 Y0 Mein Laser schneidet, gravieren geht auch. Dabei muss ich die Geschwindigkeit der Motoren und die Laserleistung anpassen. Es ist aus meiner Sicht, immer wichtig, darüber nachzudenken, was ich wie erreichen will. Zum flächigen Gravieren mit euren Galvos, ist der Weg über Laser-GRBL keine schlechte Wahl, zum schneiden und beschriften ziehe ich die langsameren arbeiten Schrittmotoren und Inkscape vor. Zum Testen noch eins, es gibt für Inkscape die Erweiterung Eggbot, damit kann man auch Füllungen auf Flächen bringen. Strichstärken sind einstellbar. @ Jens: Da du auf Geschwindigkeit achtest, ist vielleicht mal ein Test wert? Ich erstell dir auch den G-Code ,-) Kann dein Laserplotter(oder wie nennt man das mit den Galvos?) auch mit Laser-GRBL Graustufen darstellen oder machst du nur SW-Grafiken? Grüße Klaus
Hallo Klaus, ich habe beides schon probiert. Das Wandeln von Grafiken geht mit LaserGRBL sehr schön. Das was du machst, dass nur Linien gezeichnet werden sollen, geht damit auch. Dazu muss man wenn man die Grafik einließt nur auf "vektorisieren" klicken. Dann werden nur noch Linien erzeugt. Meine Tests beschränken sich im Moment auf Thermopapier (da braucht man weniger Leistung) und Holz (das geht erstaunlich gut). Mein Laser ist nicht so stark. Einen Test können wir gerne machen, aber den müssen wir nach hinten schieben. Ich habe den Laser gerade weg geräumt, da ich an einer anderen Baustelle dran bin. Ich habe aber noch Videos und Bilder. Die lade ich die Tage mal hoch. Da könnt ihr das Teil in Aktion sehen. Ich muss die Sachen aber erst suchen. Grüße, Jens
Angehängte Dateien:
-
plotter.jpg
240 KB -
bad.jpg
240 KB -
Gut.jpg
240 KB
Hallo zusammen, ich hatte jetzt ein wenig Zeit um mich mal wieder mit meinem kleinen zu befassen. Ein umgebauter Stiftplotter zum Laserschneiden. Ich hatte die GRBL-Files Version 1.1 ins Atmelstudio geladen und kompiliert. Hat alles soweit geklappt, das HEX-File ist merkwürdiger weise auch kleiner als die Variante mit WINAVR. Mit dem Verrechnen hat sich auch etwas ergeben. Der Nullpunkt und der Homing Punkt stimmt nicht. Die sind genau gegenüber. Stelle ich bei Laserweb oder Co den Nullpunkt ein, verrechnet er sich, siehe Bild „bad.jpg“ Lasse ich das, sieht alles super aus. Weiß jemand wie ich das ändern kann? Die Parameter habe ich geändert, die Motoren in der Drehrichtung angepasst…. Egal wie, es bleibt so. Grüße Klaus
Hallo zusammen, Ich klinke mich hier mal mit ein. Ich könnte bei mir im Geschäft 2 alte 10W CO2 Laserbeschrifter mitnehmen. Da ist allerdings der Controller defekt und auch veraltet bzw keine Software vorhanden. Der Laser an sich und die Galvoeiheit währe funktionsfähig. Habe da inzwischen ein bisschen recherchiert wie ich den Controller ersetzen könnte. Die Ansteuerung der Galvotreiber ist differentiell +/- 10V. Bei Ebay gibt es ein fertiges DAC-Board mit der gewünschten Ausgangsspannung und einem DAC8562. Ich habe hier gelesen dass Ihr auch an sowas dran seid. gibt es bei euch inzwischen etwas Funktionsfähiges? (portierte GRBL mit SPI Ausgabe auf den DAC8562) Ich hätte da starkes Interess daran. So etwas selbst zu Portieren bzw Implementieren Übersteigt bei weitem meine Skills. Falls mir jemand sein "fertiges Projekt" zukommen lassen könnte währe echt geil. Die Dinger einfach gegzuwerfen währe echt schade... (Meine bisherige Pejektbeteidigung hier im Forum:Beitrag "Dämmerungsschalter nur 1x pro Tag")
Hallo, ja, das ist bei mir fertig. Ich bin mir aber nicht sicher, mit welchem Board du das machen willst. Ich verwende einen AVR32. Das ist jetzt nicht der populärste Chip. Mehr verbreitet ist der STM. Bei mir ist das so, dass die Ausgabe der X-Achse und der Y-Achse direkt über SPI an den DAC ausgegeben wird. Solange du nicht den gleichen Chip wie ich nimmst, wird dir das wohl nicht sehr viel helfen. Ich kann dir aber helfen die gleichen Änderungen bei GRBL auf dem Arduino zu machen. Das ist nicht so schwer. Das bekommt jeder hin. Ein offenes Thema wäre dann noch die Kissen-Entzerrung. Da habe ich angefangen, aber das ist nicht komplett getestet. Aber eines noch: Ich nehme mal an du willst mit den Teilen auch wieder beschriften. Und nein, jetzt kommt nicht die Predigt, dass die Laser nichts für Anfänger sind! ;-) Ich denke das hat sich herumgesprochen. Nein, die Frage ist, ob bei den Galvo-Köpfen bei dir die F-Theta Linse dabei ist. Wenn nicht, kannst du das als Beschriftungsgerät vergessen. Die Verzerrung bekommst du an den Rändern ohne Linse nicht hin. Oder du hast nur einen sehr kleinen Bereich, mit dem das funktioniert. Das wäre aber nicht praktikabel. Grüße, Jens
Hallo Jens, Das DAC Modul währe das hier: https://www.ebay.de/itm/DAC8562-DAC-Module-10V-Signal-Amplitude-16-Bit-DAC-Single-Bipolar-Output-pans/283627228581 Der Laser ist ein fix fertiges Industrieteil: https://www.picclickimg.com/d/w1600/pict/164000080355_/Macsa-Flymark-30W-Flymark30W-Beschriftungslaser-used.jpg da ist eigentlich alles drin und justiert. Nur leider ist der Controller Unbrauchbar. Ich hätte noch einen esp32 herumliegen. Könnte natürlich auch was Kaufen. Dachte auch schon an ein Smoothieboard, da gibt es auch schon ein geforktes Projekt, aber die Anbindung an ein DAC8562 per SPI fehlt halt... https://www.reddit.com/r/3Dprinting/comments/fh69dk/i_modified_smoothieware_to_add_support_for_using/ Für den DAC8562 gibt es auch eine Arduino Lib: https://github.com/k164v/DAC8562 Aber ich weis nicht ob und wie man das alles zusammenwürfelt... Mit der Arduino IDE hatte ich scho mal was gemacht, aber das find ich auch schon echt schwer.. Das bei der Umsetzung einer Linearen Step/Dir Bewegung auf eine Rotatorische Bewegung da teoretisch eine Kissenverzerrung auftreten müsste ist mir auch schon durch den Kopf gegangen. Wie wirkt sich die in der Praxis aus? ist das eher eine Kissenförmige oder Tonnenförmige Verzeichnung? Im WIKI https://de.wikipedia.org/wiki/Verzeichnung gibt es einen Hinweis auf ein Mathematisches Verfahren um das Rauszurechnen (theoretisch) Gruß Thomas
Hallo, da sind bei dir ja einige Baustellen. Und ja, die Kissenverzerrung ist auch da. Das sieht man deutlich. Vor allem wenn der Projektionsabstand klein ist gegenüber der Objektfläche. Ich verwende einen billigen Kopf für Lasershows. Und da fehlt die Linse und das ist bei mir das Killerkriterium. Damit ist das bei mir gestorben. Das bekommst du nicht vernünftig hin! (Und da habe ich mir schon viele Gedanken gemacht, die aber alle mechanisch nicht zielführend sind). Ist da jetzt eine Linse dabei oder nicht? Das musst du doch sehen. Oder mach mal von allen Seiten ein Foto, dass man sich das anschauen kann. Die Einbindung der SPI wird dein kleinstes Problem, glaub mir ;-) Lass uns das der Reihe nach machen: - ist die Linse dabei? - Welches Board willst du nehmen? Das sind die Fragen, die als erstes anstehen. Dann geht es weiter. Grüße, Jens
Hallo, Nun, bei der Verzerrung handelt es sich nicht um eine vollständige Kissenverzerrung, sondern nur um eine "halbe" Kissenverzerrung in einer Achse. In der X-Richtung entsteht an den Seiten die Kissenverzerrung. In der Y-Richtung entsteht eine Linearitätsverzerrung nach außen hin, aber KEINE Bogenverzerrung wie bei X! Das liegt daran, dass der Strahl zweifach über Spiegel geführt wird und nicht an einem einzigen Spiegel in X und Y abgelenkt wird. Wäre es nur 1 Spiegel, der in allen Achsen beweglich ist, dann gäbe es die Bogenverzerrung an allen 4 Seiten. Da aber auf dem 2. Spiegel immer nur eine Linie (vom 1. Spiegel) abgebildet wird und diese Linie sich lediglich in der Y-Position ändert, bleibt die Linie stets gerade. Nur die Positionsschritte werden in Y nach außen hin größer, weil bei flacherem Zielwinkel auf die Fläche die Distanz bis auf Unendlich bei 0° steigt. Man braucht eine kombinierte Cosinus-Korrektur. Die Ankathete ist der senkrechte Strahl nach unten bei 0° Auslenkung. Die Hypotenuse ist der abgelenkte Strahl (deckt sich mit Ankathete bei 0°). Je weiter abgelenkt wird, desto kleiner wird das Verhältnis Ankathete zu Hypotenuse (= Cosinus). Die Auslenkung auf der Ebene muss also um den Faktor des Cosinus reduziert werden, damit das Pixel dort liegt, wo der Strahl den imaginären Projektionskreis darüber schneidet. Bei 0° Auslenkung = x 1, bei 20° Auslenkung x 0,94 usw. Damit für die X-Achse die Bogenverzerrung verschwindet, muss man X mit dem Faktor aus Cosinus(Winkel X) x Cosinus(Winkel Y) verrechnen. Für Y reicht der reine Cosinus aus (Winkel Y). Man muss nun noch den maximalen Ablenkwinkel des Systems exakt ermitteln (den Halbwinkel!) und kann dann die Zielpositionen mit dem Cosinus aus dem Ablenkwinkel jeweils in +/- berechnen. Ich mache das schon seit Jahren bei meinem Foto-Laserbelichter. Die größeren Probleme heissen Schärfentiefe und Strahlquerschnitt. Die Schärfentiefe bzw. Fokustiefe des Lasers muss größer sein als die maximale Distanz des "imaginären Projektionskreises" zur Ebene darunter bei Maximalauslenkung. Dabei ist Maximalauslenkung die DIAGONALAUSLENKUNG beider Achsen! Ist dort z.B. die Distanz 2cm, dann muss die Schärfentiefe DOF (Depth of Field) des Lasers mindestens 1cm betragen und der Fokus 1cm über der Ebene eingestellt werden. Hilfsweise kann der Fokus auch bei 70% Maximalauslenkung auf der Ebene scharfgestellt werden. Das nötige große DOF erreicht man nur durch eine lange Fokusbrennweite bzw. erkauft man sich mit einem recht großen Fokusdurchmesser. Ist ein Kompromiss. Eine mögliche aber komplexe Lösung wäre eine dynamische Fokussierung, welche den Fokus nachführt. Dann könnte mit DOF nahe 0 gelasert werden. Merke: Je kleiner der eingestellte Fokusspot desto kleiner das DOF (und zwar im Quadrat!). Die minimale Fokusbrennweite des Lasers wird natürlich auch aus dem maximalen Ablenkwinkel der Galvos und der gewünschten Fläche eingegrenzt. Will man eine A4 Fläche mit maximal 30° Winkel lasern (Halbwinkel!), dann muss der Galvokopf schon 260mm weit über der Fläche sein. Die Brennweite wird dann schon bei ca. 300mm liegen. Bei X/Y-Lasercuttern sind Brennweiten von 25 bis 100mm normal. Ein größerer Ablenkwinkel als 30° pro Seite ist nicht mit allen Galvos möglich. Es ist auch unpraktikabel, weil die Spiegel mit steigendem Ablenkwinkel größer werden müssen. Stichwort Strahlquerschnitt: Der Strahl wird durch die schräge Projektion auf die Ebene mehr und mehr zur Ellipse. Man bekommt also an den Seiten einen breit gezogenen Spot. Außerdem ist ein Schneiden dickerer Materialien auch nicht möglich, weil der Strahl an den Außenseiten ja schräg schneiden würde. Durch die Strahlverzerung bekommt man natürlich auch unterschiedliche Schnitt- oder Gravurergebnisse zwischen dem Bereich auf den fokussiert wurde und den Außenbereichen. Eventuell muss hier sogar in der Laserleistung nachgeregelt werden. Eine teuere F-Theta Linse korrigert sowohl den Strahlquerschnitt als auch den Auftreffwinkel auf die Ebene. Ohne eine solche Linse macht das nur bei kleimer Objektgröße Sinn. Also wenn die Beschriftungsfläche nur ein paar cm groß ist. Nochwas zu den DACs: Man hätte das auch ohne Programmierkenntnisse ganz "hardwareseitig" mäßig machen können. An die Schrittmotorsignale ein paar TTL-Zählerbausteine z.B. SN74AS867. Takt = Zählereingang, DIR = Up/Down und einen Preset auf den mittleren DAC-Wert z.B. über ein Motor-Enable Signal von GRBL. An die Zählerausgänge einen parallel-DAC z.B. DAC7621 dran und fertig. 12 Bit reichen in dem Fall übrigens dicke. Auf eine A4 Fläche sind das über 300 DPI Auflösung. Gruß Joachim
Hallo Jens, -Die Laser sind wie gesagt fertige Industrieteile da ist natürlich eine F-Theta Linse drin. -Das Board ist mir eigentlich egal schön währe es wenn man das mit der Arduino IDE programmieren / laden könnte. Wie gesagt ich hab noch ESP32 Boards rumliegen. Die könnte ich natürlich nehmen... Gruß Thomas
TotalH schrieb: > Wie gesagt ich hab noch ESP32 > Boards rumliegen. Die könnte ich natürlich nehmen... Nein das sind ESP8266 Boards...
Joachim schrieb: > ochwas zu den DACs: > Man hätte das auch ohne Programmierkenntnisse ganz "hardwareseitig" > mäßig machen können. An die Schrittmotorsignale ein paar > TTL-Zählerbausteine z.B. SN74AS867. Takt = Zählereingang, DIR = Up/Down > und einen Preset auf den mittleren DAC-Wert z.B. über ein Motor-Enable > Signal von GRBL. > An die Zählerausgänge einen parallel-DAC z.B. DAC7621 dran und fertig. > 12 Bit reichen in dem Fall übrigens dicke. Auf eine A4 Fläche sind das > über 300 DPI Auflösung. Cool... Könntest du das Layout evtl. in einer Skitze darstellen? Gruß Thomas
Hallo, na dann hänge ich dir die entsprechenden Dateien für den DAC an. Die Dateien laser_dac.c und .h sind im Prinzip die Portierung der wichtigsten Funktionen aus der Arduino Lib. Keine große Sache. Da musst du nur die SPI anpassen auf eben das Board, dass du nehmen willst. Und in stepper.c ist die Hauptroutine aus GRBL drin. Da gibt es zwei Interrupt routinen. Eine um die Signale zu setzen und eine um die Signale wieder zurück zu setzen. Pro step werden also zwei Interrupt Routinen aufgerufen. Da du aber die Position nur einmal an den DAC senden musst, ist das auch nur in einer ISR gemacht. Man sieht die Zeile, die den Pin zurück setzt ist auskommentiert und durch den Aufruf, der DAC-Funktion ersetzt. Ganz einfach. Ich sende die Position X und Y gleichzeitig, da der DAC zwei Kanäle hat (sehr praktisch). Die Verzeichnung ist da noch nicht mit drin, da das bei mir noch nicht funktioniert. @Joachim: Vielen, vielen Dank für die ausführliche Erklärung! Das hilft mir echt weiter! Du hast also auch keine F-Theta Linse drin? Und die Belichtung funktioniert bei dir? Da würde mich interessieren, was du für eine Laserdiode drin hast. Ich habe eine mit 405nm drin. Aber den Fokus bekomme ich so nicht hin. Liegt das an der Diode oder an der Linse die den Laser fokussieren soll? Habe ich da vielleicht eine falsche Linse drin? Das wäre toll, wenn du da noch ein paar Worte verlieren könntest. Wie bekomme ich die Schärfentiefe heraus, die ich in meinem System habe. Da wird ja der Fehler bei mir liegen. Grüße, Jens
Jens W. schrieb: > Du hast also auch keine F-Theta Linse drin? Und die Belichtung > funktioniert bei dir? Da würde mich interessieren, was du für eine > Laserdiode drin hast. > Ich habe eine mit 405nm drin. Aber den Fokus bekomme ich so nicht hin. > Liegt das an der Diode oder an der Linse die den Laser fokussieren soll? > Habe ich da vielleicht eine falsche Linse drin? > Das wäre toll, wenn du da noch ein paar Worte verlieren könntest. > Wie bekomme ich die Schärfentiefe heraus, die ich in meinem System habe. > Da wird ja der Fehler bei mir liegen. Nein, ich habe keine F-Theta Linse. Allerdings ist bei mir das Linsensystem etwas komplizierter, weil ich variabel fokussieren will. Ich gehe von einem möglichst parallel kollimierten Strahl aus. Dazu reicht der Standardkollimator der Diode. Auf möglichst große Entfernung möglichst klein fokussiert ergibt den bestmöglich parallelen Strahl. Dann gehe ich auf eine Kombination aus 2 Linsen, durch deren Abstand zueinander ich den Fokus einstellen kann. Bei mir 1. Linse f30mm und 2. Linse f80mm. Bei mir ist aber der Fokusabstand mit 500 - 1200mm lang. Du müsstest eine andere Brennweitenkombination nehmen, um kürzer zu fokussieren. Die zweite Brennweite (bei mir 80mm) bestimmt, wie nah fokussiert werden kann. Die Crux dabei ist, dass diese Linse so groß sein muss, dass auch bei der größten Entfernung zur ersten Linse (= minimaler Fokusabstand) der Lichtkegel noch draufpasst. Das muss je nach gewünschter Fokuslänge ermittelt werden. Langbrennweitige Linse sind von Natur aus größer, aber die Einstellwege und Abstände werden dann teilweise enorm. Wenn es bei einem festen Fokus z.B. 300mm bleibt, kann man den kollimierten Strahl auch mit nur einer 300mm Linse fokussieren. Den Fokus kann man dann nährungsweise berechnen mit Fokus = 1,27 x f(Linse) x Wellenlänge / Durchmesser Eingangsstrahl. Wenn der kollimierte Eingangsstrahl 2,5mm Durchmesser hat und die Linse 300mm bei 405nm Wellenlänge, dann Fokus = 1,27 x 300mm x 0,000405mm / 2,5mm = 0,061mm. Das ist aber ein idealer Wert, den man durch die Strahlcharakteristik der Diode nicht erreicht. Das würde hier den Rahmen sprengen. Man erreicht in der Praxis einen Wert irgendwo zwischen dem doppelten und dem berechneten, also ca. 0,1mm. Das wären dann ca. 250 DPI Auflösung. Die Schärfentiefe DOF ist annährend 2,55 x Wellenlänge x (Brennweite / Eingangsstrahldurchmesser)2 Also (Brennweite / Strahldurchmesser) zum Quadrat! Also in dem Fall 2,55 x 0,000405mm x (300mm / 2,5mm)2 = 2,55 x 0,000405mm x 14400 = 14,8mm Das ist der Bereich um den Fokuspunkt, bei dem der Spot maximal 1,4fach aufgeweitet wird. Da die Brennweite fest ist (durch den Arbeitsabstand) kann der Fokusdurchmesser nur durch die Dicke des Eingangsstrahls verändert werden. Dies erreicht man durch ein Teleskop. Aber: Die Schärfentiefe sinkt im Quadrat dazu! Wenn Du den Strahl 2fach aufweitest erreichst Du zwar einen halb so großen Spot, aber nur ein Viertel der Schärfentiefe. So. Nun musst Du erstmal Deinen Aufbau durchgehen und Deine Daten bestimmen. Also welche Abstände, welcher maximale Ablenkwinkel der Galvos usw. Dann heisst es rechnen, rechnen, rechnen. Mit der extrem kurzbrennweitigen Kollimatorlinse (ca. 5-8mm) auf eine große Distanz 300mm zu fokussieren, kann nicht gehen. Du erreichst damit nur ein sehr vergrößertes Abbild des Emitters. Das kann mit dem einfachen Abbildungsgesetz erklärt werden. Das Verhältnis der Gegenstandsweite zur Bildweite ergibt den Abbildungsmaßstab. Angenommen Deine Linse sitzt 6mm nach der Diode und der Fokus ist 300mm weg, dann ist die Vergrößerung 300 / 6 = 50. bei einem 10µm Emitter wäre der Spot dann schon 0,5mm groß. Selbst bei einem 3µm Emitter wären es mit 0,15mm mehr als mit dem obigen Verfahren. Die Schärfentiefe kann ich Dir da gar nicht sagen, weil alle obigen Berechnungen von einem Parallelstrahl, im Idealfall von einem Gaußstrahl, ausgehen. Gruß Joachim
Besten Dank Jens. Wo pack ich die config_DAC_8562 und die int_DAC_SPI rein? @Joachin, Respekt, da kennt sich einer aus mit Optik.
Hallo, vielen Dank für die ausführliche Erklärung. Da haben wir wohl beide das Ziel. Da geh ich meinen Aufbau vielleicht doch nochmal an. Ich mach mal Fotos, wie das aussieht. @TotalH Das packst du in dein Projekt rein. Nimm den normalen Arduino Mega. Der ist billig und lade dir GRBL. Dann ersetzt du in der Interrupt Routine die Zeile mit den DAC-Funktionen. Und die DAC.c und .h packst du ins Hauptverzeichnis. Und wenn sich die Galvos dann steuern lassen, dann würde ich mir an deiner Stelle erst Gedanken machen welches Board und wie man das schnell bekommt. P.S.: Den G-Code erzeuge ich mit LASERGRBL. Grüße, Jens
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.