Moin,
ich habe diverse ältere HP/Agilent-Messgeräte, die in der Lage sind,
über einen seriellen oder parallelen Port ("Centronics") einen
Screenshot direkt auf diverse altertümliche Drucker zu drucken.
Nun kann ich die Daten natürlich auch über einen seriell/USB-Wandler auf
einem aktuellen PC empfangen und in eine Datei umleiten.
Die Frage ist, kann man so eine Datei wieder zurück in ein Grafikformat
oder PFD verwandeln? Ich würde gerne Screenshots der Instrumente
speichern können, um sie in Reports zu verwenden.
Ich brauche also quasi einen inversen Druckertreiber - bzw. eine
Software, die einen solchen Drucker emuliert und dann ein handliches
Ausgabeformat erzeugt.
Gibt es sowas? Was wäre ein passendes Stichwort zur Suche?
Auf Anhieb fallen mir die Tools auf http://www.ke5fx.com ein. Dort gibt es einen HP7470 Plotter emulator. Der hilft mir gelegentlich für genau diesen Zweck, allerdings über GPIB Schnittstelle.
Welche Drucker stehen denn zur Auswahl? Wenn davon einer PostScript macht, kannst du das im Idealfall einfach in eine Datei speichern und fertig.
Das hängt stark von den "unterstützten" Drucker ab und ob da nur Texte, nur Grafik (also sozusagen ein Screenshot) oder gemischt an den Drucker geschickt wird. Bei älteren Geräten würde ich vermuten, dass die auch Laserjets unterstützen, dann vmtl. PCL-irgendwas. GhostPCL wär' dann eine Option. Da es das als Source-Code gibt, kann man ggf. auch die Texte bequem extrahieren, also "in ASCII" statt nur als Bild. Vielleicht gibt's ja auch PostScript, dann wär' ghostscript das Mittel der Wahln.
So etwas habe ich schon benutzt, eine Laserjet-Ausgabe in ein Bild umgewandelt. Texte sind dann allerdings nur noch über OCR wiederzugewinnen. PCL-to-irgendein_Bildformat.exe ,ich weiß es nicht mehr genau. Es gab auch ein DOS-Programm, das Nadeldruckerdaten in ein Bild umwandelte. EPSON oder IBM kompatible Drucker hießen die im Druckerauswahlmenü.
Einige Dosbox Forks machen das ja im Prinzip auch. Die verarbeiten die eigentlich an den Drucker gesendeten Bytes, konvertieren diese in Einzelanweisungen in ghostscript und senden diese als PDF an USB Drucker. Die Software müsste man sich dann halt selber bauen.
Philipp K. schrieb: > Die Software müsste man sich dann halt selber bauen Im Ghostscript-Umfeld gab es Druckertreiber, die statt zu drucken eine Grafikdatei erzeugt haben (z.B. bmp) - muss man nur als Drucker auswählen und einen Dateinamen angeben. Georg
Angehängte Dateien:
-
OPTIKS.png
120 KB -
SciTechLib_Aug1994.jpg
300 KB
Für ganz alte Drucker, vor dem Laserjet als Quasi-Standard, hab ich mal das hier benutzt: OPTIKS. Es konnte Nadeldruckerausgaben in Bilder konvertieren. Die CD von 1994 müsste noch irgendwo herumliegen. https://archive.org/details/scilib da kann man ein ISO-Image herunterladen
:
Bearbeitet durch User
Der TO möchte das ja umgekehrt, quasi das Druckersignal eines Druckerausgangs mit einem PC Treiber einlesen und als Datei abspeichern.. Müsste man Mal nach Druckerbypass oder druckersniffer googeln
Nach sehr langsamem Download: 3913.zip mit OK.exe OPTIKS 3.01 Graphics File Editor. Full function version. Reads 52 Graphics file types. Writes 36 file types. Supports Scanners, dozens of video cards and printers, VESA, XMS, EMS. Black & white graphics formats include TIFF, PCX, ACAD DXF, SLD, Lotus, GEM, MAC, MSP, B&W GIF. 36 image manipulation functions to enhance, clean, size, alter. Full shareware - NOT CRIPPLED. Nur etwas für Hartgesottene. Irgendwie sollte das in DOSBOX oder ähnlichem für antike Software noch laufen.
Jochen schrieb: > ich habe diverse ältere HP/Agilent-Messgeräte, die in der Lage sind, > über einen seriellen oder parallelen Port ("Centronics") einen > Screenshot direkt auf diverse altertümliche Drucker zu drucken. Welche genau? Das ist der springende Punkt.
rmf schrieb: > Dort gibt es einen HP7470 Plotter emulator. > Der hilft mir gelegentlich für genau diesen Zweck, allerdings über GPIB > Schnittstelle. Was braucht der eigentlich als GPIB-Interface?
c-hater schrieb: > Welche genau? Das ist der springende Punkt. Im Menü stehen zur Auswahl: ThinkJet QuietJet PaintJet DeskJet LaserJet Epson FX-80 Epson LQ-850 Man kann noch Lines/Page einstellen, und ob man FF am Start/Ende haben will. Text extrahieren brauche ich nicht, mir geht es um die Grafiken (Oszi, Spectrum Analyzer)
Dann nimm so einen Drucker, lege das Ergebnis auf den Scanner und gut ist es. Unter LaserJet ist evtl. PCL gemeint. Manche Laser verstehen PCL-III noch. Und wenn FX-80 angeführt ist, dann kann es auch nur Generic-ASCII sein. Welches die angeführten Drucker können.
Generic Ascii kann keine Grafik. Mein OPTIKS kennt vermutlich Epson FX80. Und PCLto... sollte den Laserjet verstehen. Das einfachste ist, das File an einen Laserjet zu senden, z.B. mit der Eingabeauffoderung und "Copy /B Filename>LPT1:" wenn ich mich recht erinnere. Das /B besagt "binary", damit werden alle Zeichen unverändert gesendet.
:
Bearbeitet durch User
Vielleicht sowas ;) Printer Dummys, ich hatte schonmal ein ähnliches Projekt. Bin nur nicht mehr drauf gekommen wie die Schlagwörter waren. http://cvieth.bplaced.net/elektronik_centronics.html
LaerJet ist mit Sicherheit PCL, DeskJet ebenfalls. Da gibt's noch eine ganze Reihe Varianten, PCL-3, PCL-5 und Subtypen davon (monochrom/Farbe). Aber ganz exotisch machen es die betreffenden Messgeräte sicher nicht. Und ganz spezielle Sachen wie Makros, spezielle Fonts etc. wohl auch nicht. Deshalb ist GhostPCL sicher eine gute Wahl (oder GhostPDL, da müsste man dann die automatische Wahl der Drucksprache beachten).
Habs gefunden: "Pagetech PCLreader" hieß meine erwähnte Laserjet-Software um 2010. Die Firma scheint nicht mehr zu existieren, aber viele "hilfreiche" Webseiten bieten es noch an (man sollte aber auf möglicherweise unerwünscht beigepackte Viren achten). Philipp: Tektronix TDS 210 - genau den habe ich vor einiger Zeit seriell drucken lassen, aber der kann direkt BMP ausgeben. Mit HTERM oder CUTECOM lässt sich das aufzeichnen (35kByte dauert eine Weile) und dann direkt als BMP abspeichern.
:
Bearbeitet durch User
Jörg W. schrieb: > Was braucht der eigentlich als GPIB-Interface? Sorry wg der verzögerten Antwort. Wenn ich die Frage richtig verstehe lautet die Antwort Prologix GPIB oder in meinem Fall NI-GPIB.
rmf schrieb: > Wenn ich die Frage richtig verstehe lautet die Antwort Prologix GPIB > oder in meinem Fall NI-GPIB. Danke. Muss ich mir mal ansehen. Habe hier einen Spekki, dessen Ausgabe man nur so zugreifen kann.
>Wie fängt man Druckerdaten ab
ich habe meinen ersten Versuch mit einem Parallel-Serien-Wandler der c't
gemacht. Da steckte ein Z80-Rechner drin, sowas war damals etwas
komplizierter als heute.
Der R&S FSBS hat keine Druckausgabe seriell, nur Centronics-Anschluss.
Um das abzufangen war der Umweg nötig. Ser-zu-par.-Wandler sind etwas
häufiger, sterben aber allmählich auch aus.
Philipp K. schrieb: > Wie fängt man Druckerdaten ab: Seriell ist weniger ein Problem, aber mit einer druckerseitigen Centronics-Schnittstelle befasst sich niemand mehr. So gesehen finde ich die Schaltung der TU Chemnitz mit Datum 20.10.2014 02:05:26 erstaunlich modern, aber die Grundlage reicht sicher auch in die IT-Steinzeit zurück. Besonders komplex ist die Centronics-Schnittstelle allerdings nicht, bloss ausgestorben. Georg
In der DOS-Zeit gab es Datenübertragung mit Parallelkabel (Lap-Link). Und einem entsprechendem Kreuz-Kabel. Damit sollte die Übertragung in den Computer erst einmal funktionieren.
Ich glaube, mit dem NC konnte man das komfortabel einlesen. Ging auch mit W98.
Und dazu muss auf der Messgeräteseite keine spezielle Voraussetzung erfüllt sein? IEEE 1284 hieß die Norm für bidirektionale Benutzung der Centronicsschnittstelle https://de.wikipedia.org/wiki/IEEE_1284
Selber probieren. Vor 25 Jahren hätte ich das sofort gewußt. Intersvr und interlnk noch bekannt? Bidirektional schon, aber nicht zur gleichen Zeit.
michael_ schrieb: > Und wenn FX-80 angeführt ist, dann kann es auch nur Generic-ASCII sein. Das stimmt nicht. Der konnte auch frei definierbare Bitmaps (natürlich in Häppchen von 9 Pixel Höhe). Und das Protokoll dafür war extrem simpel. Vermutlich gab es im Laufe der Jahrzehnte Tausende Lösungen, diese Daten abzugreifen und anderweitig zu verarbeiten. Das Protokoll ist aber so simpel, dass es auch keinen wirklich nennenswerten Aufwand darstellt, die 1001te Lösung selber zu programmieren...
michael_ schrieb: > Intersvr und interlnk noch bekannt? Bekannt schon, aber ob das ein Agilent-Messgerät für den Screenshot beherrscht? Ich denke das druckt einfach. Manche haben auch wie mein Protocol Analyzer ein Diskettenlaufwerk, aber das hilft nicht wirklich weiter. Georg
Ein Paralleladapter hat erstmal das Problem das die heutigen über USB nicht nativ sind und für ältere Drucker Protokolle nicht alle erforderlichen Pins belegt haben. Georg schrieb: > aber mit einer druckerseitigen Centronics-Schnittstelle befasst sich > niemand mehr. Ich habe erst mit dem MCP23017 eine i2c-parallel Druckerumsetzung für Dosbox gebastelt weil die heutigen USB Kabel halt nicht alle Leitungen belegt haben und die Ghostscript Varianten nicht alle Steuercodes umsetzen. Das funktioniert eben nur zum Drucker und macht auch nur auf einem ARM Sinn.
Erzeuge mal ein paar Roh-Daten. Das man mal schauen kann mit was man rechnen muss. Mit GhostPCL in Verbindung mit DOSEmu und einem DOS-basierendem Warenwirtschaftssystem hab ich gute Erfahrung gemacht. Das lies sich bis zum Barcode-inject (mit eigenem Pythonscript) treiben. Exportformate sind da bis hin zum PDF massig dabei. Zur Not gehts auch mit beliebiger Skript-Sprache um ein Bitmap/PDF zu erzeugen.
Georg schrieb: > michael_ schrieb: >> Intersvr und interlnk noch bekannt? > > Bekannt schon, aber ob das ein Agilent-Messgerät für den Screenshot > beherrscht? Man hat aber alles erst mal in einer Datei. Dann kann man weiter sehen. c-hater schrieb: > michael_ schrieb: > >> Und wenn FX-80 angeführt ist, dann kann es auch nur Generic-ASCII sein. > > Das stimmt nicht. Der konnte auch frei definierbare Bitmaps (natürlich > in Häppchen von 9 Pixel Höhe). Und das Protokoll dafür war extrem > simpel. Man müßte mal so einen Ausdruck sehen. Natürlich kann man sowas nur mit ASCII-Punkt drucken. Ich finde leider das Handbuch zu meinem 24-Nadler nicht. Ich glaube aber, dass es dort ein Epson-Protokoll gab, wo man Grafik im Microschritt-Betrieb machen konnte.
Jochen schrieb: > ich habe diverse ältere HP/Agilent-Messgeräte, die in der Lage sind, > über einen seriellen oder parallelen Port ("Centronics") einen > Screenshot direkt auf diverse altertümliche Drucker zu drucken. Welche denn genau (um das reale Alter herauszufinden) und welche Schnittstellen haben die ? Alle mit GPIB ? Meistens gab es ein Befehl für Scrennshot erstellen, Dann wäre es einfacher sich ein USB GPIB Adapter zuzulegen und vom Steuerrechner abzufragen und weiterzuverarbeiten. PCL ist nicht gleich PCL, musste schon mit einem Druckerhersteller PCL Sachen debuggen. Beim senden eines PCL file direkt an Drucker kam nur Müll raus. Schlussendlich wars ein Drucker FW Problem nach einem Update auf einer neuen PCL Version von dem verdammt viele Drucker betroffen waren. Auch die PCL Definition ist nicht Fehlerfrei bzw Fehlerfrei umgesetzt.
:
Bearbeitet durch User
michael_ schrieb: > Man hat aber alles erst mal in einer Datei. Und wie installierst du Interlnk auf dem Agilent-Messgerät? Georg
Die beiden damaligen Quasi-Standards sind ESC/P für die Nadeldrucker: https://de.wikipedia.org/wiki/ESC/P http://lprng.sourceforge.net/DISTRIB/RESOURCES/PPD/epson.htm der kannte durchaus Pixel-Grafik und PCL für Deskjet und Laserjet https://de.wikipedia.org/wiki/Printer_Command_Language beides beherrscht das Messgerät mit "Epson FX-80" und "Laserjet", es mag kleine Ungenauigkeiten geben, z.B. mit der Druckgröße oder den Rändern, aber das wäre ja tolerierbar. FÜr die Übertragung finde ich den 2. Link von Philipp interessant, ein Arduino als Centronics-zu-Seriell Wandler. Ein kurzes Assemblerprogramm ist gezeigt, mehr ist anscheinend nicht nötig. https://www-user.tu-chemnitz.de/~heha/basteln/PC/LptCap/index.en.htm#4
:
Bearbeitet durch User
Chris K. schrieb: > PCL ist nicht gleich PCL, musste schon mit einem Druckerhersteller PCL > Sachen debuggen. Der TO hat Jochen schrieb: > diverse ältere HP/Agilent-Messgeräte, Mit HP ist wirklich der Hersteller der Laserjet gemeint, Agilent ist die Ausgründung der Messgerätesparte von HP. PCL stammt von HP. Da sollte es keine Missverständnisse geben. Ebenso stammt GPIB von HP als HPIB. Centronics ist eigentlich auch nur HPIB ohne das ganze Adressgedöns. Mit der seriellen Schnittstelle (ein Paintjet 500 hatte noch eine) geht die Übertragung aber einfacher.
Christoph db1uq K. schrieb: > der kannte durchaus Pixel-Grafik Das zu interpretieren ist kein Hexenwerk - die Daten werden als Folge von Bytes übertragen, die für 8 senkrecht untereinander stehende Pixel (=Nadeln) stehen, meistens gibt man die Grafikdaten für eine ganze horizontale Zeile aus. Nach CR/LF kommt die nächste Zeile. Bei 24Nadlern ist das ähnlich, bloss stehen da 3 Bytes für die 24 Nadeln. Vor vielen vielen Jahren habe ich mal einen Interpreter geschrieben, der das abfängt und auf einem Laserjet druckt (was u.a. den Lärmpegel im Büro erheblich gesenkt hat und den Verbrauch an Z-gefaltetem Papier auf 0). Georg
Angehängte Dateien:
-
ESCP_Graphics.png
99 KB
Die verschiedenen Grafikformate sind in der sourceforge-Tabelle aufgelistet. Mit dem Atari 1040ST habe ich so mal zwei einzelne Notenblätter (vermutlich 216 dpi) ausgedruckt, die in irgendeinem Programm mitgeliefert waren (eine bekannte Air von Bach). Eine Viertelstunde dürfte es pro Seite etwa gedauert haben. Drucker war ein Star NL10, damals für >600 DM gekauft, das Zeug war teuer. Das alte DOS-Programm OPTIKS scheint doch schon für PCL gewesen zu sein, der Menüpunkt lautet "HP Printer". Das hatte ich falsch in Erinnerung. Gibt es in neueren Windows-Druckerdialogen auch noch die Möglichkeit, in eine Datei der Endung ".prn" zu drucken anstelle der direkten Ausgabe auf den Drucker? https://fileinfo.com/extension/prn
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > in > eine Datei der Endung ".prn" zu drucken "Ausgabe in eine Datei" - aber auf dem Agilentgerät wird es das nicht geben, das läuft auch ganz sicher nicht unter Windows. Georg
Angehängte Dateien:
-
TDS210.png
4 KB
>Erzeuge mal ein paar Roh-Daten. Ich dachte auch nur ans Ausprobieren der folgenden Schritte. Mit dem Tek-Oszi war es einfacher, der liefert direkt BMP, aus dessen 34kByte werden als png 4. Die serielle Übertragung dauerte schon einige Sekunden. Etwa diese Qualität könnte auch Jochen erreichen. Jedenfalls deutlich besser als ein Foto vom Bildschirm, krumm und mit Reflexionen. An meinem ersten Arbeitsplatz hatten wir noch eine HP Polaroidkamera HP197 mit Abschirmtubus. http://www.ko4bb.com/manuals/195.243.14.34/HP_197B.PDF
:
Bearbeitet durch User
Christoph db1uq K. schrieb: >>Erzeuge mal ein paar Roh-Daten. > Ich dachte auch nur ans Ausprobieren der folgenden Schritte. > > Mit dem Tek-Oszi war es einfacher, der liefert direkt BMP, aus dessen > 34kByte werden als png 4. Die serielle Übertragung dauerte schon einige > Sekunden. > > Etwa diese Qualität könnte auch Jochen erreichen. Jedenfalls deutlich > besser als ein Foto vom Bildschirm, krumm und mit Reflexionen. > An meinem ersten Arbeitsplatz hatten wir noch eine HP Polaroidkamera > HP197 mit Abschirmtubus. > http://www.ko4bb.com/manuals/195.243.14.34/HP_197B.PDF Ich nehm mal an die Ausgabe des "PCL-Treibers" stützt sich nur auf wenige Befehle. GhostPCL wäre vielleicht etwas übertrieben. Wenns denn normales PCL ohne die Job-Sprache (PJL) drumrumm ist wäre mal so ein Mitschnitt interessant. Für den Einstieg reicht. https://www.pclviewer.com/de/resources/reference/index.html Wenns um das Interpretieren von Grafikbefehlen geht sind die 3 Dokumente http://www.hp.com/ctg/Manual/bpl13210.pdf (Generell) http://www.hp.com/ctg/Manual/bpl13211.pdf (Grafik u.a. mit HP-GL/2) http://www.hp.com/ctg/Manual/bpl13212.pdf (Farbsystem) interessant. so ein Python-script würde sich auch nicht so komplex gestalten. ich benutze es z.B. um die Programmbedingten Single und Double-Lines die durch - und = generiert werden wieder zu einer durchgängigen Linie zu machen. In PDF's sieht das sonst albern aus.
1 | #begin PCL-Parser |
2 | while t<len(u): |
3 | if u[t]==0x1b: |
4 | ... |
5 | elif u[t]==0xc4 or u[t]==0xcd: #-= Replace |
6 | s=u[t] |
7 | t2=1 |
8 | while u[t+t2]==s and (t+t2)<len(u): |
9 | t2=t2+1 |
10 | width=t2/fontwidth*720 |
11 | rulesingle= |
12 | b"\x1b&a-60V\x1b*c%ih5v0P\x1b&a+60v+%iH" |
13 | % (width,width) |
14 | ruledouble= |
15 | b"\x1b&a-72V\x1b*c%ih5v0P\x1b&a+24V\x1b*c%ih5v0P\x1b&a+48v+%iH" |
16 | % (width,width,width) |
17 | u=u[:t]+(ruledouble if s==0xcd else rulesingle)+u[t+t2:] |
18 | t=t+len(ruledouble if s==0xcd else rulesingle) |
19 | continue |
Ein kleiner Vorteil wäre, man könnte es in ein Micropython (auf einem ESP32 z.B.) pressen.
:
Bearbeitet durch Moderator
Vielen vielen Dank für die ganzen Hinweise! Ich habe mir jetzt endlich das passende Kabel gebaut und zwei "Screenshots" abgespeichert. Leider weiß ich nicht, welche Auflösung der Bildschirm hat, das ist nirgendwo dokumentiert. Viel mehr als QVGA wird es wohl nicht sein. Anbei zwei Dateien, das eine mit der Einstellung "Epson FX-80", das andere mit der Einstellung "Laserjet".
Habe jetzt dieses tolle Projekt gefunden: https://github.com/MurphyMc/EPHEX-80 Damit konnte ich aus der Epson-Datei ein transparentes SVG erzeugen, das die Bildschirminhalte korrekt darstellt. Nur die Größe der Bilddatei ist nicht in Ordung, aber das dürfte eine Kleinigkeit sein.
Satz mit X License expired bei meinem Pagetech-Pclreader.zip kann sein, dass die "hilfreichen Webseiten" auch nur das liefern. Schade, dann bleibt mir noch das uralte Optiks, mit allen Unarten alter DOS-Programme. Nur kurze Dateinamen ohne Sonderzeichen oder gar Spaces, auch im Pfad keine unzulässigen Namen. Das ganze nicht im DOS-Fenster sondern im Fullscreen DOS. Eventuell läuft es ja noch mit Freedos. Da gibt es sicher neueres für Laserjet. Der FX-80-Emulator sieht interessant aus, unsere ältesten Geräte kennen noch nicht mal Laserjet.
Habe es gerade mal ausprobiert! Funktioniert wunderbar mit dem Python-Skript, das den FX-80 emuliert. Es entsteht sogar ein bisschen Nadeldrucker-Nostalgie, weil das Skript einfach dunkelgraue Kreise malt, die sich ganz leicht überlappen. Einziger Nachteil ist, dass so natürlich die Dateigröße beim Export als PDF (mein Favorit für die Weiterverarbeitung) relativ groß wird. Wenn jetzt noch die Position der Nadelabdrücke mit einem leichten Rauschen überlagert wird, würde es wie ein echter Ausdruck aussehen ;)
Angehängte Dateien:
-
ct_10_86.jpg
75 KB
So muss das aussehen. Für eine Veröffentlichung sieht das jedenfalls
besser aus als ein Bildschirmfoto.
Besser ginge es noch, wenn man einen Bildschirmspeicher im Messgerät per
GPIB auslesen kann und die Schreibspur als Folge von XY-Werten bekommt.
Die kann man z.B. in HP-GL Vektorgrafik umwandeln.
>Parallel-Serien-Wandler der c't
ich habe es gefunden, aus der Computersteinzeit 10/1986. Es gab von
Heise auch eine Platine dazu, den Rest musste man selbst zusammenkaufen.
Zum oben genannten Arduinoprojekt braucht man nur noch einen
Centronics-Steckverbinder, dann geht das direkt über USB in den PC.
:
Bearbeitet durch User
Dirk B. schrieb: > Ebenso stammt GPIB von HP als HPIB. > Centronics ist eigentlich auch nur HPIB ohne das ganze Adressgedöns. Uff, das ist aber grob vereinfachen. Man könnte eher sagen, beides sind Parallelschnittstellen. Und ansonsten völlig inkompatibel.
Vor allem ist GPIB ein richtiger Bus mit wired-OR (open-collector Ausgänge), Centronics nur Punkt-zu-Punkt (USB ist irgendwo dazwischen, ohne Hub ist das auch nur Punkt-zu-Punkt).
Dirk B. schrieb: > Centronics ist eigentlich auch nur HPIB ohne das ganze Adressgedöns. Ein Auto ist eigentlich auch nur ein Pferdewagen, nur ohne Pferd... Oliver
MaWin schrieb: > Uff, das ist aber grob vereinfachen. > Man könnte eher sagen, beides sind Parallelschnittstellen. > Und ansonsten völlig inkompatibel. Nö, da ist Dirk deutlich näher an der Wahrheit. Dass man bei einer unidirektionalen Punkt-zu-Punkt-Verbindung ohne Schmankerl wie group execute trigger und ähnliche Späße auskommt, dürfte banal sein. Ergänzend sei darauf hingewiesen, dass CBM das HPIB-Protokoll für serielle Datenübertragung adaptiert hat. Und dann kam MIDI ... Du stellst damit einen sinnlosen Vergleich an.
:
Bearbeitet durch User
Angehängte Dateien:
-
test.png
6,2 KB -
Zwischenablage01.png
120 KB
In der PCL sind auch nur Raster-Daten. Der Aufwand hielte sich in Grenzen. Als Anhang test.png die mit GPCL6 konvertierte "printfile-laserjet.bin". Für eine Analyse taugt https://github.com/michaelknigge/pclparaphernalia Screenshot Anhang Zwischenablage01.png
>paraphernalia
Das Wort hatte ich schon gelegentlich gelesen, aber die Bedeutung nicht
gewußt:
"Grabbeigaben"
da wird also PCL zu Grabe getragen.
Christoph db1uq K. schrieb: >>paraphernalia > Das Wort hatte ich schon gelegentlich gelesen, aber die Bedeutung nicht > gewußt: > "Grabbeigaben" > da wird also PCL zu Grabe getragen. Keine Ahnung wie Du auf "Grabbeigaben" kommst: https://en.wikipedia.org/wiki/Paraphernalia https://www.merriam-webster.com/dictionary/paraphernalia
https://de.wikipedia.org/wiki/Paraphernalien Ok, scheint mehrere Bedeutungen zu haben, das war nur die erste Fundstelle auf Wikipedia. Also "Nebengabe" "Beigabe" bells & whistles sagt man auf Englisch für nutzlose Zugaben, Glöckchen und Trillerpfeifen am Geschenkpaket
:
Bearbeitet durch User
Christoph db1uq K. schrieb: > da wird also PCL zu Grabe getragen. Durch was soll es denn ersetzt werden? Postscript gibt es nur noch bei hochwertigen(-preisigen) Druckern. Georg
Georg schrieb: > Postscript gibt es nur noch bei hochwertigen(-preisigen) Druckern. Ich habe eigentlich eher den Eindruck, dass das früher mal so war. Für die alten LaserJet musste man Postscript noch als teuren Add-in-Modul kaufen. Aktuelle haben das seit langer Zeit dabei. Aber trotzdem sehe ich PCL nicht aussterben.
Jörg W. schrieb: > Aber trotzdem sehe ich PCL nicht aussterben. Versteht PCL6 nicht auch GDI von Windows.
Um noch einmal das Thema des Threads aufzugreifen: Gibt es fertig für einen Raspi: Retro Computer / Equipment > Centronics Port > Retro-Printer Module > USB > Printer https://www.retroprinter.com/ Das Teil hängt bei mir am Parallel-Port eines Audio Precision ATS-1 Audio Analyzers Bj. 1990. Funktioniert perfekt.
Jochen H. schrieb: > Das Teil hängt bei mir am Parallel-Port eines Audio Precision ATS-1 > Audio Analyzers Bj. 1990. Was gibt der denn aus? Wenn ich den Text im Link korrekt interpretiere, versteht der von Dir beschriebene Wandler ESC/P. TE will aber die Ausgabe von HP bzw Agilent auswerten, die ich eher der Ausgabe von HPGL oder eher PCL verdächtigen würde.
Aus der Doku: >We also support HP PCL printer capture. This is stored as raw PCL printer >data without any conversion. We have included instructions in the manual >to explain how to install GhostPCL to convert these raw PCL printer files >to PDF as they are generated. Das setze ich auch ein, da mein ATS-1 PCL ausgibt. Die rohen PCL-Daten werden automatisch per GhostPCL in ein PDF umgewandelt und dann über WLAN in ein Ausgabeverzeichnis auf mein NAS kopiert. Da habe ich dann die Prints auch gleich mit Zeitstempel archiviert...
:
Bearbeitet durch User
>Aber 55 £ tun weh ...
Ja, stimmt schon. Der Raspi kommt ja dann auch noch dazu...
Aber bei Geräten die nur ein Centronics-Interface haben, ist die Sache
halt schwierig.
- Selbst ein IF bauen, um die PCL Rohdaten zu erfassen und dann weiter
mit GhostPCL & Co.
- Einen alten Drucker mit Parallel-Port kaufen.
Letzteres habe ich zuvor gemacht und mir einen gebrauchten Deskjet 450
gekauft, da ich meinen Meßplatz nicht mit einem Monster-Drucker zumüllen
wollte. Ein Tinten-Spritzer hat allerdings einen massiven Nachteil. Da
ich nicht regelmäßig drucke, trocknet ebenso regelmäßig die Tinte ein.
Ich habe dann nach jedem Druck die Patrone entfernt, den Druckkopf
abgeklebt und in eine Tupperdose gelegt. Das funktioniert, nervt aber
:-)
Also wäre ein Nadeldrucker hier die deutlich bessere Wahl. Ist aber zu
groß und umsonst bekommst du diese auch nicht mehr. Dann stellt sich
hier zudem noch die Frage nach Ersatz-Bändern.
Da ist mir die Lösung mit dem Retro-Printer lieber....
Jochen H. schrieb: > Aber bei Geräten die nur ein Centronics-Interface haben, ist die Sache > halt schwierig. > > Selbst ein IF bauen, um die PCL Rohdaten zu erfassen und dann weiter mit > GhostPCL & Co Nun, die 55 £ relativieren sich, falls man Nutzen aus dem vermutlich enthaltenen ESC/P-Interpreter ziehen kann; ansonsten wäre es nicht mehr als ein simpler Centronics-Grabber-Dongle. Und der wäre mit 55 Pfündern deutlich überbezahlt, jedenfalls für neinen Geschmack (ich nag nicht daran denken, was Mitte der 80er gewöhnliche Druckerkabel gekostet haben, von etwas spezielleren ganz zu schweigen). Gut, Selbstbau wird bei realistischem "Eigenlohn" zu dem Preis wohl eher nicht möglich sein. Trotzdem schmerzt der Preis ... Aber immerhin: das Problem des TE ist (zumindest technisch) gelöst. Für een wirtschaftlichen Teil sind wir nicht zuständig.
Percy N. schrieb: > Wenn ich den Text im Link korrekt interpretiere, versteht der von Dir > beschriebene Wandler ESC/P. > > TE will aber die Ausgabe von HP bzw Agilent auswerten, die ich eher der > Ausgabe von HPGL oder eher PCL verdächtigen würde. Der TO schrieb aber auch dass das Gerät Ausgaben für den FX-80 machen kann. Und der ist ja eigentlich das Standardgerät für ESC/P.
Dirk B. schrieb: > Der TO schrieb aber auch dass das Gerät Ausgaben für den FX-80 machen > kann. Und der ist ja eigentlich das Standardgerät für ESC/P. Stimmt. Und ich muss mich korrigieren: Sein Problem ist keineswegs gelöst. Er hat erklärtermaßen kein Problem damit, die Daten in seinen PC zu bekommen, sondern ihm fehlt ein Renderer, der ihm eine Grafikdatei in einem gängigen Format erzeugt.
Percy N. schrieb: > Dirk B. schrieb: >> Der TO schrieb aber auch dass das Gerät Ausgaben für den FX-80 machen >> kann. Und der ist ja eigentlich das Standardgerät für ESC/P. > > Stimmt. > > Und ich muss mich korrigieren: Sein Problem ist keineswegs gelöst. Er > hat erklärtermaßen kein Problem damit, die Daten in seinen PC zu > bekommen, sondern ihm fehlt ein Renderer, der ihm eine Grafikdatei in > einem gängigen Format erzeugt. Von GhostPCL (TIFF/PDF/PNG/PCX/JPG) bis zum eigenem Skript (z.B.Python+Pillow) ist da alles möglich. Als Insellösung könnte das auch so ein ESP32 mit den passenden Pegelwandlern bei Centronics und das bis in die "Cloud" eventuell mit nem Li-Akku.
Percy N. schrieb: > Und ich muss mich korrigieren: Sein Problem ist keineswegs gelöst. Er > hat erklärtermaßen kein Problem damit, die Daten in seinen PC zu > bekommen, Das ist seit Anfang an klar, wurde aber gerne übersehen. > sondern ihm fehlt ein Renderer, der ihm eine Grafikdatei in > einem gängigen Format erzeugt. Dazu gab es genug Hinweise, die aber teilweise zwischen den Datenübertragungsbeiträgen verschwinden
Eine Frage für den Threaderöffner. Mit welcher Geschwindigkeit kann man bei der Rs232-Schnittstelle maximal rechnen ?
:
Bearbeitet durch User
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.