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 :).
Ich denke auch, dass dass das eher eine Aufgabe für einen uC ist. Die Bandbreite des FPGa brauchts Du an der Stelle nicht.
Ich wuerd die Entzerrung der Geometrie ueber das Pixeltiming machen. Am Rand eine hoehere Pulsfrequenz. Ein moderner DDS kann das.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.