Forum: Mikrocontroller und Digitale Elektronik Problem mit Positionsrückmeldung bei GRBL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hat keiner eine Idee?

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus H. (Firma: privat) (klaus777)


Bewertung
0 lesenswert
nicht lesenswert
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

von sven (Gast)


Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von n.b. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jens W. schrieb:
> Galvos sind ...

... kaputtgesparte Galvanometer
https://de.wikipedia.org/wiki/Galvanometer

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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

von jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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...

von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Bei mir sieht das so aus:

von Klaus H. (Firma: privat) (klaus777)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jens W. (jensw)


Bewertung
1 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
Hi Julian,

kommst du voran? Funktioniert dein DAC jetzt?

Gruß, Jens

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus H. (Firma: privat) (klaus777)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus H. (Firma: privat) (klaus777)


Bewertung
1 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Klaus H. (Firma: privat) (klaus777)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Helmut -. (dc3yc)


Bewertung
0 lesenswert
nicht lesenswert
Heisst das Programm wirklich Incscape oder vielleicht Inkscape?

von Klaus H. (Firma: privat) (klaus777)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Helmut,
Ja.
Da hatte sich ein Fehler eingeschlichen.
Vielen Dank an die Autokorrektur von Android ,-)
Grüße

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Julian H. (kiwi85)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus H. (Firma: privat) (klaus777)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von Klaus H. (Firma: privat) (klaus777)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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")

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Das DAC Modul währe das hier:
Ebay-Artikel Nr. 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

von Jens (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Joachim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
TotalH schrieb:
> Wie gesagt ich hab noch ESP32
> Boards rumliegen. Die könnte ich natürlich nehmen...

Nein das sind ESP8266 Boards...

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jens W. (jensw)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Joachim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von TotalH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jens W. (jensw)


Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.