Forum: Platinen Ein weiterer Versuch. Laserbelichter mit Problemchen


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 Uwe D. (Firma: privat) (altrheinuwe)


Angehängte Dateien:

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

von MWS (Gast)


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

von Uwe D. (Firma: privat) (altrheinuwe)


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

von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Interessantes Problem, lese ich gerne mit abo on

von bernte (Gast)


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

von Uwe D. (Firma: privat) (altrheinuwe)


Angehängte Dateien:

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

von Werner H. (pic16)


Bewertung
0 lesenswert
nicht lesenswert
Das könnte an den verwendeten Steppertreibern liegen, die kleinen A4988 
und auch der DRV8825 vergessen gern mal Schritte.

von Guido B. (guido-b)


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

von Typ (Gast)


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

von Christian B. (luckyfu)


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

von Uwe D. (Firma: privat) (altrheinuwe)


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

von Typ (Gast)


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

von Werner H. (pic16)


Bewertung
0 lesenswert
nicht lesenswert
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
von Uwe D. (Firma: privat) (altrheinuwe)


Bewertung
0 lesenswert
nicht lesenswert
Typ schrieb:
> Kannst du mal den gcode für den Barcode anhängen?

Das ist der GCode aus meinem ersten Post (Leiterbahnen.gcode)

von Typ (Gast)


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

von Typ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Vll. kannst du ja mal mit der Option FAN_SOFT_PWM spielen. Also 
aktivieren oder deaktivieren, je nachdem.

von Christian B. (luckyfu)


Bewertung
0 lesenswert
nicht lesenswert
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
von MWS (Gast)


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

von Johannes S. (jojos)


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

: Bearbeitet durch User
von Uwe D. (Firma: privat) (altrheinuwe)


Angehängte Dateien:

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

von FlorenzW (Gast)


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

von Uwe D. (Firma: privat) (altrheinuwe)


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

von Dieter F. (Gast)


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

von MWS (Gast)


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

von Lutz H. (luhe)


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

von MWS (Gast)


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

von Lutz H. (luhe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von MWS (Gast)


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

von Lutz H. (luhe)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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
von Mampf F. (mampf) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von Uwe D. (Firma: privat) (altrheinuwe)


Angehängte Dateien:

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

von Uwe D. (Firma: privat) (altrheinuwe)


Angehängte Dateien:

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

von bernte (Gast)


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

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.