Thermodrucker unter FreeBSD

Sickboy

Müßiggänger
Hallo allerseits,

momentan versuche ich, einen billigen Thermodrucker der Marke Centronics unter FreeBSD 11.1 zum Laufen zu bekommen. Das Ding wird für 10 € im Internet angeboten und hat eine IEEE-1284-Schnittstelle (Parallel-Port). Das mitgelieferte 25-pol.-auf-USB-Adapterkabel habe ich erst einmal entsorgt, weil China-Schrott mit Fake-Chip. Mit einem neuen Adapterkabel kommen zumindest schon mal ein paar Zeichen aus dem Drucker, nur noch nicht die richtigen. Es wird von FreeBSD wie folgt erkannt:
Code:
ulpt0 on uhub3
ulpt0: <vendor 0x1a86 USB2.0-Print, class 0/0, rev 1.10/2.54, addr 3> on usbus1
ulpt0: using bi-directional mode
Danach habe ich zwei neue Device-Nodes: /dev/unlpt0 (ohne reset) und /dev/ulpt0 (mit reset).

Um zu drucken, muss ich eigentlich nur in das Device schreiben:
Code:
$ cat text.txt | unix2dos | iconv -f UTF-8 -t 437 > /dev/ulpt0
Leider kommt nur Buchstabensalat aus dem Drucker (TIX W statt UNIX FOR THE WIN). Der Drucker versteht, soweit ich weiß, nur Codepage 437. Unter Microsoft Windows funktioniert er ohne Probleme.

Hat jemand Hinweise?
 
Ich würde erstmal unlpt0 probieren; dann kommen keine störenden Steuerzeichen
echo -e "abc \012 \015 def" >/dev/unlpt0

Daß das Ding so alt ist, daß es noch TTL Signale braucht (und den Treiber im USB Konverter überlastet), glaube ich dann doch nicht.
 
Den Parameter -e kennt mein echo nicht. Wenn ich zum Beispiel
Code:
$ printf "UNIX\r\n" | unix2dos > /dev/unlpt0
aufrufe, wird nur ein X gedruckt. Immer fehlen Buchstaben.
 
probier mal mehrmals
echo -n "a" >/dev/unlprt0; echo -n "bcdefg" >/dev/unlpt0; echo -n "y" >/dev/unlpt0; echo "z" >/dev/unlpt0

Ist das Ergebnis immer gleich? (Evtl. verschluckt sich der Drucker und wird vom Interface "überfahren"
echo -n heißt "wandle die Oktalzahlen, hier \012, \015" (CR und LF
 
Egal, ob ich echo oder printf nutze, von jeweils vier Zeichen wird nur das letzte gedruckt (also nur D von ABCD). So auch bei deinem Beispiel: von bcdefg wird nur e gedruckt. Mein Terminal ist auf UTF-8 gesetzt. Ob das ursächlich ist? (Edit: Bei Latin-1 das gleiche Ergebnis.)
 
Ich werfe noch mal LF vs CR-LF in den Ring. Ich würde aber erwarten, dass es nur Zeilenumbrüche verhunzt und nicht in den Fließtext eingreift.
 
Falls das Teil verschiedene Druckmodi kennt,
könnte es sein dass zuerst (also vor den ersten zu druckenden Zeichen )
irgendeine Escape-Sequenz erwartet wird.
Dann schreibst Du, dass das Ding eine IEEE-1284-Schnittstelle ( bidirectional )hat.
Ist das eine Vermutung - oder ist das wirklich so?
Oder ist es doch noch eine uralte Centronics ( unidirectional )?

Gruss walter
 
Das mitgelieferte 25-pol.-auf-USB-Adapterkabel habe ich erst einmal entsorgt, weil China-Schrott mit Fake-Chip.
Was aber vielleicht auch leichtsinnig war?
Du kennst ja (vermutlich) keine Details zu dem Drucker und weißt gar nicht, was der vielleicht braucht.
Wie auch immer, ich hätte es auf jeden Fall erst mal mit dem gelieferten Kabel probiert, wenn nicht ein direkter Anschluss mit Parallel-Port (alter PC) zur Verfügung steht.
Außerdem kann ich mir vorstellen, das "alles für ein Microsoft" mitgeliefert wird, also evtl auch spezielle Treiber etc. Vor einem Experiment würde ich erst die Funktion des gelieferten Teils testen wollen und das möglichst in einem beschriebenen Zustand, also Notfalls mit einem Microsoft und allem drum herum. Es es ist nicht von der Hand zu weisen, dass man ein ganz anderes Gefühl beim experimentieren hat, wenn man gewiss sein darf, dass das Testgerät ja überhaupt vollständig funktioniert.
 
Falls das Teil verschiedene Druckmodi kennt,
Nein. Unter Linux funktioniert es genau so:
Code:
$ echo -e "Test\r\n" | unix2dos | iconv -f UTF-8 -t 437 > /dev/usb/lp0
Und unter Windows funktioniert der interne "Generic / Text only"-Treiber. Das Ding ist also wirklich einfach aufgebaut, und druckt, was man über die IEEE-1284-Schnittstelle schickt. Ich sehe da eher ein Problem mit dem ulpt-Treiber von NetBSD. Irgendetwas wird da anders umgesetzt, als unter Linux.

Oder ist es doch noch eine uralte Centronics ( unidirectional )?
Nein, kein Centronics.

Wie auch immer, ich hätte es auf jeden Fall erst mal mit dem gelieferten Kabel probiert, wenn nicht ein direkter Anschluss mit Parallel-Port (alter PC) zur Verfügung steht.
Das ist nur ein einfaches Adapter-Kabel: IEEE-1284 zu USB mit gefaktem Prolific-Chip. Funktionierte bei einem Test mit Windows, aber nicht unter FreeBSD. Das neue Kabel ohne Fake-Chip läuft auch unter FreeBSD.
 
Unter Linux funktioniert es genau so:
mir war wichtig, dass man irgendwie sicher machen kann, dass das Teil überhaupt richtig funktioniert. Womöglich hatte ich das überlesen.

Von FreeBSD her weiß ich, dass auch der echo Befehl etwas anders funktioniert, als unter einem GNU/Linux. Ob das shell-abhängig ist, kann ich nicht sagen. Um das auszuschließen, könntest du vielleicht noch alternative Kommandos mit printf unter unterschiedlichen Systemen testen. Es wird sich aber vermutlich dein Verdacht damit nur erhärten und keine Lösung daraus für dich ableiten.
 
Zurück
Oben