Hallo Gemeinde,
Da ich mich, wie ihr wahrscheinlich auch, immer über meine
Laser-Folien-Belichtungs-Ausdrucke ärgere und sowieso immer x Ausdrucke
vom ersten Typen bis zur lauffähigen Maschine brauche, fand ich die Idee
in diesem Beitrag sehr interessant
Beitrag "UV-Laserdrucker"
Aber so einfach dürfte es nicht sein, da es keinerlei Korrekturoptik für
die winkelabhängige Position des Laserpunktes gibt. Zumindest keine, die
ich sehen kann. Super Idee, mechanisch problemtaisch. Aber es
funktioniert.
Es scheint generell drei Ansätze für das Problem zu geben:
1. Laserdiode an einem Plotter und "Isolierbelichten".
2. Laser an einem Plotter/Koordinatentisch und zeilenweises Belichten
3. Belichten über einen Polygonspiegel.
Alle drei Varianten haben ihre Vor- und Nachteile.
Ich würde mich gerne an der dritten Version versuchen.
Ich sehe zur Zeit 2 Probleme für die Strahlaufbereitung.
1. Kolimation und Profilkorrektur. Das geht nur per Optiken. Hier sind
viele Korrekturen nötig. Nicht zuletzt durch die Profilformveränderung
in Abhängigkeit vom Auftreffwinkel am Polygonspiegel.
2. Korrekur zwischen dem äquidistanten Pixelabstandes des Layouts zum
winkelabhängigen Ortes des Laserpunktes auf der Platine.
Als erste Annahme gehe ich von einer Auflösung von 1000-1200dpi aus. Je
nach Drehzahl des Polygonspiegels und der Spiegelflächenanzahl komme ich
bei einer möglichen Belichtungsfläche von Din A4 über den Daumen auf
eine Datenrate von bis zu 1MBit/s. Ganz grobe Schätzung. Aber das ließe
sich machen.
Meine Überlegung ist nun, wie ich hier eine Ortskorrektur anbringen
kann. Bei gleicher Austaktung liegen die Punkte in der Belichtungsmitte
näher zusammen als am Rand. CPLDs/FPGAs können ja sehr schnell Daten
schieben und haben schnelle Zähler. Wäre es nicht möglich das Bild des
Layouts entweder komplett oder zeilenweise in einen kleinen Ram
abzulegen und den CPLD/FPGA diesen mit Hilfe von Zählern zeit- und damit
ortskorrigiert an die Laserdiode auszugeben? Also am Rand hohe
Ausgaberate, geringe Zählerdauer, in der Mitte geringe Ausgaberate, hohe
Zähldauer?
Ich bin in diesem Gebiet noch vollkommen neu. Aber seht ihr hier
eventuell eine Möglichkeit? Wenn ja, so werde ich mich da mal
einarbeiten.
Mit Gruß
Mike
Es gibt noch eine weitere Möglichkeit, das Problem zu lösen:
Moderne billige Laserdrucker verwenden keine Polygonspiegel
mehr, stattdessen kommen UV-LED-Belichter zum Einsatz (sehen
aus wie die Zeilenscanner in einem Billigscanner). Bei denen
ist der Abstand untereinander immer gleich (auf X-Achse),
der Abstand auf der Y-Achse ebenso, "gute" Mechanik
vorausgesetzt. Im Netz gab's zu diesem Ansatz auch schon
Beispiele.
Aus einem Farblaser von HP habe ich mal die 4 LED-Belichter
ausgebaut und angesteuert. Ist relativ einfach.
Hallo Sigi,
ich kannte dieses Prinzip von einigen Scannern. Und wo da das sagst
fällt mir ein, dass ich auch vor langer Zeit mal einen LED-Drucker
hatte. Hat aber nicht lange gehalten, war aber zu der Zeit wahnsinn :)
Der lief aber mit IR-Leds. Blau- oder UV-Leds gabs da noch gar nicht.
Hast du eine Idee, wo ich solch eine Zeile her bekommen könnte? Wieviel
Leistung gibt die einzelne Led etwa ab? Wie groß ist denn die Auflösung
der Zeile, also wieviele Leds pro Zoll sind denn da verbaut? Wie hast du
die Zeile angesteuert bekommen?
So eine Zeile würde sehr viel Arbeit sparen. Eine stabile Mechanik
sollte machbar sein.
Ich würde mich sehr über eine Antwort von dir freuen. Mit dem Ansatz
könnte was draus werden
Mit Gruß
Maik
Maik schrieb:> Meine Überlegung ist nun, wie ich hier eine Ortskorrektur anbringen> kann. Bei gleicher Austaktung liegen die Punkte in der Belichtungsmitte> näher zusammen als am Rand. CPLDs/FPGAs können ja sehr schnell Daten> schieben und haben schnelle Zähler. Wäre es nicht möglich das Bild des> Layouts entweder komplett oder zeilenweise in einen kleinen Ram> abzulegen und den CPLD/FPGA diesen mit Hilfe von Zählern zeit- und damit> ortskorrigiert an die Laserdiode auszugeben? Also am Rand hohe> Ausgaberate, geringe Zählerdauer, in der Mitte geringe Ausgaberate, hohe> Zähldauer?
Grundsätzlich ja. Aber ein gescheit dimensionierter Controller müsste
das auch packen können (So machen das die Laserdrucker ja auch).
Eine andere Variante ist, dass du das gar nicht live machst. Die
Ortskorrektur ist ja immer gleich und bekannt, die Ortskorrektur
könntest du (mit genügend Speicher im Drucker) ja auch schon vor dem
Druckvorgang ausrechnen. Innerhalb des Druckers oder gleich auf dem viel
schnellerem PC.
Maik schrieb:
>.. Hat aber nicht lange gehalten, ...
schade, aber eben dieses Prinzip sorgt dafür, dass weniger
Mechanik verbaut werden muss (=> evtl. längere Haltbarkeit).
>Der lief aber mit IR-Leds. Blau- oder UV-Leds gabs da noch gar nicht.
ich kann dir leider nicht mehr sagen, in welchem Spektrum meine
arbeiteten, ich glaube mich noch an ein leicht bläuliches Licht erinnern
zu können. Die einzelnen Pixel habe ich mit einer SW-Industriekamera
überprüft (erkennt IR wie auch UV), von daher kann auch IR möglich sein
(dann scheidet die Platinenbelichtung natürlich aus :( )
>Hast du eine Idee, wo ich solch eine Zeile her bekommen könnte? ..
ich habe meine aus einem teureren HP-Color-Laserprinter vom Sperrmüll.
Aber schau mal bei EBay nach Defekten bzw. Gebrauchten nach. Nähere
Angaben zum Hersteller der LED-Leiste kann ich dir nicht geben,
auf der Platine ist nur eine Nummer aufgedruckt.
Such aber mal nach "Laserprinter LED Array", da findest du genug Infos.
(z.B. ist über dem LED-Array ein Linsen-Array, dass das Licht relativ
abstandsunabhängig auf dem Papier bündelt (=> keine Korrektur nötig!).
Hallo,
@ Christoph
ja, das stimmt. Die Korrektur über die Zeile ist eine invariante
Funktion. Meine Überlegung war, dass die Austaktung der korrigierten
Bildinformation sehr schnell erfolgen muss, will ich eine brauchbare
Auflösung erreichen.
Zudem würde eine Korrektur hinsichtlich der Zeit (also des Winkels) eine
deutliche Vergrößerung der Datenmenge mit sich bringen (entweder
verbreitere ich das Bild oder ich liefere für jedes Pixel
Zeitinformationen bei der Initialisierung). Beim ersten bräuchte ich
einen Speicher und eine schnelle Austaktung zur LED. Beim zweiten einen
kleineren Speicher und zuverlässige Timer.
Mache ich das zeilenweise, so ginge es auch über USB, seriell, parallel
etc. Soll das Ganze schnell laufen, so würde ich das gesamte Layout
gerne vollständig in einem extra Speicher halten.
Über einen uC... zumindest die Atmegas lassen eine Austaktung an
I/O-Pins nicht über 1MHz zu. Zudem habe ich feststellen müssen, dass
Interrupteinsprünge durch Timer unter C nicht immer 100% richtig sind.
SPI ginge, wäre aber nicht zu timen. Mit STM32 habe ich noch keine
großen Erfahrungen.
Daher meine Frage, ob FPGA/CPLD hier sinnvoll sein könnten. Da alles
"hardwaremäßig" codiert ist, sollten die Timer schnell und zuverlässig
sein. Ebenso ist die Taktrate an den I/O-Pins viel höher als an Atmegas.
@Sigi
bei meinem Drucker leuchtete da nichts :)
Dann werde ich mich mal auf die Suche begeben. Konkretes zu solchen
Zeilen konnte ich bisher noch nicht finden.
Mit Gruß
Maik
@Maik (Gast)
>ja, das stimmt. Die Korrektur über die Zeile ist eine invariante>Funktion.
Eben, das ist konstant und kann leicht vorausberechnet werden.
> Meine Überlegung war, dass die Austaktung der korrigierten>Bildinformation sehr schnell erfolgen muss, will ich eine brauchbare>Auflösung erreichen.
Daszu braucht man nur ein etwas schnelleres Schieberegister und etwas
Logik bzw. etwas RAM/ROM, Genau das, was in einem FPGA oder CPLD
drinsteckt.
>Zudem würde eine Korrektur hinsichtlich der Zeit (also des Winkels) eine>deutliche Vergrößerung der Datenmenge mit sich bringen (entweder
Das kann man in Echtzeit erzeugen, spart viel Speicher und
Transfervolumen.
>Über einen uC... zumindest die Atmegas lassen eine Austaktung an>I/O-Pins nicht über 1MHz zu.
Stimmt so nicht, wenn es sein muss, gehen bis zu 10 Mbit/s per SPI oder
so.
>Zudem habe ich feststellen müssen, dass>Interrupteinsprünge durch Timer unter C nicht immer 100% richtig sind.
Das geht nhier natürlich nicht, selbst mit ASM wird es sportlich.
>Daher meine Frage, ob FPGA/CPLD hier sinnvoll sein könnten.
Ja.
> Da alles>"hardwaremäßig" codiert ist, sollten die Timer schnell und zuverlässig>sein. Ebenso ist die Taktrate an den I/O-Pins viel höher als an Atmegas.
Ja. Z.B. könnte man per SPI eine Zeile Daten in den FPGA/CPLD laden und
der gibt die dann verzerrt über den Polygonspiegel aus, quasi als
Coprozessor.
Hallo Falk,
genau so hatte ich mir das gedacht. Ich habe gestern das Ganze mal als
Skizze zu Papier gebracht und spätestens für den Datentransfer vom PC
zum Belichter würde dann ein uC fällig werden. Auch die Koordination von
Leiterplattenpositionierung, Datenübertragung, Timing des
Lasers/Polygonspiegel etc. müsste zentral gesteuert werden.
Btw... das eine Austaktung an einem Atmega über den SPI auch jenseits
der 1MHz möglich ist, hatte ich geschrieben. Nur kann ich da keinen
Timer ansetzen :).
