Hallo Forum, ich versuche normal, meine Probleme selbst zu klären aber diesmal brauche ich Hilfe da ich absolut ratlos bin. Auch ich will meine Leiterplatten per Laser belichten, da mein guter alter HP-Deskjet das Zeitliche gesegnet hat. Am Anfang hatte ich folgendes Setup: - Präziser 3D-Drucker mit Marlin (V1.02) - Ansteuerung des Laser per M106/M107 (Pin D9 auf RAMPS 1.4) - 100mW/405nm Laser mit käuflichen TTL-Treiber (im Set gekauft) - BMP zu G-Code Konverter: Eigenprogrammierung Das Ergebnis war eine sehr gut belichtete Leiterplatte, mit "Störungen" drin (siehe Bild). Ok, Versuch Nr.1: Andere Software (Trialware aus dem Netz). Ergebnis: Exakt das Gleiche! Versuch Nr.2: Anderer Lasertreiber (Eigenbau mit FET und LM317). Ergebnis: Das Gleiche! Versuch N.3: Anderer Ausgabepin auf RAMPS. In Marlin von D9 auf D40 gesetzt und umgelötet. Ergebnis: Keine Änderung. Jetzt bin ich am Ende. Ich komme nicht mehr weiter. Könnte es an Marlin selbst liegen? Oder habe ich irgendwo ein Brett vorm Kopf? Was mich wundert, beim Testlasern auf Kassenbonrolle erkennt man (beim Druck von vertikalen Linien) dass die Störungen System haben, also regelmäßig passieren (siehe Bild). Nur macht mich das jetzt leider nicht schlauer. Den GCode für die Ausgabe der vertikalen Linien, hänge ich ebenfalls mal an. Bin für jeden Tipp dankbar. Einen schönen Restsonntag wünscht, Uwe
Angehängte Dateien:
-
pcbdemo.jpg
62 KB -
Leiterbahnen.jpg
140 KB
Es gibt Online GCode-Viewer, ersetze vorher alle M107 gegen G01 Z0 und alle M106 gegen G01 Z1, sonst siehst Du nichts im Viewer. Hast Du das gemacht, dann ist erkennbar dass das GCode-File einwandfrei ist. Wenn's also nicht die Software ist, wird's wohl die Hardware sein. Es könnte der Lüfterausgang gering priorisiert sein, was für die ordentliche Funktion eines Lüfters ok wäre. Die Plots sehen so aus, als ob das Signal des D9 den TTL-Treiber zufällig mit Verzögerung ansteuert. Füge nach jedem M106/M107 testweise ein Dwell mit G4 P200 ein. Evtl. beeinflusst die Treiberstufe bestehend aus Mosfet STP55N das D9-Signal, mal D8 oder D10 alternativ versuchen. Auch nach der Treiberstufe könnte man ein TTL-Signal abgreifen, einen 1k5 Widerstand von P$4 nach GND ergibt zusammen mit der Kontroll-Led und dessen Widerstand einen Spannungsteiler. An P§4 liegt jedoch ein invertiertes Signal an, also M106 und M107 tauschen.
Guten Morgen, vielen Dank für die Tipps. Leider habe ich diese schon komplett durch. Der Erste Versuch war direkt am Lüfterausgang D9 mit Widerstandsteiler. Der zweite Versuch D9 direkt am Arduino (vor dem MOSFET) abgegriffen. Der dritte Versuch war statt D9 den D40 genutzt (mit Marlin-Änderung in "pins.h" von 9 auf 40). Alles mit dem gleichen Ergebnis. Der Versuch mit dem Einfügen einer Pause (G4) habe ich auch schon durch (von 20-150mS). Ergebnis bleibt gleich oder verschlechtert sich weiter. Das gepostete Demo-GCodefile sieht in jedem GCode-Viewer perfekt aus, wenn ich M106/M107 gegen Z-Vorschub tausche. Für Tests habe ich das in meine Software mit eingebaut.
Interessantes Problem, lese ich gerne mit abo on
Hallo Uwe, ich hätte Interesse an deinem Konvertierungsprogramm bmp->gcode hab so einen kleinen Benbox Laser zu Hause würde damit gern mal ein smd layout Lasern was ich aber generell für besser halte wäre das Belichten der Isolationsstrecken und nicht zeilenweise alles man nicht benötigt
Kein Problem. Ist aber nur ein kleines Delphi Programm. Hänge es mal mit kompletten Quellcode hier rein. Sollte auch mit Lazarus statt Delphi funktionieren. Ich glaube die Art der Belichtung ist eher nebensächlich und dieses blöde Problem wird immer auftauchen, wenn ich den Fehler nicht finde. Was wirklich rätselhaft ist, das es ja irgendwie Struktur hat (sie Foto weiter oben).
Das könnte an den verwendeten Steppertreibern liegen, die kleinen A4988 und auch der DRV8825 vergessen gern mal Schritte.
Werner H. schrieb: > Das könnte an den verwendeten Steppertreibern liegen, die kleinen A4988 > und auch der DRV8825 vergessen gern mal Schritte. Kann ich nicht bestätigen, an meinem Bohr-Belichter habe ich 4 St. DRV8825 im Einsatz, da vergisst keiner Schritte.
Werner H. schrieb: > Das könnte an den verwendeten Steppertreibern liegen, die kleinen > A4988 > und auch der DRV8825 vergessen gern mal Schritte. Aber dann würde der Fehler ja nicht in der nächsten Zeil wieder verschwinden, sondern das komplette Bild dauerhaft verschoben werden. Für mich sieht das doch so aus, als würde der Laser teilweise zu spät ein- bzw. ausgeschaltet, oder nicht? Gibt's für M106/M107 vll. irgendeinen Parameter o.ä. der eine Verzögerung verursacht oder verhindert?
Überhaupt fehlt eine Information: Was ist das denn genau für ein 3D Drucker? Uwe D. schrieb: > Präziser 3D-Drucker mit Marlin (V1.02) genügt mir hier irgendwie nicht. Wenn unterschiedliche Software zum gleichen Ergebnis kommt kann es ja nurmehr an der Mechanik / Firmware liegen. Wie sieht das Muster aus, wenn du das Layout an einer anderen Stelle im Druckraum positionierst? Und: Was ist das für ein Drucker? Marlin als Firmware deutet auf Selbstbau / Bausatz hin. Was mir beim Betrachten der Bilder noch einfällt: ist da vielleicht irgendeine Retract Einstellung am wirken? (Marlin Grundeinstellung? Ich hab nicht alle möglichen Einstellungen im Kopf) Wie breit sind die Striche?
Nach Schrittverlusten sieht das ja auch nicht aus. Es gibt keinerlei Verschiebungen, wie bei Schrittverlusten. Es sieht so aus als wenn der Laser, einer bestimmten Regel folgend, länger an bleibt oder auch mal später an geht.
Kannst du mal den gcode für den Barcode anhängen? Da sieht man vll. eher, ob da schon was verschoben ist, als bei der Platine
Werner H. schrieb: > vergessen gern mal Schritte Hab mich da ein bischen unglücklich ausgedrückt, die Dinger konnen Schritte überspringen. Und danach siehts meiner Meinung nach aus. https://www.youtube.com/watch?v=JcRlM-UFq30
:
Bearbeitet durch User
Typ schrieb: > Kannst du mal den gcode für den Barcode anhängen? Das ist der GCode aus meinem ersten Post (Leiterbahnen.gcode)
Uwe D. schrieb: > Typ schrieb: >> Kannst du mal den gcode für den Barcode anhängen? > > Das ist der GCode aus meinem ersten Post (Leiterbahnen.gcode) Ah, alles klar, bin davon ausgegangen, dass das der gcode für die Platine ist. Gut, der sieht ja einwandfrei aus. Meine Vermutung ist ja die, dass Marlin die M106 und M107 nicht besonders hoch priorisiert ausführt (falls es sowas wie Priorisierung gibt), weil es bei einem Lüfter ja relativ egal ist, ob der nun 500ms später anläuft oder stoppt. Hast du eine Möglichkeit, den Ausgang mal aufzuzeichnen (Speicheroszi, Logic analyzer o. ä.)? Wenn da ein entprechender Jitter feststellbar ist, kann man ein Hardwareproblem ja eigentlich schonmal ausschließen. Wie lange sind denn die "Ausreißer" und welcher Zeit entspricht das?
Vll. kannst du ja mal mit der Option FAN_SOFT_PWM spielen. Also aktivieren oder deaktivieren, je nachdem.
Werner H. schrieb: > Hab mich da ein bischen unglücklich ausgedrückt, die Dinger konnen > Schritte überspringen. Und danach siehts meiner Meinung nach aus. Nein, wenn der Treiber einen Schritt verliert findet der den nicht bei der nächsten Zeile wieder, wie in den angehangenen Bildern. Sprich: dabei entsteht ein permanenter Versatz. Das ganze Bild wird schief gezogen. Danach sieht es nicht aus. Ich denke, "Typ" ist auf dem richtigen Weg: Ich würde hier auch bei der Priorisierung ansetzen. Die Frage ist, wie man das, ohne groß in die Firmware eingreifen zu müssen, umbauen kann. Eine Idee ist: Den Extruderausgang dafür zu nutzen. Der hat einen Direction und einen Step Ausgang. Wenn du nun die Steps so einstellst, daß ein Step die halbe laserbreite ist könntest du den Step Ausgang zum Triggern nehmen. Allerdings musst du dann deinen Linien immer in ganzzahligen Vielfachen dieser Mindestbreite machen, 3,5mal Laserbreite würde dann wieder zu Problemen führen.
:
Bearbeitet durch User
Uwe D. schrieb: > vielen Dank für die Tipps. Leider habe ich diese schon komplett durch. Diese Info hätte ich gern vorher gehabt. > Das gepostete Demo-GCodefile sieht in jedem GCode-Viewer perfekt aus, Um die letzte Möglichkeit eines schwer zu durchschauenden und im Viewer nicht sichtbaren Fehlers im Aufbau der Datei auszuschließen, würde ich diese händisch erzeugen. Also einen X-Block des .gcode nehmen, 20mal kopieren und den Y-Vorschub manuell einfügen. Von der Elektronikseite würde ich versuchen, Z-DIR (D48) für den den Enable des Lasers zu verwenden. Wenn Du Glück hast, ist der µC so programmiert, dass der diesen Pin nicht dauernd umeinanderwackelt, sondern sich nur ändert, wenn sich tatsächlich die Drehrichtung ändert. Statt eines M107 generierst Du dann eben ein G01 Z0.01, für ein M106 ein G01 Z0.00. Der Gedanke dabei ist, dass die Lüfteransteuerung ungenau sein kann und dennoch für den Zweck funktioniert, die Steuerung sämtlicher Achsen jedoch zwingend genau laut GCode erfolgen muss.
Es gibt ein 'M400', Wait for current moves to finish, sowas sollte vor dem Laser on/off gemacht werden. Und es gibt M42: Switch I/O pin, damit kann auch andere Pins verwenden. Das Argument ist die Pinnummer in Arduino Zählweise, das hatte mich viel Zeit gekostet bis ich das gefunden hatte. reprap.org/wiki/G-code
Angehängte Dateien:
-
LA-4-Zeilen.jpg
24 KB
Das mit dem händisch erzeugtem GCode-File werde ich als erstes Probieren. Danke. Habe auch neue Erkenntnisse. Und zwar habe ich die Daten vom Pin D40 (Laser) mittels Logikanalysator mitgeschrieben (bei Ausgabe von Leiterbahnen.gcode). Darin sieht man schön das Marlin auf jedem Fall diesen Müll ausgibt (ein Beispiel mit vier aufeinanderfolgenden Zeilen hänge ich als Grafik an). Mal sehen ob der manuelle Gcode Erfolg bringt. Wenn nicht, probiere ich noch den Tipp mit der Z-Achse bzw. wie ich das mittels Extrudersteuerung hin bekomme. Alles sehr eigenartig....
Ich erinnere mich, das sich Conny G. mit so einem Problem schon mal rumgeschlagen hat: Beitrag "Re: UV-Laserdrucker II" Beitrag "Re: UV-Laserdrucker II" Ich verwende LinuxCNC, da kann man Ports synchron zur Bewegung schalten: Beitrag "Re: Belichten von Platinen mit CNC-Fräse + UV-Laser"
So, wieder etwas getestet. Habe jetzt den M400 Befehl eingebaut, welches die Situation etwas verbesserte aber noch nicht das Problem beseitigt. Der Versuch, statt M106/M107 mit dem M42 einen Pin zu schalten, brauchte leider auch keinen Erfolg (habe mit M42 P42 S0 und S255 den Pin 42 genutzt). Der Hinweis das der Forenuser "Conny G." das gleiche Problem hatte, ist heiß. Leider verstehe ich diesen Lösungsansatz nicht so ganz. Vielleicht kann jemand seine Problemlösung so erklären, das man sie auch versteht, wenn man sich noch nicht mit der Firmwareprogrammierung beschäftigt hat. Schönen Abend noch, Uwe
Uwe D. schrieb: > Leider verstehe ich diesen Lösungsansatz nicht so ganz. Vielleicht liest Du einfach mal nach, was vor oder nach dem angegebenen Beitrag geschrieben wurde. Ein wenig über den Tellerrand schauen schadet nicht ...
Uwe D. schrieb: > Leider verstehe ich diesen Lösungsansatz nicht so ganz. Es ist so wie bereits vermutet, der Lüfter wir nicht synchron bedient. Es gibt dem verlinkten Thread zufolge einen Puffer in der Firmware, der mittels Interrupt bedient wird und MOVE-Befehle lädt. Der User Conny modifizierte die Firmware, so dass der Laser synchron beim Laden eines neuen MOVE betätigt wird. Du müsstest also die Firmware verstehen und verändern können. Falls Du das nicht kannst - eine "fertige" Firmware zum Download ist im verlinkten Thread nicht zu finden - würde ich Dir raten den Ansatz mit dem DIR des Z-Treibers zu testen, denn wenn in der ISR synchron die MOVE-Befehle bedient werden, dann natürlich auch diejenigen für Z. Die Firmware weiß nicht, dass da kein Stepper betrieben wird, sondern ein Laser über DIR moduliert wird. Nachteilig könnten die Rampen sein, mit denen die MOVE-Befehle gefahren werden, das könnte zu einem Geruckel führen, d.h. fahre xx-Steps nach X, beschleunige erst und bremse, fahre nach Z, fahre xx-Steps nach X, beschleunige/bremse usw. Eigentlich wäre eine gleichmäßige Linearbewegung über die gesamte Scanlänge ohne irgendwelche Rampen das Optimale, wobei die einzelnen MOVEs nur dazu dienen, dem Laser die Info zu geben, wann er ein- oder auszuschalten ist.
MWS schrieb: > Eigentlich wäre eine gleichmäßige Linearbewegung über die gesamte > Scanlänge ohne irgendwelche Rampen das Optimale, wobei die einzelnen > MOVEs nur dazu dienen, dem Laser die Info zu geben, wann er ein- oder > auszuschalten ist. Ich würde den Laser bis zum nächsten Umschaltpunkt fahren lassen, dort stoppen, Pausse machen, den Laser ein oder ausschalten, weiterfahren. So das irgendwelche Zeiten aus anderen Tasks im Rechner keine Rolle spielen können.
Lutz H. schrieb: > Ich würde den Laser bis zum nächsten Umschaltpunkt fahren lassen, dort > stoppen, Pausse machen, den Laser ein oder ausschalten, weiterfahren. > So das irgendwelche Zeiten aus anderen Tasks im Rechner keine Rolle > spielen können. Warum? Ein Polygonspiegel in einem Laserdrucker hält auch nicht an, um den Laser ein- oder auszuschalten. Das ist Licht, das lässt sich recht flott modulieren Hier kommt noch die im Vergleich zur Zeilenabbildung im Laserdrucker schnarchlangsame Linearmechanik hinzu. Deshalb könnte man in einem Rutsch die komplette Breite scannen und nur den Laser passend modulieren. Der User im anderen Thread fand ja bereits eine gute Lösung, ich würde sogar behaupten, dass es recht übersichtlich wäre, die Firmware komplett auf die Belichtungsanwendung neu zu schreiben. Vieles was für die Anwendung als 3D-Drucker wichtig ist, ist für's zeilenweise Belichten unnötig, es ist z.B. keine zweidimensionale Interpolation notwendig und Rampen sind auch eher störend.
Angehängte Dateien:
-
Jitter.png
27 KB
MWS schrieb: >> So das irgendwelche Zeiten aus anderen Tasks im Rechner keine Rolle >> spielen können. > > Warum? Das Umschalten des Lasers erfolgt oft nicht immer an der richtigen Position, sondern zufällig meist irgendwo nach der richtigen Position.
:
Bearbeitet durch User
Lutz H. schrieb: > stoppen, Pausse machen, den Laser ein oder ausschalten, weiterfahren. > So das irgendwelche Zeiten aus anderen Tasks im Rechner keine Rolle > spielen können. >> MWS schrieb: >>> Warum? Ein Polygonspiegel in einem Laserdrucker hält auch nicht an, um >>> den Laser ein- oder auszuschalten. >> Das Umschalten des Lasers erfolgt oft nicht immer an der richtigen >> Position, sondern zufällig meist irgendwo nach der richtigen Position. Hast Du diesen Thread und die gegebenen Antworten überhaupt gelesen? Es sind keine "Tasks im Rechner" schuld, wenn mit "Rechner" der steuernde PC gemeint ist, sondern Grund der Probleme ist der Aufbau der Firmware. Der TE hat nicht allein Probleme mit nach der richtigen Position, sondern mit dem zufälligen zeitversetzten Schalten des Lasers, also auch vorher, schau' den von Dir geposteten Bildausschnitt an, dann siehst Du's, es sind sowohl Lücken, als auch belichtete Stellen wo keine sein sollen. Das resultiert daraus, dass in der Originalfirmware für RAMPS, dem 3D-Drucker Kontrollboard, der Lüfter nicht priorisiert bedient wird. Für den gedachten Anwendungszweck des 3D-Drucks ist das vollkommen ausreichend, nur hier störend. Mit einer, wenn auch kurzen Pause, hat's der TE bereits erfolglos probiert. Nimmt man an, dass der RAMPS-Controller vorausschauend aus dem Puffer liest, dann versteht man dass ein Lüfter-Befehl zufällig ausgeführt werden kann, bevor oder nachdem der aktuelle MOVE-Befehl beendet ist. Mein Post zu "gleichmäßiger Linearbewegung" und "Polygonspiegel" ging hingegen von einer idealen Firmware aus, das sollte eigentlich zu verstehen gewesen sein. Eine ideale, auf diesen Zweck abgestimmte Firmware auf dem Funktionsprinzip eines Zeilenscans würde einen MOVE Befehl entgegen nehmen, die Schritte einzeln zum Schrittmotortreiber schicken und nach jedem Schritt prüfen, ob die Zielposition erreicht ist. Ist das der Fall würde der nächste MOVE-Befehl abgearbeitet, ein zwischenliegender Laser Ein/Aus-Befehl würde unmittelbar zum Pin des Lasertreibers geschickt. Das Holen allein der Befehle aus dem Puffer würde zu keinem Jitter führen und Senden der Schritte an den Schrittmotortreiber würde in einer Timer-ISR geschehen, wäre also auch weitestgehend jitterfrei, zumindest soweit, dass im Belichtungsergebnis nichts davon zu bemerken wäre. G01 X20.00 M106 ;Laser ein G01 X30.00 M107 ;Laser aus G01 X40.00 M106 ;Laser ein G01 X60.00 M107 ;Laser aus G00 X00.00 ;Rücklauf G00 Y00.10 ;Vorschub in Y nächste Zeile... Rampen sollen dabei vermieden werden, außer vielleicht bei Beginn und Ende einer Zeile, Rampen führen nur zu unterschiedlicher Belichtungsdauer. Gegenüber den Anforderungen an den 3D-Druck müsste eine solche ideale Firmware einen geradezu primitiven Funktionsumfang besitzen, GCode vom PC entgegennehmen, in einen Puffer schreiben und daraus vornehmlich den X-Treiber mit konstanter Geschwindigkeit bedienen. Die Diskussion hier ist eigentlich fragwürdig, so ähnlich wie die tausendste Frage zum Led-Widerstand, denn es wird nur das wieder durchgekaut, was vom User Conny bereits gelöst wurde. Seitens des TE würde ich den mal anschreiben, ob er eine passende Firmware rausrückt.
Angehängte Dateien:
-
Jitter.png
27 KB
MWS schrieb: > G01 X20.00 Pause > M106 ;Laser ein Pause > G01 X30.00 Pause > M107 ;Laser aus Pause > G01 X40.00 Pause > M106 ;Laser ein Pause > G01 X60.00 Pause > M107 ;Laser aus Pause > G00 X00.00 ;Rücklauf > G00 Y00.10 ;Vorschub in Y > nächste Zeile... Ich habe es noch einmal eingemalt, wo Fehler sind und im Programm Wartezeiten ein gebaut werden müssten, wenn nicht die gesammte Firmware umgestellt werden soll.
:
Bearbeitet durch User
Hmm, ähnliches Problem: > Sorry for being a noob! Found similar issue, and an answer. For those > who finds it, instead of: > G1 Xnnn Ynnn > M42 P4 Snnn > use: > G1 Xnnn Ynnn > M400 > M42 P4 Snnn > It will help to synchronize movements and toggling the laser by command > M400, which forces system to wait until movements completes. Quelle: https://github.com/MarlinFirmware/Marlin/issues/5844 Aber soweit ich gesehen habe, hast du das schon versucht? *edit*: M42 schaltet wohl einen Output-Pin ... Das wäre also vermutlich der richtige Weg, den man einschlagen sollte und nicht über die Lüftersteuerung.
:
Bearbeitet durch User
Angehängte Dateien:
-
PCB-2211.jpg
28 KB
So, da bin ich wieder. Es gibt erfreuliche Neuigkeiten. Es lag tatsächlich an der (alten) Marlin Firmware. Historisch bedingt, arbeitete ich ja noch mit der Version 1.0.2. In den neuen Versionen (ab 1.1.2) wurde Laser/Spindel Unterstützung eingebaut. Das hieß für mich: Firmwareupgrade auf 1.1.6. Nach korrekter Konfiguration, lässt sich der Laser nun mit den Kommandos M3/M5 ein- bzw. ausschalten. Dabei nutze ich den Servo-Pin D6 auf dem RAMPS-Board. Die Ergebnisse sind sehr Erfolgsversprechend (siehe PCB-Demo auf Thermopapier). Nun kommt noch etwas Feintuning und dann geht's an die ersten "echten" Leiterplatten. Vielen Dank an Alle, welche hier Tipps gegeben haben. Schön dass es ein solch aktives Forum gibt!
Der Vollständigkeit wegen, hier das jetzt fertige Programm mit Sourcecode zum erzeugen des Laser G-Codes für die Marlin-Firmware aus BMP-Dateien. Vielleicht hilft das dem einen oder andern.
ich sag einfach mal danke für deine arbeit hast es ja doch gelöst mal sehen am Wochenende kann ich evtl meinen benbox mal mit Daten füttern werde lichtempfindliche China Folie auf eine unbeschichtete platine laminieren und dann damit mal einen laser belichtungstest durchführen allerdings bleibt alles was belichtet wird stehen (wird ausgehärtet) so dass ich lediglich die leiterbahnen abfahren muss
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.