Kommunikationsfehler -1

Drucken über das Netzwerk
Antworten
Paul
Beiträge: 9
Registriert: Mi 15 Jul, 2009 06:57

Kommunikationsfehler -1

Beitrag von Paul » Mi 15 Jul, 2009 07:09

Hallo

Nachdem ich Turboprint seit einigen Jahren problemlos eingesetzt habe gibt es plötzlich ein Problem beim Drucken über's Netzwerk.

Wenn ich im Client den TP-Druckermonitor öffne erscheint dort "Kommunikationsfehler -1". Es ist keine Statusabfrage wie z.B. Tintenstand oder Verbrauchsanzeige mehr möglich. Das Drucken selbst geht nach wie vor.

Ich habe den Drucker auf dem Server und Client testhalber gelöscht und neu angelegt, ohne Änderung.

Auf dem Client ist der Drucker über die Verbindungsart CUPS URI mit der URI ipp://server/printers/tp0 verbunden. Gibt es einen Unterschied zur Verbindungsart IPP, außer, das die URL etwas anders aussieht?

Für jede Hilfe dankbar.

Hat wohl nichts mit dem Problem zu tun, trotzdem komisch:
Beim Neuanlegen auf dem Server ist mir zudem noch aufgefallen, daß mir zwei Drucker angezeigt werden (obwohl nur einer angeschlossen ist): Der eine heisst Canon i560 TP-USB#1 und hat die URI tpu://Canon/i560usb
Der andere heißt "Canon i560" und hat die URI hal://freedesktop.org/Hal/usb_device_49a...._if0_printer_noser.
Mit beiden Druckern kann man drucken. Was bedeutet das?

zedonet
Administrator
Beiträge: 1506
Registriert: Fr 29 Sep, 2006 13:10

Beitrag von zedonet » Mi 15 Jul, 2009 11:09

Hallo Paul,

die Fehlermeldung besagt, daß über die Netzwerkverbindung keine Daten vom TurboPrint Dämon des Servers erhalten werden.
Läuft der tprintdaemon auf dem Server? Falls der TurboPrint-Monitor, der direkt am Server läuft schon einen Fehler meldet, kann natürlich der Client auch nichts anzeigen.
Ist der TCP Port auf Server und Client der gleiche (siehe /etc/turboprint/system.cfg unter TPDAEMON_PORT)?
Ist eine Firewall auf Client oder Server aktiv, die den Port 5552 blockiert (bzw. den in system.cfg eingestellten Port)?

Paul
Beiträge: 9
Registriert: Mi 15 Jul, 2009 06:57

Beitrag von Paul » Mi 15 Jul, 2009 15:28

Natürlich läuft der Daemon auf dem Server, und der Server ist auch an. Es druckt ja auch? OP nicht gelesen?
Wenn der TP-Daemon auf dem Server nicht läuft gibt es die sinnvolle Meldung: "keine Verbindung zum Remote-Daemon" und nicht Kommunikationsfehler -1.
Sind denn keine Entwickler hier im Forum? Niemand sonst kann ja eigentlich wissen, was diese kryptische Meldung bedeutet.

Wie kann man denn den Loglevel erhöhen? Das Turboprint-log ist leer.

Paul
Beiträge: 9
Registriert: Mi 15 Jul, 2009 06:57

Beitrag von Paul » Mo 20 Jul, 2009 17:18

Hallo, mein Problem besteht leider immer noch.

Gibt's hier keinen Support? :-(

zedonet
Administrator
Beiträge: 1506
Registriert: Fr 29 Sep, 2006 13:10

Beitrag von zedonet » Mo 20 Jul, 2009 17:26

Drucken funktioniert auch ganz ohne den TurboPrint Daemon, dieser ist nur für Druckerstatus und Tintenstand zuständig. Mit welchem der beiden eingerichteten Drucker ist der Client verbunden bzw. welche URI hat der "tp0" Drucker dort? Statusabfrage kann nur mit der URI "tpu://" funktionieren.
Wird direkt am Server der Status korrekt angezeigt - falls dort eine grafische Oberfläche und TurboPrint Monitor installiert sind?

Die kryptische Meldung erscheint nur, wenn zwar eine Verbindung zum Dämon erstellt wurde, von dort aber keine Antwort zurückkommt. Möglicherweise hängt der Dämon am Server bei der Statusabfrage - deshalb die Frage, ob dort der Status korrekt gezeigt wird, oder die gleiche Meldung kommt - dann wäre zumindest das Netzwerk als Fehlerquelle ausgeschlossen.

Paul
Beiträge: 9
Registriert: Mi 15 Jul, 2009 06:57

Beitrag von Paul » Mo 20 Jul, 2009 18:57

zedonet hat geschrieben:Drucken funktioniert auch ganz ohne den TurboPrint Daemon, dieser ist nur für Druckerstatus und Tintenstand zuständig. Mit welchem der beiden eingerichteten Drucker ist der Client verbunden bzw. welche URI hat der "tp0" Drucker dort?
Nach weiteren Experimenten habe ich jetzt sogar 3 Drucker:

Bild

Der erste hat den Anschluß "Canon i560", der zweite "Canon i560 USB #1" und der dritte "Canon i560 TP-USB#1"

Der Client benutzt zur Zeit den Dritten drucker.
Dieser wird über zwei Methoden angesprochen:

1.
Verbindung: "andere (CUPS URI),
URI: http://Atlas:631/printers/tp2
Damit kann man drucken.
Es kommen aber keine Statusmeldungen beim Client an.
Status: "keine Informationen verfügbar"
UPDATE: Man kann auch mit dieser Konfiguration nicht (mehr?) drucken. Der Druck einer Testseite funktioniert. Wenn ich aber aus einer Anwendung drucken will passiert folgendes:
Acrobat: The Document could not be printed. (Ein anderes PDF hat funktioniert)
KPDF: Beim Server kommt nichts an und der Status-Monitor auf dem Client schaltet den Drucker auf "gestoppt". (Ein anderes PDF hat funktioniert).
Gimp: Druckt.
Direkt vom Server kann ich das bockende PDF problemlos mit allen Programmen drucken. Ich kapiere langsam gar nichts mehr.

2.
Verbindung: "andere (CUPS URI),
URI: tpu://Atlas:631/printers/tp2
Damit geht nichts.
Status am Client: "Drucker nicht angeschlossen oder abgeschaltet"

Warum beendet sich der Status-Monitor auf dem Client eigentlich bei jeder Gelegenheit selbst?
Statusabfrage kann nur mit der URI "tpu://" funktionieren.
Wird direkt am Server der Status korrekt angezeigt - falls dort eine grafische Oberfläche und TurboPrint Monitor installiert sind?
Zumindest auf dem Server wird der Status auch mit der URI usb://Canon/i560 angezeigt.
Kann man die TPU:// URL auch auf dem Client angeben, und wie genau sähe die aus?
Die kryptische Meldung erscheint nur, wenn zwar eine Verbindung zum Dämon erstellt wurde, von dort aber keine Antwort zurückkommt. Möglicherweise hängt der Dämon am Server bei der Statusabfrage - deshalb die Frage, ob dort der Status korrekt gezeigt wird, oder die gleiche Meldung kommt - dann wäre zumindest das Netzwerk als Fehlerquelle ausgeschlossen.
Der Status wird am Server korrekt angezeigt, wenn der Server oder ein Client einen Druckauftrag abschickt. Auch Tintenstandabfrage usw. funktionieren auf dem Server.

Dieses ganze unausgegorene Linux-Druckergefrickel treibt mich schon seit meinem ersten Kontakt mit diesem BS zum Wahnsinn. Das zusätzliche TurboPrint macht die Sache leider auch nicht gerade durchschaubarer.

zedonet
Administrator
Beiträge: 1506
Registriert: Fr 29 Sep, 2006 13:10

Beitrag von zedonet » Di 21 Jul, 2009 10:08

Die URI am Client sollte "ipp://Atlas:631/printers/tp2" lauten, "tpu://" kann immer nur mit einer lokalen USB-Schnittstelle verbunden werden, über das Netzwerk ist das bei CUPS nicht vorgesehen.
Wenn die Druckerwarteschlange am Server gestoppt wurde, ist beim Drucken ein Fehler aufgetreten. Dieses Verhalten läßt sich übrigens in CUPS definieren, ob der Auftrag im Fehlerfall einfach verworfen, oder die Warteschlange gestoppt werden soll.

Hierzu muß ich auch bemerken, daß das Drucken über das Netzwerk, ob von Windows oder von Linux Clients, eine Aufgabe des CUPS Druckerspoolers ist, und im eigentlichen Sinne nichts mit dem Druckertreiber bzw TurboPrint zu tun hat, der lediglich am Server dann von CUPS die Daten zum Drucken bekommt. TurboPrint ergänzt nur zusätzlich den TurboPrint Daemon für die Statusmeldungen.

Paul
Beiträge: 9
Registriert: Mi 15 Jul, 2009 06:57

Beitrag von Paul » Di 21 Jul, 2009 10:42

zedonet hat geschrieben:Die URI am Client sollte "ipp://Atlas:631/printers/tp2" lauten, "tpu://" kann immer nur mit einer lokalen USB-Schnittstelle verbunden werden, über das Netzwerk ist das bei CUPS nicht vorgesehen.
Leider funktioniert ipp:// genau so gut/schlecht wie http://. Es druckt, aber es wird immer noch wechselweise "Verbindungsaufbau..." und "Kommunikationsfehler: -1" angezeigt.
Wenn die Druckerwarteschlange am Server gestoppt wurde, ist beim Drucken ein Fehler aufgetreten. Dieses Verhalten läßt sich übrigens in CUPS definieren, ob der Auftrag im Fehlerfall einfach verworfen, oder die Warteschlange gestoppt werden soll.[/qupte]
Danke für den Hinweis.
...TurboPrint ergänzt nur zusätzlich den TurboPrint Daemon für die Statusmeldungen.
Das verstehe ich jetzt nicht. Muss ich "TurboPrint daemon" vielleicht durch "CUPS daemon" ersetzen?

Antworten