Lasergravieren, in welchem Zeitrahmen ist der Laserschuss sinnvoll ?

    Hi,
    Bin gerade dabei meinem Eigenbau Lasercutter das Gravieren beizubringen.


    Also der Modus, wo der der Laserkopf eine Dither Grafik Zeilenweise abfährt.
    Und den Laser in Abhängigkeit des Pixels kurz einschaltet oder eben nicht.


    Bin gerade am Testen mit 100µs pro Laserpixel auf dem Werkstück.
    Ist dies realistisch ? Klar hängt das jetzt wieder von der Leistung und Material ab.


    Aber es gibt mit Sicherheit Eckwerte bei den kommerziellen Maschinen.


    Insgesamt dauert der Gravierjob so sehr lange, weil die Verweilzeit des Laserkopfes die Bremsgröße ist.
    Oder gehe ich das Problem falsch an ?

    Ja, das dauert sehr lange.


    Ich gehe mal davon aus, du nutzt den Z-Achsen Befehl zum Auslösen des Lasers.


    Mit der Lösung dauert nen Bild ja ewig, weil der Gcode den Kopf erst in XY Position fährt und dann Z auslöst. Bei feiner Rasterung ist das ja die Hölle.



    Beim DSP Controller wird das alles in einem Rutsch während des laufenden Laserkopfes erledigt. Da ist der Unterschied zu einem GCode Controller und einer DSP Steuerung.


    Schneiden mit Gcode ist überhaupt kein Problem, aber gravieren, da kann man schon mal Alt und Grau werden.....


    Bevor ich mir das antun würde, würde ich eher in einen AWC Controller investieren um ganz ehrlich zu dir zu sein.



    Die Standart Röhre wird mit 20000 Hz betrieben, also müsste das dann die maximale Auflösung sein. Irgendwo hat das Diemo mal schön beschrieben, es sind glaub ich µsec.


    :pop:

    Gruß

    Michael


    Vom Handwerk kann man sich zur Kunst erheben. Vom Pfuschen nie.

    Johann Wolfgang von Goethe

    Zitat von Gewindestange

    Ich gehe mal davon aus, du nutzt den Z-Achsen Befehl zum Auslösen des Lasers.

    Nein, denn auch die Software ist ein kompletter Eigenbau.
    Der erste Teil (G-Code) läuft


    Nur beim Gravieren fällt mir keine andere Strategie als diese ein.
    Hier wird kein G-Code verarbeitet.
    Meine Software arbeitet hier im Raw Mode, fängt bei Pixel 0,0 an und arbeitet dann Zeilenweise ab.

    Zitat von Gewindestange

    Mit der Lösung dauert nen Bild ja ewig, weil der Gcode den Kopf erst in XY Position fährt und dann Z auslöst. Bei feiner Rasterung ist das ja die Hölle.

    Verstehe nicht wirklich, warum eine DSP Steuerung hier schneller sein soll.
    Weil der Laser braucht immer die gleiche Zeit um den Pixel im Material zu hinterlassen.

    hehe, ich bin ja jetzt davon ausgegangen, du nutzt den GCode Befehlssatz.


    Hier wird für ein scanning die Z-Achse benutzt, also minimal der Turm bewegt ( Z -0.0001 , schuß, Z 0.0000 )


    Das dauert ewig :)

    Gruß

    Michael


    Vom Handwerk kann man sich zur Kunst erheben. Vom Pfuschen nie.

    Johann Wolfgang von Goethe

    Kann jetzt sein, das ich komplett falsch liege, aber warum gehst du das Problem nicht folgendermaßen an -


    Den Laser auf Dauerfeuer und in Abhängigkeit von der Z Info die Intensität geregelt. Steht doch eh im GCode wenn sich Z ändert. Das Einzige, worauf Du achten musst, ist das beim Richtungswechsel immer eine Laser off drin ist, sonst hast Du gleich ne schwarze Umrandung mit dabei.
    Vielleicht seh ich das ein bissl so wie "Fritzchen die weite Welt" sieht, aber ich seh da erstmal kein Problem. Im Gegenteil, ich kann sogar noch eine 3. Ebene bearbeiten, wo bei einem DSP Controller nur 2.5 Ebenen drin sind.

    Zitat von Gewindestange

    Das dauert ewig :)

    Es dauert auch bei meiner bisherigen Strategie ewig, im Kontext der DPI Auflösung der Grafik und der Mechanik ist jeder Pixel der Grafik 19x19 Steps !
    Dann ist die Gravur genau so groß wie die Vorlage.
    Selbst bei kleinen Bildchen entstehen riesige Datenmengen.


    Ich fahre schon bidirektional, Lasere also auch im Rückweg des Laserkopfes die nächste Zeile.
    Trotzdem ist das ganze für größere Gravuren ungeeignet.


    Muß mir dem Ansatz von skdx überlegen, das Problem ist, das ich meinen G-Code Teil ohne Z-Achse umgesetzt habe.
    Das noch einzubauen wäre ein Riesenaufwand.

    Hallo,
    Habe nun meinen Algo optimiert komme auf etwa 300mm/s.


    Nun tritt ein anderes Problem auf.


    Und zwar beim Richtungswechsel muß gebremst bzw beschleunigt werden.
    Mit Vollgas die Rictung zu ändern tut nicht nur in den Ohren weh, sondern schädigt mit Sicherheit die Mechanik oder die Motoren.


    Ich habe diesen Algo drin: cos((1.5/rampenbreite)*x)^ 2 * rampenhöhe


    x ist die Position des Laserkopfes einer Zeile. Für das Bremsen kommt die selbe Funktion mit den Sinus zum Einsatz
    Mit 5 Einheiten breite und 5 Einheiten höhe zur Demo schaut die Funktion so aus.


    Nicht schlecht dachte ich erst.
    Doch was passiert jetzt: zwischen den Rampen rennt das Ding wie erwartet.
    Und jeweils am Ende wird gebremst/beschleunigt wie wenn er auf ein Kissen aufschlägt.
    Das ist auch das was ich erwartet hatte, nur geht hier viel Zeit verloren.
    Mache ich die Rampe schmäler reicht der Bremsweg nicht mehr aus, und es kommt wieder zu den harten Schlägen.
    Mache ich sie höher ist der Zeitverlust noch größer.


    Wenn ich mir die Videos von den Trotec Maschinen ansehe, der Laserkopf wechselt hier scheinbar aus hoher Geschwingkeit die Richtung ohne Zeitverlust und ohne harte Schläge.


    Hier noch ein schlechtes Handyvideo, man kann aber erkennen was ich meine.