Ausdruck über serielle Schnittstelle GPIO - cartoonify

[darkKyle]

Hallo,
ich habe auf einem Raspberry das Github Projekt cartoonify zum laufen gebracht. Allerdings geht der automatische Ausdruck über den Thermodrucker an der seriellen Schnittstelle des Pi nicht.

https://github.com/danmacnish/cartoonify

Ich habe keine Ahnung von python. Habe zwar schon die Dateien durchsucht und an einer Stelle eine Änderung bezüglich des Druckers vorgenommen, aber das war es wohl nicht. Funktioniert jedenfalls noch nicht.

Kann mir jemand die Stelle in welcher Datei auch immer sagen, wo der Ausdruck / Ausgabe auf den Drucker erfolgt?

Der Thermodrucker ist per cups installiert, dann würde ich die Stelle anpassen.

Vielen Dank.
Gruß

[__blackjack__]

@darkKyle: Ich vermute mal das ist keine Python-Frage weil das Programm einfach CUPS' ``lp`` verwendet um zu drucken. Beim „Troubleshooting“ der letzte Punkt: „Check that you can manually print something from the thermal printer from the command line.“

Geht das denn? Kannst Du mit ``lp -o landscape -c bilddatei.jpg`` von der Shell aus eine Bilddatei drucken? Falls nicht, ist das das Problem.

[darkKyle]

Hallo,

@darkKyle: Ich vermute mal das ist keine Python-Frage weil das Programm einfach CUPS' ``lp`` verwendet um zu drucken. Beim „Troubleshooting“ der letzte Punkt: „Check that you can manually print something from the thermal printer from the command line.“

Geht das denn? Kannst Du mit ``lp -o landscape -c bilddatei.jpg`` von der Shell aus eine Bilddatei drucken? Falls nicht, ist das das Problem.

Ja, ich kann über CUPS per bash drucken.

Wo hast du denn die Stelle gefunden, wo "lp" in dem Script genutzt wird?
Welche Datei(en)?

Gruß

[__deets__]

In github oben links im Suchfeld "lp" eingeben, und im repository suchen. Kommt genau ein Treffer.

https://github.com/danmacnish/cartoonif ... low.py#L68

[darkKyle]

In github oben links im Suchfeld "lp" eingeben, und im repository suchen. Kommt genau ein Treffer.

https://github.com/danmacnish/cartoonif ... low.py#L68

Hm, okay danke. Sieht auf den ersten Blick ja dann komisch aus, warum es bei mir nicht geht.
--> lp -o fit-to-page /usr/share/raspberrypi-artwork/raspberry-pi-logo.png
druckt z.B. ein schönes Pi Logo auf dem Drucker.

Über die Suche habe ich run.py gefunden, wo der Wert print_cartoon auf True übergeben (?) wird. Aber in der workflow steht etwas über deiner Fundstelle
"def run(self, print_cartoon=False):"

Liegt hier ein Problem? Würde zumindest auch erklären, warum ich damals in keinem Log iwie eine Fehlermeldung wegen Druck fand.

Danke dir,
Gruß

[darkKyle]

Hm, sorry für das Doppelposting. Aber scheinbar kann man seinen Beitrag nicht (mehr) bearbeiten.

Ich habe mal testweise Änderung an der workflow.py gemacht. z.B. einfach mal direkt nach der Zeile über "self._logger.info('text')" etwas ins log schreiben lassen. Das kam auch ins File. Also hat er zumindest die Stelle auch durchlaufen.

Da ich aber wie gesagt python nicht kenne, weiß ich nicht ob die Zeile ansich davor korrekt ist. Wie gesagt, über "lp ...." kann ich drucken in der bash.

Kann mir sonst jemand sagen, ob diese Zeile in dem Script so gehen müsste?

Code: Alles auswählen

            self._logger.info('start druck')
            if print_cartoon:
                subprocess.call(['lp', '-o', 'fit-to-page', str(cartoon)])
                self._logger.info('druck done')
            self.gpio.set_status_pin(False)

Die "self._logger.info" kommen wie gesagt gerade wegen debug vor.

Danke.

[__deets__]

Wenn das an der Stelle vorbeikommt, dann liegt das Problem prinzipiell erstmal nicht in Python. Denn einfach ueberspringen tut der nix. Du kannst die subprocess-Zeile mal ersetzen mit

Code: Alles auswählen

subprocess.check_call(['lp', '-o', 'fit-to-page', str(cartoon)])

also nur "check_" davor - dann kann man sehen, ob der Aufruf fehlschlaegt. Das Programm sollte dann abstuerzen mit einem SubprocessError oder etwas aehnlichem. Wenne es das NICHT tut, dann haengt es irgendwo in CUPS, User-Rechten etc.

[darkKyle]

Wenn das an der Stelle vorbeikommt, dann liegt das Problem prinzipiell erstmal nicht in Python. Denn einfach ueberspringen tut der nix. Du kannst die subprocess-Zeile mal ersetzen mit

Code: Alles auswählen

subprocess.check_call(['lp', '-o', 'fit-to-page', str(cartoon)])

also nur "check_" davor - dann kann man sehen, ob der Aufruf fehlschlaegt. Das Programm sollte dann abstuerzen mit einem SubprocessError oder etwas aehnlichem. Wenne es das NICHT tut, dann haengt es irgendwo in CUPS, User-Rechten etc.

Wo würde ich diese Fehler sehen? Ich habe das Script ja im Autorun und sehe somit keine Meldungen direkt von python.

[__blackjack__]

Was ist denn der ”Autorun”? Und wie ist das wenn Du das mal nicht automatisch startest, sondern manuell?

[darkKyle]

Was ist denn der ”Autorun”? Und wie ist das wenn Du das mal nicht automatisch startest, sondern manuell?

/etc/rc.local

sonst starte ich es normal in der bash, über das ./raspi-run

Da sehe ich nirgends Fehlermeldung, daher gestaltet sich der Debug für mich ja schwierig (mal ab von meiner Unkenntnis was python angeht.

[__blackjack__]

@darkKyle: Druckt es denn wenn Du es manuell in der Shell startest? Was ist mit dem anderen Troubleshooting-Tip? Werden die Dateien erstellt?

[darkKyle]

@darkKyle: Druckt es denn wenn Du es manuell in der Shell startest? Was ist mit dem anderen Troubleshooting-Tip? Werden die Dateien erstellt?

Ist egal, ob ich das Script in den /etc/rc.local packe oder nach dem Boot per ./raspi-run starte, er druckt nie.

Du meinst die CUPS User Rechte? Da weiß ich nicht, wie ich das filtern soll.
Laut ps aux läuft das Script als root, und ein "sudo lp -o fit-to-page -c datei" druckt eben.
Läuft der Aufruf lp in dem workflow nicht auch unter root - unter welchem User sonst?

Gruß

[darkKyle]

Ich habe gerade mal auf dem Pi in "Thonny IDE" ein kleines Python Script getestet,

Code: Alles auswählen

import subprocess
subprocess.call(['lp', '-o', 'landscape', '-c', 'dateiname.png'])

Die Shell meldete daraufhin Anfrage ID an den Drucker und der Drucker lief - druckte die Datei aus.

Also generell scheint es über python zu gehen - nur nicht aus dem cartoonify Script.
Können es wirklich die CUPS Rechte sein - wie kann ich das checken?

Danke,
Gruß

[__deets__]

Du koenntest zb den Prozess der auto-gestartet wurde mal anschauen, welchen Benutzer der hat. Und dann der Benutzer werden, und es auf der Kommandozeile probieren.

[darkKyle]

Du koenntest zb den Prozess der auto-gestartet wurde mal anschauen, welchen Benutzer der hat. Und dann der Benutzer werden, und es auf der Kommandozeile probieren.

Hm, im Autostart liegt die "raspi-run.sh"

Code: Alles auswählen

pi@raspberrypi:~/cartoonify $ cat raspi-run.sh
#!/usr/bin/env bash
sudo docker run -d \
 --mount type=bind,source=$(pwd)/cartoonify,target=/cartoonify \
 --restart unless-stopped \
 --device=/dev/ttyS0 \
 --device /dev/mem:/dev/mem \
 --device=/dev/serial0 \
 --privileged \
 -p 8081:8081 \
 -p 8082:8082 \
 -w /cartoonify \

Code: Alles auswählen

 cartoonifypi@raspberrypi:~/cartoonify $ ps aux | grep cart
root      1378 99.4 31.0 450808 273348 ?       Rl   08:13  13:17 /usr/local/bin/python /usr/local/bin/cartoonify --raspi-headless --raspi-gpio


pi@raspberrypi:~/cartoonify $ ps aux | grep docker
root       507  0.3  5.3 967296 46956 ?        Ssl  08:13   0:02 /usr/bin/dockerd -H unix://
root      1084  0.0  0.2 792628  2188 ?        Sl   08:13   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8082 -container-ip 172.17.0.2 -container-port 8082
root      1098  0.0  0.2 792628  2188 ?        Sl   08:13   0:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8081 -container-ip 172.17.0.2 -container-port 8081
root      1111  0.0  0.5 794580  4420 ?        Sl   08:13   0:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux [.....]

Also läuft das Ding als root?

Unter sudo oder su root druckt er mit "lp....."

Oder habe ich was falsch verstanden?

Gruß

[Sirius3]

Du startest ja nicht das Programm, sondern einen Docker-Container und der kennt natürlich keinen Drucker, weil ein Container ja gerade dazu da ist, alles abzukapseln. Da wird zwar ein /dev/serial0 durchgeschleust, aber ist das auch der Port, den der Drucker benutzt?

[darkKyle]

Der Drucker wurde ja als Cups von dem Install Script mit eingerichtet, daher gehe ich mal davon aus.
Allerdings gab es da ja mal eine Änderung zwischen Raspi 2/3 und dem Rasbian meine ich.
Daher habe ja einige ältere Scripte Probleme mit der Sache. Muss ich morgen mal checken.

[darkKyle]

Du startest ja nicht das Programm, sondern einen Docker-Container und der kennt natürlich keinen Drucker, weil ein Container ja gerade dazu da ist, alles abzukapseln. Da wird zwar ein /dev/serial0 durchgeschleust, aber ist das auch der Port, den der Drucker benutzt?

So, du sprichst vom "dockerfile"? Kommt das nicht nur beim Install zum tragen? Jedenfalls hatte ich das und startup.sh mal angepasst vor einem Install, was allerdings auch nichts brachte.

Aber kann das denn überhaupt wirklich das Problem sein? Der Aufruf zum Druck kommt ja definitiv aus der workflow.py und dort passt der Aufruf.

Ansonsten was wäre deine Idee für die Lösung zu dem Problem, was du hier vermutest?
Gruß

[Sirius3]

Ich kenne Dein System nicht, aber zum Drucken muß Docker den Zugriff aus dem Container auf den Drucker erlauben.

Warum benutzt Du überhaupt Docker?

[sparrow]

Docker wird er benutzen, weil das Projekt das so in der Readme schreibt.
Und damit sind wir wieder bei dem alten Problem, dass dem Benutzer Techniken an die Hand gegeben werden, die er weder kennt noch beherrscht.