Stellzeit von Galvos messen, wie?

[P51D]

Hallo miteinander

Im Zuge eines kleinen selbstgebauten DAC möchte ich mal sehen, wie schnell sich die Galvos nun stellen, da mich die Zeit zwischen der MCU-Pegeländerung über die DAC's weiter zu den OpAmps und dann über den Treiber zu den Galvos interessiert. Wie kann ich einfach diese Zeit herausfinden, respektive gibts eine Feedbackleitung die vom Galvo kommt und bedeutet "OK, gestellt"? Die Feedbackleitung zu den Treibern ist über Phototransistoren und Stromsumme gelöst (soweit ich weiss) aber ich möchte nur ungern einfach einmal ein KO anschliessen und schauen, ob ich etwas auf dem Bildschirm habe.

Besten Dank für die Infos

MFG
P51D

P.S.: Ich hoffe, ich bin hier im richtigen Forum gelandet, da ich kein passenderes gefunden habe.

[thomasf]

Hi,

na dann miss doch die durchlaufzeit vom DA wandler bis zum galvo feedback mit einem 2 kanal speicherozi.

mfg

thomas

[P51D]

tja, nur sollte ich jetzt noch wissen, wo ich das Feedback Signal abgreifen kann (Litrack Treiber).
Den einen Kanal schliesse ich an die Select-Eingänge der DAC's und der andere müsste ich an das Feedback anschliessen. Ich gehe mal von der Annahme aus, dass bei dem Treiber-Regelkreis das Feedback gleich dem Input-Signal ist, wenn die Galvos die Endstellung erreicht haben.

[thomasf]

Hi,

frag doch mal jojo wo das feedback signal bei dem treiber anliegt. sollte aber mit dem ozi auch nicht so schwer zu finden sein. bzw durch scharfes hinsehen

aber wofür soll das gut sein? ich geh mal davon aus das du d/a wandler mit einem spi verwendest, mit welcher frequenz schickst du denn die daten rein?
aber da kannst du eh nichts mehr optiemieren also wofür brauchst du diese zeit? am längsten dauert es wohl bis das galvo die soll position erreicht hat, alles andere läuft sicher im ns bis µs bereich ab.

thomas

[P51D]

Die DAC's werden parallel angesteuert. Mir gehts eigentlich nur um die "Wartezeit" bis ich die neuen Punkte auf die DAC's setzen kann, damit der vorhergegangene Punkt sicher angefahren wurde.
Ich kann ja nicht ein Quadrat mit maximaler Ablenkung abfahren und dabei alle 1us ein neuer Punkt ausgeben. So kriege ich höchstens etwas in der Art eines Kreises/Elypse da die Galvos schon verfrüht einen neuen Punkt bekommen haben.

ok, Ich werde dann mal eine PM an jojo schicken.

Danke für die Antworten
MFG
P51D

[thomasf]

daher gibt es ja auch die einstellung pps, also wieviele Punkte in einer Sekunde angefahren werden sollen.
Dies ist natürlich von frame zu frame unterschiedlich.

Punkte die sehr nah beieinander liegen kann man viel schneller anfahren als solche die jeweils im maximum liegen, sollte klar sein.

daher nützt dir die ermittung der zeit rein garnichts, da sie bei jedem angefahrenen punkt anders ist. bei einem quadrat beispielsweise werden auch nicht nur die 4 ecken angefahren, dafür sind heutige galvos viel zu schnell, man würde nur die eckpunkte sehen. dazwischen interpoliert man zusätztliche punkte um dann dieses frame mit beispielsweise 20kpps auszugeben.

also vergiss deinen ansatz am besten gleich wieder.

Thomas

[P51D]

mhm, soweit ich als Elektroniker weiss, MÜSSEN die Punkte zwischengespeichert werden, da sonst das Windows oder was auch immer für ein Betriebssystem mekern würde, da zum Beispiel USB nur alle 1ms die so genannten Endpoints abfragt (also bei 30kpps müssen mindestens 30 Punkte mit sämtlichen Informationen auf dem DAC zwischengespeichert werden). Daher muss ein DAC die Punkte aus einem Buffer lesen und diese dann ausgeben. Jetzt muss doch der DAC aber wissen nach welcher Zeit er der Nächste Punkt ausgeben darf, oder nicht?

Das weitere Punkte Interpoliert werden, ist mir klar, und dass je nach Software auch noch die Eckpunkte erhöht werden auch.

Punkte die sehr nah beieinander liegen kann man viel schneller anfahren als solche die jeweils im maximum liegen, sollte klar sein.
....

Falls du es bis jetzt noch nicht gemerkt hast, genau das ist der Grund, wieso ich die Zeiten bei unterschiedlichen Abständen messen möchte, und diese dann als valriable Delay-Tabelle im MCU verwenden möchte.

Ich weiss ja nicht genau, wie das bei den Handelsüblichen DAC's für Laserprojektoren aussieht, aber ich denke, dass dies genau gleich gemacht wird, da sonst die DAC's weder Betriebssystem- noch Standartkonform sind.

Ich weiss nicht, ob ich dir langsam auf die Nerven gehe (könnte ich mir gut vorstellen), aber ich habe das Gefühl wir reden an einander vorbei.

Dennoch, besten Dank für die Hilfe
MFG
P51D

[jojo]

Das Problem, welches ich sehe:
Wenn Du sogenannte "Stützpunkte" an den Linien, also NICHT nur die Eckpunkte in Dein Konzept einbeziehst, dann bekommst Du immer eine Linie mit hellen Punkten.
Denn Du willst ja bei jedem Punkt warten, bis er erreicht ist.
In der Praxis wird eben nicht gewartet, sondern der Punkt quasi "überfahren".
Also bevor er erreicht wurde, gibts auf SOLL schon die Position für den nächsten Punkt.

Ein Auswerten,ob ein Punkt erreicht ist, macht nur bei statischen Punkten Sinn, aber nicht wenn sich das Galvo noch in der Bewegung befindet.
Während der Bewegung eilt die Istposition der Sollposition ständig hinterher.
Mess einfach mal bei einem Dreieckssignal 100Hz auf dem Scanner Soll- und Istsignal und Du siehst, was ich meine. Je schneller das Signal, desto größer die Phasenverschiebung.
Wenn Du also keine Phasenverschiebung haben willst, also immer warten, bis die Position erreicht ist, dann wird Deine Ausgabe unglaublich langsam.

Joachim

[P51D]

ah, ok.

Wie wird das den bei den käuflichen DAC's gelöst? Wird da noch eine Zusatzinformation über Status bei ILDA mitgeliefert, ob bei diesem Punkt gewartet werden muss, oder ob dieser nur überfahren wird?

Wenn die IST Position immer der SOLL Position hinterher läuft, so würde im Extremfall ein Quadrat runde Ecken bekommen.

des weitern müssten die Hilfspunkte dann etwa im gleichen Zeitabstand angefahren werden, aber wenn ich von Links nach Rechts eine Linie fahre und dann in der Hälfte schon alle Stüzpunkte ausgegeben wurden, weil der MCU zu schnell ist, erfüllen die Hilfspunkte ihren Zweck auch nicht mehr.

Besten Dank für den Hinweis
MFG
P51D

[jojo]

Wie wird das den bei den käuflichen DAC's gelöst? Wird da noch eine Zusatzinformation über Status bei ILDA mitgeliefert, ob bei diesem Punkt gewartet werden muss, oder ob dieser nur überfahren wird?

Nee, keine Zusatzinformation. Die Ausgabe (Software -> DAC) läuft nicht closed loop.
Jeder Punkt wird gleich schnell ausgegeben. Ecken werden eben mehrfach ausgegeben.
Das entscheidet dann die Software.

Wenn die IST Position immer der SOLL Position hinterher läuft, so würde im Extremfall ein Quadrat runde Ecken bekommen.

Ja genau so ist es auch. Wird zu schnell gescannt bzw. die Eckpunkte auch nur 1mal, dann wirds rund.
Willst Du dort richtige Ecken sehen, dann werden auch die Stützpunkte bereits sichtbar (als helle Stellen).

des weitern müssten die Hilfspunkte dann etwa im gleichen Zeitabstand angefahren werden, aber wenn ich von Links nach Rechts eine Linie fahre und dann in der Hälfte schon alle Stüzpunkte ausgegeben wurden, weil der MCU zu schnell ist, erfüllen die Hilfspunkte ihren Zweck auch nicht mehr.

So schnell darf die Ausgabe eben nicht sein.
Bei 30Kpps eben ein Punkt alle 33us. Der Abstand der Stützpunkte ist auch ein wichtiger Parameter. Lässt sich ja mit jeder Software unter "Interpolationsabstand" einstellen.
Je nach Geschwindigkeit des Galvos eilt dieses ca. einem bis vier Punkten hinterher.
Bei Eckpunkten, die vielleicht 4, 5 oder 6mal ausgegeben werden, "holt" die Galvoposition den Punkt quasi ein und verweilt daher für 2 bis 4 Punkt dort.
Ein mittelschnelles Galvo hat eine Verzugszeit von ca. 50 bis 100us, also wenn die Software bereits 2 bis 4 Punkte ausgegeben hat, "steht" das Galvo immer noch an der Verweilposition, bis es sich in Bewegung setzt.

Ein weiterer Punkt, den Du berücksichtigen musst, ist das sogenannte "Blank-" oder "Colourshifting".
Wenn Du beim Ausgeben eines Punktes die Farben änderst, dann wird diese Information an der falschen Stelle aktiv, denn das Galvo ist ja noch gar nicht an der Position, wo die Farbe wechseln soll.
Im einfachsten Fall übernimmt die Kompensation die Software, indem sie die Farbinformation punktweise um X-Punkte nach hinten "shiftet" (um ca. die Verzugszeit des Galvos).
Der Nachteil ist, dass man beim Ändern der Punktfrequenz diesen Wert ständig nachjustieren muss.
Die Verzugszeit des Galvos ist fix, die Punktfrequenz (pps) aber variabel.
Besser ist eine feste Verzögerungszeit für die Farben. Das lässt sich aber nur hardwareseitig auf dem DAC realisieren (z.B. wie bei der NetLase ). Dann bleibt das Colourshiftig stabil, egal wie schnell man scannt.

Joachim

[P51D]

OK, danke vielmals. Jetzt wird einiges klarer.

Willst Du dort richtige Ecken sehen, dann werden auch die Stützpunkte bereits sichtbar (als helle Stellen).

oder auch nicht. Die Stützpunkte werden normal abgefahren und dann werden die Eckpunkte erhöht => nur die Ecken scheinen heller oder habe ich jetzt etwas falsch aus dem Zusammenhang gerissen?.

Bei 30Kpps eben ein Punkt alle 33us.

Wenn ich dich jetzt richtig verstanden habe, dann werden alle Punkte, egal welcher Abstand und ob Eckpunkt oder nicht in einem 33us Abstand angefahren. Bei einer Framerate von 30 wären das dann 1000 Punkte pro Frame, bevor es anfängt zu flackern.

Die Verzugszeit des Galvos ist fix, die Punktfrequenz (pps) aber variabel.
Besser ist eine feste Verzögerungszeit für die Farben. Das lässt sich aber nur hardwareseitig auf dem DAC realisieren (z.B. wie bei der NetLase ). Dann bleibt das Colourshiftig stabil, egal wie schnell man scannt.

Das wiederum ist nicht so schwer Hardware-Seitig zu realisieren. => DAC's neu setzen, Xus warten und erst dann Farbe ausgeben. Da brauche ich nur 2 Timer und schon wäre das gelöst.
Die Verzugszeit der GAlvos ist aber nur bei dem momenat verbauten Galvo so, bei einem andern müsste dies ebenfalls nachjustiert werden, oder? Also am besten über ein Trimmer.

Nochmals besten Dank für die Beratung
MFG
P51D

[thomasf]

Hi,

mal eine andere Frage zu deinem Projekt, mit was willst du das Aufbauen. Also was verwendest du als Hardware? µC DA Wandler, usw.

MfG

Thomas

[P51D]

mhm ok...

Kontroller-Teil:
- FT245 als USB Wandler
- dsPIC30F6012A für die ganze Kontrolle (20MHz Quarz, wird intern auf 128MHz erhöht)
- AD7945 12Bit DAC
- TL084 OpAmps für die Gegentakt-Stuffe
- 4 LEDs (Rot, Blau, Grün, Orange)
- 4x20 Segment LCD

Kleine Onboard-Savety:
- 74HC4538 retriggerbare FlipFlops, die mir die Laser durchschalten, oder nicht, wenn keine Pegeländerung mehr vom MCU kam (irgendwo hängengeblieben)
- AND Tore

Speisung:
- MC7808 für +8V bei den OpAmps
- MC7908 für -8V
- TEN 4-4811 für 5V DC/DC Wandler

Temperaturüberwachung des ganzen:
- PIC16F687
- NTC Widerstände als Sensoren
- PWM Lüfter

Laserdiodentreiber:
- FDC6327C (konnte mir die Rote Laserdiode sauber bis 130kHz schalten. Ev noch höher aber nicht getestet)

Klingt jetzt nach viel, aber 98% von dem was ich verbaut habe, war gerade so zur Hand (uC's, LCD, Lüfter, DC/DC Wanlder).

Zuerst hatte ich das ganze auf einem 8Bit Atmel aufgebaut, aber dann merkte ich schnell, dass ich Geschwindigkeitsprobleme habe. Jetzt mit dem 16Bit Prozi habe ich nur von der DAC und Lasersteuerung eine Durchlaufszeit von unter 700ns (und das in C geschrieben !!). Bei sämtlichen Funktionen mit parallelem Buffern und Ausgeben der Laser-Settings und LCD-Kontrolle bin ich bei etwas über 6us Durchlaufszeit.

Eine Savety-Auswertung wäre eventuell auch noch möglich, aber nicht geplant.

Einziges Problem bis jetzt ist, dass ich naiv wie ich bin die Laser über PWM gedimmt habe -> gestrichelte Linien bei schneller Fahrt.

Falls noch was unklar sein sollte, oder sonst noch Fragen bestehenm, kannst du die gerne stellen.

MFG
P51D