Raspberry Pi als Zwischenelektronik für Labelsoftware

  • Guten Tag alle miteinander!


    Zuerst einmal möchte ich mich entschuldigen, falls der Beitrag im falschen Thema/Bereich landet, ich nutze eigentlich nie Foren!

    Aktuell wirke ich bei einem Projekt mit, wo der Einsatz eines Raspberry Pi's durchaus sinnvoll ist. Momentan wird nach einer gewissen Anzahl an gescannten Objekten (z.B. 5) von der zuständigen Labelsoftware automatisch ein Label gedruckt. Dies soll zwar weiterhin automatisch passieren, jedoch soll eine Anwesenheitsprüfung durch eine Kamera zusätzlich "grünes Licht" geben. Erst dann soll das Label wirklich gedruckt werden.


    Leider besitzt mein Team keinen Zugriff auf die Software, da diese zentral gesteuert wird und somit eine Anpassung des Quellcodes nicht möglich ist.


    Meine Überlegung dazu:

    Ein Raspberry Pi als "Übermittler" bzw. Zwischenelektronik einsetzen, welcher sowohl die Daten der Labelsoftware als auch das entsprechende I/O-Signal der Kamera empfängt. Weitergegeben werden die Daten erst, wenn das Auswertungsprogramm (müsste man natürlich selbst schreiben) "grünes Licht" gibt. Die Datenkommunikation findet über RS232-Schnittstellen statt, wobei diese ja einfach per USB-RS232-Adapter an den Pi angeschlossen werden können.


    Nun zu meinem Problem/Fragen:


    Ist diese theoretische Überlegung einfach so möglich? Leitet der PC die Daten trotzdem weiter, auch wenn der Pi nicht wirklich ein Drucker ist oder kann man das als Außenstehender nicht beurteilen (heißt, ich sollte Kontakt zu Verantwortlichen der Software aufnehmen)?


    Generell war meine Überlegung, dass der Pi den Port zum PC dauerhaft abliest und falls etwas kommt, diese Daten abspeichert.


    Falls das möglich ist, ist der Rest wahrscheinlich nicht weiter schwierig! Falls nicht - habt ihr eine andere Idee bzw. eine Lösung?


    Vielen Dank schon einmal!

  • Ich war beruflich viel bei Warenversendern in der Produktion, auch und gerade an den Packstationen mit den Labelprintern. In der Regel waren das "geschlossene" Systeme, dass heißt, WWS und darauf abgestimmte Drucker. Die Label wurden in der Regel im WSS aufbereitet, da die Drucker nicht die entsprechende Rechenleistung hatten/haben und die Label sich von Versandpartner zu Versandpartner unterscheiden.


    Sich in den Datenstream zwischen WWS und Drucker einzuklinken, dürfte

    1. nicht gewollt (Stichwort Duplikate, Datenschutz etc.)

    2. schwierig sein, da die Daten unbedingt ihre Formatierung behalten müssen, sonst fliegt das Label "auseinander", was wiederum Problem mit den Versandpartnern gibt:

    Der RPi müsste den eigentlichen Drucker emulieren, damit die Label "in Form" bleiben". Jetzt versuch mal, die Daten z.B. für einen Zebra-Drucker, Toshiba TEC (Thermotransfer) oder beliebigen Laserdrucker zu bekommen, um den entsprechenden Emulator zu programmieren.


    Bei Kamera-Überwachung kommen auch noch Überlegungen zum Datenschutz etc. dazu.
    Am einfachsten dürfte ein Taster sein, der die zu druckenden Label freigibt. Das müsste die Software ermöglichen.

  • Dieser Drucker hängt, wenn ich das richtig verstehe, an der parallelen Schnittstelle (LPT1 ?) eines PCs unter Windows?


    Dann sollte es eigentlich möglich sein, die Daten statt an den Drucker einfach in eine Datei zu schreiben. Diese könnte mit einem Copy-Befehl an den LPT1-Port gesendet werden.


    Das könnte auch der PC selbst machen - ein passendes Programm würde das hinkriegen und könnte mit dem Pi, der das Kamerasystem steuert, die Druckfreigabe abstimmen. Die Druckdaten müssen dazu nicht über den Pi laufen - aber auch das ist wahrscheinlich kein großes Problem.

    Die Frage ist für mich eher, woher der Pi weiß, was denn die Kamera sehen muss, um eine Freigabe zu erteilen. Müsste der Pi dazu nicht den Inhalt des Etiketts kennen?

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Gnom Der Drucker hängt an der seriellen Schnittstelle, ist im Zweifelsfall vermutlich ein Thermotransferdrucker. Das ist bei WWS häufig der Fall.

  • Dieser Drucker hängt, wenn ich das richtig verstehe, an der parallelen Schnittstelle (LPT1 ?) eines PCs unter Windows?

    Momentan ist der PC mittels serieller (nicht paralleler) Schnittstelle (RS232) mit dem Drucker verbunden.

    Das könnte auch der PC selbst machen - ein passendes Programm würde das hinkriegen und könnte mit dem Pi, der das Kamerasystem steuert, die Druckfreigabe abstimmen. Die Druckdaten müssen dazu nicht über den Pi laufen - aber auch das ist wahrscheinlich kein großes Problem.

    Die Frage ist für mich eher, woher der Pi weiß, was denn die Kamera sehen muss, um eine Freigabe zu erteilen. Müsste der Pi dazu nicht den Inhalt des Etiketts kennen?

    Der RasPi steuert das Kamerasystem nicht. Vielleicht noch einmal zur Verdeutlichung:

    - PC mit Labelsoftware ist mit einem Zebra-Drucker verbunden

    - Nun soll eine Kamera zur Anwesenheitsprüfung installiert werden (Auswertung geschieht in der Kamera direkt), welche ein digitales Ausgangssignal weiterleiten kann

    - RasPi soll nun ZWISCHEN PC und Drucker gesteckt werden (PC -> RasPi -> Drucker) und die Daten aufnehmen und erst dann weiterleiten, wenn bei der Kamera-Analye alles in Ordnung war.

  • Ja, dann mach das doch so...

    Zu dem Thema "Schreiben in eine Datei" - leider habe ich keinen Zugriff auf die Software, welche die Daten zum Drucken erhält. Ergo kann ich sie ja auch nicht in eine Datei schreiben, weil ich ja sonst den Code anpassen müsste? Oder wie meintest du das? :)


    Angenommen es gibt die Möglichkeit die Daten in einer Datei zu speichern. Dann wäre es wohl über die serielle Schnittstelle möglich, die Datei an den RasPi zu schicken, auf das Kamera-Signal zu warten und anschließend von dort an den Drucker weiterzuleiten?

  • Das unterstellt, dass die serielle Kommunikation nur in eine Richtung geht. Und nicht einem auf Frage und Antwort basierenden Protokoll unterliegt. Was sehr unwahrscheinlich ist. Damit muss dann also alle möglichen Formen von Kommunikation nachgebildet werden, und dabei teilweise ein komplett paralleles System geschaffen werden. Denn wenn der Drucker zb ein leeres Magazin meldet, dann hat die Software da ja schon lange mit abgeschlossen. Die Meldung muss also parallel dargestellt und aufgelöst werden.


    Ich halte das alles für überambitioniert. Ich würde mit dem Hersteller Kontakt aufnehmen und das Problem schildern. Dann hat der da ggf was in petto.

  • Eigentlich ganz einfach😬

    • Die Kamera liefert ein digitales Signal wenn irgendwer/ irgendwas anwesend ist.
    • Du hast eine RS232 im Einsatz
    • Der Drucker hat ebenfalls eine RS232 Schnittstelle

    Das Kamera digital Signal könnte via CTS den Drucker steuern.

    D.h. digitales Signal = anwesend -> enable Druck

    wenn digitales Signal = abwesend -> Drucker nimmt keine Daten an.


    https://www.elektronik-kompendium.de/sites/com/0310301.htm




    Man muss im Prinzip nur den unteren Teil mit CTS realisieren.

    Und man sollte eine Drucker Queue haben😀


    Wenn die Kommunikation bidirektional ist muss noch der Rest der Schnittstelle genutzt werden.

    Optimismus ist nur ein Mangel an Informationen🤓

  • Die Software wird doch wohl einen Druckertreiber verwenden, oder? Da kann man normalerweise einstellen, wo die Daten hin fließen. LPT1 COM1, File...
    Wenn nicht - ja, dann tu doch, was du die ganze Zeit sagst. Lass den Pi die Daten an der seriellen Schnittstelle einlesen und an einer zweiten Seriellen Schnittstelle wieder ausgeben. Und eigentlich reicht dafür auch ein ESP32.


    Was ist denn nun eigentlich deine Frage?

    Probier es doch einfach mal aus. Wenn es dein Treiber ermöglicht, schreib eine Datei und schau sie dir an - bei meinem Drucker beginnt die Datei mit "blabla job start" und endet mit "blabla job end". Schließ einen Pi an und versuche die Daten zu lesen.

    Eigentlich dürfte da kein kompliziertes Protokoll dahinter stecken.
    Falls doch, kannst du immer noch versuchen, die Druckdatei (sofern du eine erstellen kannst) mittels Pi an den Com-Port zu senden. Aber wie gesagt - wozu eigentlich ein Pi? Das kann doch auch der PC selbst machen. Du musst ihm nur eine Möglichkeit geben, diesen Kamerastatus einzulesen.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

  • Man muss im Prinzip nur den unteren Teil mit CTS realisieren.

    Und man sollte eine Drucker Queue haben😀

    Heißt im groben, dass ich mir einfach einen Stecker vornehmen könnte und den CTS-Pin und Kamerasignal mittels "UND-Relais" verbinden könnte? Dann werden die Daten ja nur an das Peripheriegerät weitergeleitet, sobald die Kamera und der Drucker ihr OK gibt, oder?

  • Atrox Was alle bisher vergessen haben: Willkommen hier im Forum ;););)

    Ob du dazu eine Kamera brauchst oder ein Taster reicht, sei dahingestellt. Wenn Kamera, wie stellst du sicher, dass nicht nur jemand gerade vorbeigegangen ist und Kamera das als "Anwesend" erkennt?

    Meine dringene Empfehlung: Du solltest dich mit Hersteller des Systems in Verbindung setzen, da eigentlich alle Systeme, die ich kenne, "Closed Jobs" machen und eng aufeinander abgestimmte Komponenten haben.

  • Das sowohl Software als auch Drucker auf ein von außen manipuliertes Kontrollfluss-Signal reagieren halte ich für ausgeschlossen. Bestenfalls gibt’s einen Timeout.


    Man kann nicht einseitig ein Protokoll umdefinieren, und dann erwarten, dass die gegenstelle das brav schluckt.

  • Ich beziehe mich ja auch auf hardware handshaking. Da kann man sehr wohl von aussen Einfluß nehmen. Wenn die Schnittstelle hardware mäßig tatsächlich so ausgeprägt ist und nicht nur aus RX,TX und GND besteht.

    Optimismus ist nur ein Mangel an Informationen🤓

  • Ich habe schon verstanden, worauf du dich beziehst. Die Software hat trotzdem eine Erwartungshaltung, die du dadurch verletzt. Denn die bekommt einfach von System einen timeout hochgemeldet, und dann passiert wer weiß was.


    Es geht nicht darum, das es irgendwie geht. Das ist klar. Das man einfach ein undokumentiertes Verhalten ausnutzen kann, ist eben unwahrscheinlich.

  • Schalte den Zebra einfach per SNMP auf "Pause"

    Aus der MIB :


    Code
    zbrControlPause OBJECT-TYPE
    SYNTAX INTEGER {
    no(1),
    yes(2)
    }
    ACCESS read-write
    STATUS optional
    DESCRIPTION
    "A value of 2 will pause the printer."
    ::= { zbrControl 1 }


    Nachteil hier ist jedoch wenn du den wieder frei gibst wird der ganze Puffer gedruckt.

    Offizieller Schmier und Schmutzfink des Forum.
    Warum einfach wenn's auch schwer geht ?


    Kein Support per PN !
    Fragen bitte hier im Forum stellen. So hat jeder etwas davon.

  • Du hast uns immer noch nicht gesagt, ob der Drucker einen Treiber verwendet. Normalerweise druckt heute keine Software mehr direkt an COM1. Wenn dein System also nicht gerade ein 30 Jahre altes DOS-Programm ist, müsste ein Zebra-Druckertreiber unter Windows installiert sein. Den kannst du auch so einstellen, dass er in eine Datei druckt.

    Der Pi oder auch ein Programm auf dem PC könnte dann die erstellte Datei finden und nach Freigabe einfach an COM1 senden. Eigentlich sollte das kein Problem sein.

    Andere Möglichkeit: Du gibst den Drucker im Netz frei und schickst die Datei an die Druckerfreigabe. Das müsste auch gehen.
    Vielleicht reicht es bereits, den COM-Port in eine Datei umzuleiten. Vielleicht reicht schon

    Code
    type com1: >> data.log


    Du betreibst eine ziemlich anstrengende Art von Geheimniskrämerei. Bisher hast du noch nicht mal gesagt, welches Betriebssystem auf deinem PC läuft. Nochmal: Windows mit einem Zebra-Druckertreiber, wie man es bei jedem Wald- und Wiesensystem erwarten würde, bietet dir mit einer Handvoll Mausklicks die Möglichkeit, deine Druckdaten in eine Datei zu schreiben. Aber du stehst wohl drauf, dir das Leben schwer zu machen.

    Oh, man kann hier unliebsame Nutzer blockieren. Wie praktisch!

    Edited once, last by Gnom ().