Suche Anregungen für Programmstruktur

  • Hallo,


    ich mach gerade ein grobes Konzept für eine Art Arbeitserfassungssystem an Produktionsmaschinen. Im wesentlichen geht es darum, zum einen einige Maschinendaten zu erfassen (Produktionsmengen, Zustand, Geschwindigkeiten - also größtenteils einfache Zähler mit Lichtschranken oder Erfassung von Zuständen wie Antrieb an/aus oder Tür offen/geschlossen) und zum anderen die Tätigkeitserfassung (per Eingabe am Display) zu machen, also wer macht wann welche Tätigkeit an welcher Maschine für welchen Auftrag. Das Ganze wird allerdings schon relativ komplex.

    Es werden mindestens 10 Erfassungsgeräte. Als Hardware möchte ich auf Mikrocontroller setzen, weil robuster und schneller gestartet als ein Pi. Da ich auch Netzwerk brauche kommt ein Pico weniger in Betracht - ich denke eher an ESP32 (WLAN oder Ethernet). Displays (7-10" Touch) würde ich von Nextion nehmen, um nicht die ganze Grafikarbeit vom µC machen lassen zu müssen. Die Daten sollen auf einer Serverdatenbank landen. Für die Übermittlung könnte man MQTT nehmen. Da die Geräte auch untereinander sozusagen synchronisiert werden müssen, ist im Hintergrund entweder eine schnelle Datenbank nötig, wo jeders Gerät jeweils den aktuellen Status der andern abrufen kann oder eine zentrale Instanz, die die Informationen rumschickt. Lezteres ginge sicher auch mit MQTT. Bei der Programmiersprache würde ich wohl auf C zurückgreifen. Mit Python hab ich weniger Erfahrung und C ist wohl auch schneller.


    Ich hab alternativ auch überlegt, ob man das ganze stärker zentralisiert macht. Mit einem Pi im Kiosk-Mode, so dass die gesamte Logik auf einem Server läuft. Möglich wäre ein webbasiertes System oder eine Art Terminallösung. Auch ein Client-Server-System wäre denkbar. Webbasiert hätte den Vorteil, dass man auch noch ganz andere Sachen machen kann - wobei die zugänglichen Server den Umfang beschränken. Allerdings erscheint mir die Programmentwicklung auf Webbasis wesentlich schwieriger als ein lokales Programm auf einem µC. Auch die Integration von Sensoren für die Maschinen in das Programm erscheint mir wesentlich schwieriger. Außerdem braucht man dann entsprechende Hardware - Pi, Bildschirm, Maus/Tastatur. Ein echtes C/S-System ist auch nicht einfacher. Ein Pi als RDP-Client und die Software rein serverbasiert wäre auch denkbar. Zumal 10" Touchdisplays auch erschwinglich sind. Aber wie integriert man dann die Sensoren?


    Wer hat ein paar Anregungen, wie man sowas am besten strukturieren kann, welche Tools, Sprachen oder anderes so ein Projekt vereinfachen oder bessere Möglichkeiten bieten können?

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

  • Hallo Gnom,


    mir sind das zu wenige Details.


    Üblicherweise werden "Aufträge" generiert, aus denen hervorgeht, für welchen Auftrag welche Maschinen in welcher Reihenfolge zu verwenden ist. Entweder steht sogar schon der Mitarbeiter im Arbeitsplan - oder der Mitarbeiter wird durch Annahme des Auftrages zum Zuständigen.


    Normalerweise hat der Auftrag einen Barcode / QR-Code etc. Der Mitarbeiter kann sich auch entsprechend ausweisen und einem Prozess zuordnen lassen.


    Das kann man alles erfassen.


    Skeptisch werde ich bei solchen Sachen, "Zustände zu erfassen", "Tür offen/geschlossen". Hieraus lässt sich die Geschwindigkeit ermitteln, wie schnell ein Mitarbeiter arbeitet. Spätestens hier brauchst Du die Zustimmung des Betriebsrates. Ohne Grund werden die ein solches Unterfangen nicht unterstützen.



    Wenn Du ein sog. Storyboard anfertigst, wirst Du von selbst auf die erforderliche Hardware und IT-Infrastruktur kommen, die beim jetzigen Stand der Informationen nur grob angedeutet werden können.


    Ohne aussagekräftiges Lastenheft, in dem verschiedene Abläufe durchgespielt werden, wirst Du aber nicht weiterkommen.


    Die Programmiersprache ist aber das kleinste Rädchen im Zusammenspiel. An der "richtigen" Programmiersprache wird das Projekt jedenfalls nicht scheitern.



    Beste Grüße


    Andreas

    Ich bin wirklich nicht darauf aus, Microsoft zu zerstören. Das wird nur ein völlig unbeabsichtigter Nebeneffekt sein.
    Linus Torvalds - "Vater" von Linux

    • Icon-Tutorials (IDE: Geany) - GPIO-Library - µController-Programmierung in Icon! - ser. Devices - kein Support per PM / Konversation

    Linux is like a wigwam, no windows, no gates, but with an apache inside dancing samba, very hungry eating a yacc, a gnu and a bison.

  • Also als Rückrad eigent sich MQTT. Vielleicht benötigst DU da nichtmal eine Datenbank. Die Aktuellen Zustaende können auf dem MQTT-Broker vorgehalten werden. Programmiersprache C, ja ist ne gute Idee.


    Als Anregung: mein Tutorial: [Tutorial] Daten zwischen mehreren Raspis live austauschen und in einem Cockpit anzeigen


    Das dort referenzierte Projekt MQTT-Hyperdash verwendet C. Es hat auch einen Rahmen mit Regelmaschinen und einige interessante Dokumente, die ein Konzept beschreiben, wie man meherere Maschinen miteinander interagieren lassen kann.

    Hier der Direkt-Link: click.


    Entspricht das Deinem Geschmack?

    Edited once, last by wend ().

  • Muss ich mir mal in Ruhe anschauen.

    An einer Datenbak werde ich nicht vorbei kommen. Ich rechne da schon mit ein paar Hundert Einträgen pro Tag. Und die müssen ja dann auch mal ausgewertet werden.

    MQTT ist als Transportmechanismus und für einige einfache Regelaufgaben sicher interessant.


    Das Hauptproblem ist, dass das Ganze relativ flexibel sein soll. Die einzelnen Geräte sollen konfiguriert werden. Je nachdem, ab welcher Maschine ein Gerät steht, muss es unterschiedliche Arbeitsgänge und Maschinendaten verarbeiten. Das alles muss in ein übergeordnetes Schema.

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

  • Na, vor allem, wann wurde welcher Auftrag gefertigt, wie lange hat es gedauert - das ist doch der Hauptgrund der Anwendung.Siehe #1.

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