Announcement: there is an English version of this forum on Ich habe auf einem Raspi CUPS installiert und einen Bondrucker EPSON TM88V am USB-Port eingerichtet. Über die Shell kann ich einfache PS-Files drucken: z.B. mit "lp -d EPSON_TM_T88V test.ps" Das funzt. Nun der nächste Schritt, der mir allerdings Probleme bereitet: Wie sende ich per CUPS/CLI das Kommando zum Schneiden des Bon zu dem Drucker: x1B und x69 (also die Bytes 27 und 105 dezimal)? Einfach die beiden Bytes in eine Datei schreiben und mit dem gleichen Kommando wie oben zum Drucker schicken (natürlich nicht mit der Endung .ps, ich habe .txt und .bin ausprobiert), klappt aber nicht, der Drucker zuckt nicht ... Danke für Tips.
:
Bearbeitet durch User
https://stackoverflow.com/questions/30662024/how-to-send-esc-pos-commands-to-thermal-printer-in-linux Gruesse Th.
Besten Dank! Das Kommando: lp -d EPSON_TM_T88V -o raw test.txt hat funktioniert, wobei test.txt 4 Bytes enthält: x27 x69 x0D x0A Danke! Die "raw"-Option hätte mich bereits viel früher "getriggert", allein sie kommt in der CUPS-Doku einfach nicht vor ... oder sie ist gut versteckt. :-)
Frank E. schrieb: > x0D x0A Das ist CR/LF, Datei wohl unter Windows erstellt. Linux hätte glaube ich nur LF. Aber wenn's den Drucker nicht stört... Gruss Chregu
Christian M. schrieb: > Frank E. schrieb: >> x0D x0A > > Das ist CR/LF, Datei wohl unter Windows erstellt. Linux hätte glaube ich > nur LF. Aber wenn's den Drucker nicht stört... > > Gruss Chregu Nix Windows, mit einem Hex-Editor manuell erstellt auf Mac. Aber es stört nicht, lass' ich jetzt so ... Nachfrage: Gibts noch irgend einen Trick, die Daten nicht erst in eine Datei schreiben zu müssen, sondern direkt zu übergeben? Ich mache das mit Xojo, dort sieht das so aus: var s as new shell s.execute "bla bla bla ..." Ich kann also die Kommandozeile als String-Konstante oder als Variable direkt aus dem Programmcode übergeben. Allerdings kann ich mir vorstellen, dass die Shell mit Binärdaten so ihre Probleme hat, oder?
:
Bearbeitet durch User
Im Vorraus: Ich kenn mich mit CUPS kaum aus. Die Idee, beliebige ESC/P-Sequenzen per Druckjob abzusetzen, geht in die falsche Richtung. Beachte, dass CUPS ein Drucksystem ist, welches Druckjobs umordnen, wiederholen, umleiten,beliebig verwursten kann. Das Konzept, das dir vorschwebt, Job-1 absetzen, Spezialkommando absetzen, Job-2 absetzen, etc funktioniert nur mit Glück. Spezialkommandos, die einen bestimmten Druckjob betreffen, müssen an diesen gebunden sein. Kommandos, die jeden Job eines Druckers betreffen, müssen in der Druckerkonfiguration hinterlegt sein. Etc. So etwas wie "Schneiden" gehört entweder in die Druckerkonfig, nach jedem Job/jeder Seite schneiden, ob an den Job. Ich hab wahllos mal in die PPD eines Ettikettendruckers geschaut, und sowas gefunden:
1 | *OpenUI *Cutting/Cutting: PickOne |
2 | *OrderDependency: 0 AnySetup *Cutting |
3 | *DefaultCutting: 1CutAtTheEndOfPage |
4 | *Cutting 0NoCutting/No cutting: "" |
5 | *Cutting 1CutAtTheEndOfPage/Cut at every page: "" |
6 | *Cutting 2CutAtTheEndOfJob/Cut at every job: "" |
7 | *CloseUI: *Cutting |
D.h. der kennt schon Schneideoptionen. Die muß man ihm nur mitteilen. Und hier endet mein Wissen über CUPS. Ob man hier jetzt einfach "-o cutting=CutAtTheEndOfJob" angibt, das irgendwo in eine Druckerkonfig festlegen kann - keine Ahnung. Musst du mal selbst wühlen (PPD suchen, Druckersettings finden, etc). Aber das mit dem ESC/P selbst absetzen ist eine Schnapsidee. PS: Irgendwo hab ich auch mal was mit "-o source=<datei>" gefunden (scheint <datei> an den Druckjob zusätzlich dranzupappen?!? Keine Ahnung.)
Nachtrag: wenn du tatsächlich komplexe Features des Druckers nutzen willst, die in CUPS nicht abgebildet sind, würde ich CUPS erst gar nicht verwenden, sondern direkt auf den Drucker zugreifen, /dev/USB0 oder entspr. Dann musst du dich aber selbst um die komplette Druckaufbereitung kümmern (keine automatische PS Konvertierung, Skalierungen, etc). Alternativ den Druckertreiber erweitern ...
Warum zum Geier sollte man das über CUPS machen? Drucker per Netzwerk anschließen, und auf Port 9100 senden. Evtl. musst du erst noch ein InitializePrinter senden. Guck mal hier: https://github.com/python-escpos/python-escpos
Kaj G. schrieb: > Warum zum Geier sollte man das über CUPS machen? > Drucker per Netzwerk anschließen, und auf Port 9100 senden. Evtl. musst > du erst noch ein InitializePrinter senden. > > Guck mal hier: > https://github.com/python-escpos/python-escpos Es geht nicht darum, den Drucker "irgendwie" zum Drucken zu bringen. USB-Anschluss und Raspi sind fest gesetzte Randbedingungen. Cups brauche ich, um schnell Logos aus vorab gespeicherten Dateien zu drucken. Generell am Jobende zu cutten reicht auch nicht, ich benötige zwischendurch mehrere Halfcuts ...
Angehängte Dateien:
Gibts denn eine Möglichkeit, an den Drucker auch dann über USB (!) Daten zu senden, wenn er nicht in CUPS eingebunden bzw. wenn CUPS überhaupt nicht auf dem Raspi installiert ist? Beim Mac (was in vielen Details dem Debian ähnelt) erscheinen auch Gräte, für die kein Treiber installiert wurde, im System. Zumindest kann man sie über den "Systembericht/USB" als vorhanden erkennen. Normale Anwendungssoftware kann dann aber nichts damit anfangen. Mit welchem Bash/Shell-Befehl kann man trotzdem Daten in so ein Device schreiben? Ich habe mich mal mit dem Terminal bis in das Verzeichnis "/dev/" vorgearbeitet. Da gibts quasi hunderte EInträge, aber keiner davon hat einen Namen, der auf den EPSON TM88V schließen lässt (s. Bild)
:
Bearbeitet durch User
Frank E. schrieb: > Beim Mac (was in vielen Details dem Debian ähnelt) erscheinen auch > Gräte, für die kein Treiber installiert wurde, im System. Zumindest kann > man sie über den "Systembericht/USB" als vorhanden erkennen. Normale > Anwendungssoftware kann dann aber nichts damit anfangen. Naja, da sind schon systemische Unterschiede, die Unterschiede BSD <-> Linux sind schon gross. > Gibts denn eine Möglichkeit, an den Drucker auch dann über USB (!) Daten > zu senden, wenn er nicht in CUPS eingebunden bzw. wenn CUPS überhaupt > nicht auf dem Raspi installiert ist? Wenn ich meinen Drucker (kleiner Brother) mit USB mit dem Raspberry verbindet, erzeugt er ein Device /dev/usb/lp0. Das ist also ein ganz banales Character-Device. Was Du dann machen willst weiss ich ja nicht (ich kenne auch den Drucker nicht). Und wenn das Ding ja schon druckt wuerde ich versuchen, die spezifische PPD-Datei zu finden (oder eine vorhandene Datei modifizieren). Der Druckerhersteller waere Dein Ansprechpartner (PPD-Dateien sind eine Apple Erfindung, wurde dann sehr schnell ein Industriestandard. Gerade im professionellen Bereich weil kein geraetespezifische Treiber mehr gebraucht wurde). > Mit welchem Bash/Shell-Befehl kann man trotzdem Daten in so ein Device > schreiben? cat abc.txt > /dev/usb/lp0 sollte immer gehen, es sei denn, es ist ein Lock drauf (weiss ich nicht, ob CUPS so etwas macht). > > Ich habe mich mal mit dem Terminal bis in das Verzeichnis "/dev/" > vorgearbeitet. Da gibts quasi hunderte EInträge, aber keiner davon hat > einen Namen, der auf den EPSON TM88V schließen lässt (s. Bild) Das ist auch ein Apple, das Verzeichnis ist ausserdem nicht vollstaendig. Gruesse und Bonne Chance Th. P.S.: Ich hatte eben bei epson geguckt, die Treiberlinge fuer den Drucker sind doch alle da (auch die ppd-Dateien). Kleines Problem sind die backend-programme (nur Intel)
:
Bearbeitet durch User
Frank E. schrieb: > Cups brauche > ich, um schnell Logos aus vorab gespeicherten Dateien zu drucken. Das ist Unsinn, CUPS braucht es dafür nicht. Du brauchst nur ein kleines Programm/Script, das aus einem PNG/BMP/etc. eine Rastergrafik macht und in den entsprechenden ESCPOS Befehl packt. Befehle sind alle hier beschrieben: https://www.epson-biz.com/modules/ref_escpos/index.php?content_id=72 Frank E. schrieb: > USB-Anschluss und Raspi sind fest gesetzte Randbedingungen. Ist ja kein Problem, kann das Projekt auch. Frank E. schrieb: > Gibts denn eine Möglichkeit, an den Drucker auch dann über USB (!) Daten > zu senden, wenn er nicht in CUPS eingebunden bzw. wenn CUPS überhaupt > nicht auf dem Raspi installiert ist? Klar:
1 | from escpos.printer import Usb |
2 | |
3 | """ Seiko Epson Corp. Receipt Printer (EPSON TM-T88III) """ |
4 | p = Usb(0x04b8, 0x0202, 0, profile="TM-T88III") |
Wie gesagt: CUPS brauchst du dafür nicht. Das ist deine künstliche Einschränkung.
Um das Raster Bit Image zu drucken kannst du den Befehl GS v 0 nehmen. https://www.epson-biz.com/modules/ref_escpos/index.php?content_id=94 bzw. die alternativen GS ( L oder GS 8 L: https://www.epson-biz.com/modules/ref_escpos/index.php?content_id=95#gs_lparen_cl
:
Bearbeitet durch User
Kaj G. schrieb: > Klar: > from escpos.printer import Usb > """ Seiko Epson Corp. Receipt Printer (EPSON TM-T88III) """ > p = Usb(0x04b8, 0x0202, 0, profile="TM-T88III") Die ESC/P-Befehle kenne ich in- und auswendig, danke. Aber das, was du da als Code angegeben hast, das geb' ich über das Terminal auf den Raspi ein? Ohne weitere Abhängigkeiten vorher zu installieren?
Ich muss dazu nochmal einige "dumme" Fragen stellen und die Richtung des Thread ein wenig korrigieren: Also wie man solche Drucker mit ESC/P ansteuert, weiss ich und die passenden Codes kommen schon "fix und fertig" aus meiner Anwendung (Text, Grafik und Zusatzbefehle, wie Schneiden usw.). DAS ist nicht mein Problem, das habe ich bereits ausführlich mit der UART-Schnittstelle getestet. Mein konkretes Problem ist es eher, wie sende ich die "fertigen" Daten mit möglichst geringem Aufwand (bezüglich der notwendigen Installationen) rein physikalisch per USB an den Drucker - nicht mehr und nicht weniger. CUPS enthält für diesen Zweck wahrscheinlich 98% unnötigen Code, aber das hat im Prinzip funktionert (siehe weiter oben). Wenn es auch deutlich sparsamer ginge, wäre ich echt glücklich. Danke. Und bevor die Frage aufkommt, warum ich nicht UART nutze, man glaubt es kaum: Selbst bei 115200 bit/s kommt der Bon rel. gemütlich aus dem Drucker (der in einem Verkaufsautomaten hinter der Frontplatte installiert ist). Bisher handelt es sich um einen Kiosk-Drucker GPT-4672 von GEBE, Kostenpunkt ca. 600,-, kompatibel mit ESC/P-Codes. Es gibt doch tatsächlich "Kunden", die so blöd sind, an dem Bon zu ziehen, sobald sich die ersten Zentimeter zeigen. Das quittiert der Drucker jedoch mit einer sofortigen Fehlermeldung "Papierstau", was wiederum jedesmal ein manuelles Eingreifen notwendig macht. Werden die Daten per USB übertragen, kommt der Bon schnell genug, so dass keine Dumpfbacke die Gelegenheit hat, daran zu zerren ...
Und was ist falsch an cat > /dev/usb/lp0? Ob das so richtig klappt weiss
ich latuernicht nicht.
Und warum willst Du CUPS nicht verwenden? Mir gefaellt das CUPS-System
auch nicht, aber es macht seinen Job und gut ist. ppd-Dateien sind beim
Treiber dabei.
Und Du sagst
> Wenn es auch deutlich sparsamer ginge, wäre ich echt glücklich. Danke.
hast Du im Jahr 2023 einen falschen Ansatz: Speicher ist billig. Selbst
transaktionsfester Speicher ist billig.
Was Du latuernich braeuchtest waere eine vandalenfeste Druckausgabe
(gehe mal zur BVG): Alles, an dem Du irgendwie ziehen oder druecken
kannst, wird zerstoert.
Gruesse
Th.
Thomas W. schrieb: > Und was ist falsch an cat > /dev/usb/lp0? Ob das so richtig klappt > weiss > ich latuernicht nicht. Vermutlich nichts, habe ich nur noch nicht getestet ... > Und warum willst Du CUPS nicht verwenden? Mir gefaellt das CUPS-System > auch nicht, aber es macht seinen Job und gut ist. ppd-Dateien sind beim > Treiber dabei. Hier im Thread hieß es, das sei - verkürzt - "mit Kanonen auf Spatzen". Teilwiese kann ich mich dem anschließen, denn ich benötige ausschließlich die physikalische Übertragung, kein Rendering oder PS-Interpretation ... > Was Du latuernich braeuchtest waere eine vandalenfeste Druckausgabe > (gehe mal zur BVG): Alles, an dem Du irgendwie ziehen oder druecken > kannst, wird zerstoert. Ja, hinterher ist man natürlich immer schlauer. Eine Problemlösung sucht man auch nur dann, wenn sich des Problems überhaupt bewusst ist. Für Drucker im "Publikumskontakt", das weiss ich inzwischen auch, verwendet man sog. "Präsenter". Das sind Zwischenmodule, die den Bon intern so lange festhalten, bis er komplett ist und dann mit hoher Geschwindigkeit ausgeben. Falls er nicht entnommen wird, wird er in eine interne Ablage zurückgezogen. Kostet allerdings genau so viel wie der Drucker ...
:
Bearbeitet durch User
Frank E. schrieb: > Thomas W. schrieb: >> Und was ist falsch an cat > /dev/usb/lp0? Ob das so richtig klappt >> weiss >> ich latuernicht nicht. > > Vermutlich nichts, habe ich nur noch nicht getestet ... Mach das mal: Wenn kein CUPS laeuft, kann es auch nicht dazwischenfunken. Vielleicht waere das die einfachste Loesung. >> Und warum willst Du CUPS nicht verwenden? Mir gefaellt das CUPS-System >> auch nicht, aber es macht seinen Job und gut ist. ppd-Dateien sind beim >> Treiber dabei. > > Hier im Thread hieß es, das sei - verkürzt - "mit Kanonen auf Spatzen". > Teilwiese kann ich mich dem anschließen, denn ich benötige > ausschließlich die physikalische Übertragung, kein Rendering oder > PS-Interpretation ... Aber Du hast auch Goodies: Fehlermeldungen per eMail, vielleicht musst Du auf der Maschine noch einen weiteren Drucker benutzen. Aber wenn Du es nicht brauchst, wuerde ich mir schon ueberlegen ob Du Dir Nerverei mit CUPS (vor allen Dingen die ppd-Dateien) antun willst. Wenn das Ding aufgesetzt ist, funktioniert es wie ein Kuehlschrank: Einstecken, vergessen. >> Was Du latuernich braeuchtest waere eine vandalenfeste Druckausgabe >> (gehe mal zur BVG): Alles, an dem Du irgendwie ziehen oder druecken >> kannst, wird zerstoert. > > Ja, hinterher ist man natürlich immer schlauer. Eine Problemlösung sucht > man auch nur dann, wenn sich des Problems überhaupt bewusst ist. Für > Drucker im "Publikumskontakt", das weiss ich inzwischen auch, verwendet > man sog. "Präsenter". Das sind Zwischenmodule, die den Bon intern so > lange festhalten, bis er komplett ist und dann mit hoher Geschwindigkeit > ausgeben. Falls er nicht entnommen wird, wird er in eine interne Ablage > zurückgezogen. Kostet allerdings genau so viel wie der Drucker ... Immer noch guenstiger als einen Human-Presenter "Hier haben Sie Ihr Ticket. Haben Sie einen schoenen Tag!". Gruesse Th. P.S.: Hattest Du Deinen Brother-Drucker reparieren koennen? Ich hatte zwar damals (klar, Lockdorn!) das ServiceManual fuer meinen 51xx gefunden, das Ding zerstoerungsfrei auf- und zuzumachen war mir nicht gegeben. Der Drucker ging dann leider in den Spaenekorb.
Thomas W. schrieb: > P.S.: Hattest Du Deinen Brother-Drucker reparieren koennen? Ich hatte > zwar damals (klar, Lockdorn!) das ServiceManual fuer meinen 51xx > gefunden, das Ding zerstoerungsfrei auf- und zuzumachen war mir nicht > gegeben. Der Drucker ging dann leider in den Spaenekorb. Noch keine Zeit gehabt, steht aber auf der ToDo-Liste. Habe erstmal einen Raspi und den Epson-Drucker "am Wickel" ...
Rückmeldung zum Thema Epson am Raspberry: 1. Im aktuellen Raspian (Debian Bullseye) ist bereits ein CUPS enthalten, muss also nicht extra installiert werden. 2. Der EPSON am USB kann ganz normal über die GUI (Printer Setup) eingerichtet werden. Physikalisch wird er automatisch (USB) erkannt. 3. Für meine Zwecke (ESC/P-Codes vorhanden), habe ich den Drucker als "Generic" und mit "raw queue" eingerichtet. 4. Das Kommando lp -d EPSON_TM_T88V -o raw test.txt druckt den Inhalt der Datei bzw. führt die Kommandos aus, wenn sie im Code enthalten sind. Was mir zum vollständigen Glück noch fehlt, wäre, wenn ich die Daten nicht erst in ein File kopieren müsste, sondern aus meiner Anwendung irgendwie direkt übergeben könnte ...
> Was mir zum vollständigen Glück noch fehlt, wäre, wenn ich die Daten > nicht erst in ein File kopieren müsste, Dann schau halt mal in die man-page zu lp. Statt fp = fopen("test.txt", "w"); ein fp = popen("lp -d EPSON_TM_T88V -o raw", "w"); //[1] oder noch besser: fp = fopen("/dev/ttyUSB0", "w"); // evtl "/dev/serial/by-id/...." denn meiner Meinung/Erfahrung nach ist ein Drucksystem wie lp/cups für solche Anwendungen (Ettiketten-/Bon-Drucker) nicht nur überflüssig, sondern nachteilig. Die zusätzlich gebotenen Features werden nicht benötigt (denn wenn man mal genau schaut, das einzige was du von CUPS benötigst, ist das Mapping vom Druckernamen zum Druckerport), die zusätzliche Komplexität grätsch einem aber gerne mal in die Beine. Wirst du aber schon merken, wenn das erste Mal z.B. Dutzende von alten/mißlungenen Druckjobs gesammelt ausgedruckt werden oder dir der Plattenplatz ausgeht, weil Jobs nicht gelöscht wurden. Die Verzögerung bis zum Druckbeginn kommt auch noch dazu ... [1] CUPS selbst erstellt natürlich immer noch Temporärdateien. Wenn's dir also um das Vermeiden von Schreibzugriffen aufs Filesystem oder um Plattenplatz geht, hilft das nicht.
Ich hatte vor etlichen Jahren ein ähnliches Problem: eine Altapplikation, mit hart-kodierten Druckercodes in einer archaischen Druckersprache wollte drucken. Vom Druckerhersteller gab es (gegen Geld) eine Emulation für diese Druckersprache. Man musste den Drucker aber explizit umschalten. Das ging entweder dauerhaft, oder mit PJL-Befehlen, so ähnlich wie dein ESC/P. Gleichzeitig wollten "moderne" Applikationen auch auf den gleichen Drucker drucken, man will ja nicht 2 kaufen müssen. Lösung damals: In CUPS eine Queue für die Altapplikation. In dieser Queue wurde ein Filter konfiguriert, der vor dem Druckjob die passenden Binärcodes zum Umstellen ausgegeben hat, danach die eigentliche Druckdatei, und danach Codes zum Zurückstellen. Das war ein kurzes Shellscript, mit echo -n und cat, Ausgabe auf stdout. Dann gab es eine "normale" Queue für moderne Applikationen. Die war das Frontend zum USB-Port des Druckers und auf sie wurden die Spezialjobs nach dem Filtern "überwiesen". Um eine weitere Filterung in der Queue zu verhindern musste irgendwo noch ein Phantasie-Mimecode genutzt werden. Leider kann ich nicht mehr Details liefern und habe die Sourcen nicht mehr. Ist schon sehr lang her. Das lief so weit ich weiß robust, in mehreren hundert Instanzen. Foobar schrieb: > denn meiner Meinung/Erfahrung nach ist ein Drucksystem wie lp/cups für > solche Anwendungen (Ettiketten-/Bon-Drucker) nicht nur überflüssig, > sondern nachteilig. Imho musst du dich entscheiden, raw auf USB, oder mit CUPS. Die älteren Druckerdeamons (lpd, lprng) waren zumindest damals deutlich zickiger als das gut konfigurierbare CUPS.
> Imho musst du dich entscheiden, raw auf USB, oder mit CUPS. > Die älteren Druckerdeamons (lpd, lprng) waren zumindest damals deutlich > zickiger als das gut konfigurierbare CUPS Wenn du so fragst, wäre mir RAW auf USB natürlich lieber. Die Frage ist (finde ich aber bestimmt heraus), wie deinstalliere ich CUPS, wenn es doch schon zum Raspian-Image gehört? Und mit welchem Tool oder Hilfsmittel finde ich dann unter "dev" den richtigen Port? Keiner der Namen dort hat irgendwas mit "EPSON" zu tun ...
so lange cups nicht druckt, sollte der den USB-Port eigentlich auch nicht anfassen. Den cups-Daemon kannst du deaktivieren (systemctl disable ...) Info über angeschlossene USB-Geräte bekommst du z.B. mit lsusb. Du solltest unter /etc/udev/rules.d/ eine Regel eintragen können, damit dein Drucker, sobald er erkannt wird, immer den selben Devicenamen bekommt.
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.