HTML5 Icon 10 Jahre Thailand 

Alternative Steuerung für GEBA-Maschinen

by Nudels


Posted on Samstag September 18, 2021 at 11:01PM in Technik - Steuern und Regeln


Ein neuer Schrittmacher für zwei Athleten in der Fischverarbeitung


Das Schneiden von Fisch ist eine Gourmet-Angelegenheit. Nach dem Räuchern erwarten Konsument und Anrichter ein Maximum an Geschmack und Vielfältigkeit. Weicher, also nicht tiefgefrorener Fisch, bürgt für Aromenvielfalt und lang geschnittener Fisch bürgt für Verarbeitungsvielfalt. Die GEBA-HS241 und die GEBAWSM100 sind 2 richtige Klassiker. Sie haben eine robuste Mechanik und schneiden schnell und präzise. Aus diesem Grunde sind sie auf dem Markt immer noch beliebte Lieferanten für Gourmet-Produkte.




Weichschneidemaschine für ungefrorenen Fisch





Horizontalschneidemaschine für maximale Scheibenlänge



Die beiden Maschinen haben aber eine Achillesverse, die Steuerung stammt aus einem ähnlichen Jahrgang wie die Maschine selbst, und das ist schon ganz schön lange her. Für die SBC-16-Karte und die Simatic-S5 sind kaum noch Ersatzteile zu bekommen. Die Software ist auf in ein EPROM gebrannt. Dieses Bauteil kennen vielleicht noch meine Jahrgänge. So etwas ist nicht mehr lieferbar und hierauf ist die Steuerungssoftware der Maschine hinterlegt. Die Software genügt vielleicht auch nicht mehr den Ansprüchen heutiger Verarbeiter. Damit die Meisterstücke deutscher Maschinenbaukunst nicht auf den Schrottplätzen landen, ist also Handlungsbedarf angesagt und so ist es auch gekommen, dass ich mit meinem neuen Lieblingsspielzeugen nicht mehr all zu viel Zeit zum experimentieren hatte, denn jetzt wird es ernst: Ein Industrieprojekt steht an.




Beispiel für ca. 30 Jahre alte Steuerung



Ein wesentlicher Punkt ist, dass alle Funktionalitäten, inklusive der Bedienpanels erhalten bleiben und genauso funktionieren, wie vorher, denn das sind die Eckpunkte für eine Maschinenabnahme in der Lebensmittelindustrie. Alle Neuerungen und Erweiterungen dürfen diese nich beeinflussen oder einschränken. Sie dürfen nur den Charakter eines erweiterten Bedienkomforts haben, und dieser soll im folgenden Blockschaltbild einen Gesamteindruck liefern:





Neugestaltung der Steuerung von Fischverarbeitungsmaschinen







Zu sehen sind die 4 Bereiche: Produktion, Betrieb, Kommunkation und Entwicklung. Es folgt eine Übersicht:


Produktion


Die alte Steuerung wird durch eine moderne Steuerung ersetzt. Um für die Zukunft gewappnet zu sein, wird die neue Steuerung über ein Kommunikationsmodul mit weiteren Steuereinheiten  kommunizieren und dabei gezielt Aufgaben an Helper-MCUs, oder externe Systeme verteilen. Die Grundfunktionalität der Maschinen bleibt vollständig erhalten. Eine Steuerung hat gegenüber einem Rechner einen entscheidenen Vorteil: Sie arbeitet in Echtzeit und das, wenn es sein muss auch im Parallel-Processing-Mode. Aufgaben, die für diese Betriebsart ohne Betriebssystem zu aufwendig sind, müssen abgegeben werden und die Ergebnisse in Pipelines, für die Steuerung erreichbar, zur Verfügung gestellt werden. Hierbei ist entscheidend, ob Aufgaben verteilbar sind, oder nicht. Die Bedienhoheit obliegt dem Benutzerpanel, was im Einsatzbereich der Lebensmittelverarbeitung durchaus eine Berechtigung hat, da hier in kalter und nasser Umgebung gearbeitet wird. Es hat in der Regel einen IP44-Standard.


Betrieb


Zur Unterstützung der Einrichtung des Kommunikationsmodul wird eine Smartphone-App (Android) geliefert. Zusätzlich lassen sich über diese App alle bekannten und auch neue Funktionen der Service-Programme von Werks-Techniker steuern. Der Techniker kann während der Wartung um die Maschine rum gehen. Abschliessend verfügt diese App über eine Historie des Fehlerspeichers und der Betriebsparameter wie: Betriebsstunden geschnittene Scheiben, ... etc. Betriebsparameter sind abhängig von den Maschinenmodellen.


Entwicklung


Mit der Visualisierung wird das Maschinenverhalten in Echtzeit, oder über Protokolldateien dargestellt. Es ist somit ein wertvolles Werkzeug, um Fehlverhalten zu analysieren, oder Neuentwicklungen zu testen. Die Darstellung lässt sich raumfest drehen, d.H.: die Maschinenbewegungen sind aus allen Perspektiven einsehbar.



Da ich natürlich nicht alle Maschinentypen hier vorhalten kann, um sie mit den Prototypen zu testen, brauche ich einen Innitiator, der mir genau das Verhalten einer Anlage über die Zustände der Ein- und Ausgänge simmuliert.



Die Entwickler-GUI ist ein Werkzeug für einfache Änderungen in der Steuerungssoftware. Es ist möglich ohne C- oder C++-Kenntnisse Abläufe mit grafischen Werkzeugen zu parametrieren und zu ändern.


Kommunikation


Der Kom-Server bietet eine sehr große Palette an Anwendungsmöglichkeiten. Er unterstüzt nicht nur die Helper-MCUs und die Android-App, er kann auch mit autarken SQL-Datenbanken kommunizieren, um Maschinenstatus abzurufen und darauf zu reagieren, Updates auf Konfigurationen durchzuführen, Aufgaben an rechenstarke Partner deligieren und in Pipelines zur Verfügung stellen, ... und vieles mehr. Die Kommunikation unterliegt dabei den aktuellen Sicherheitsstandards. Autarke SQL-Datenbanken, liegen auf geschützten Web-Servern, auf denen nur authorisiertes Personal Zugang hat. Das interaktive Web-Interface dient in erster Linie dazu, sich einen schnellen Überblick über Maschinen-Status zu verschaffen. Einfache Aktionen wie: Rebooten, Starten und Stoppen von Controllern sind möglich, wenn sie keine sicherheitsrelevanten Aufgaben übernehmen, denn das Internet ist ein sehr schwacher Kommunikationspartner. Wie Sie sehen,. ist der Kom-Server eine wichtige und leistungsstarke Einheit in der Gesamtarchitektur.


Natürlich stellt sich die Frage, ob die Entwicklung einer derart aufwendigen Steuerung für 2 Maschinenmodelle, die ca. 30 Jahre alt sind, gerechtfertigt ist. Die Antwort ist: Ja, denn Entwicklungszeit ist teuer. Niemand kann es sich heutzutage leisten, individuell für ein Projekt oder einen Kunden zu entwickeln.   



Der PLC – Programmable Locical Controller


Aus der umfangreichen Systemarchitektur will ich zuerst den PLC-Bereich beschreiben. Für 2 Maschinen gibt es 2 Teil-Projekte: Das Projekt mit dem Namen Patpatson beschreibt den PLC für die GEBA WSM-Baureihe (200, 100, 100D, 75, 45). Das Projekt Paweena beschreibt den PLC für die GEBA HS-Baureihe (240, 241). Die Prokektnamen habe ich von meinen beiden kleinen Nichten entliehen. Die Teilprojekte beziehen sich nur indirekt auf die Model-Typen, es ist viel mehr so, dass die HS-Baureihe einen komplexeren PLC benötigt. Ich fange mit dem einfacheren an.


Das Projekt Patpatson – GEBA WSM-Baureihe


Bevor man anfängt etwas zu entwickeln, ist man gut beraten, sich einen umfassenden und detaillierten Überblick zu verschaffen, was man da eigentlich bauen soll. Im Teil-Projekt Patpatson geht es im Kern um zwei überlagerte Bewegungszyklen. Im Klartext beschrieben: (1)Bringe einen Fisch in eine ideale Schneideposition, danach (2)schneide eine Scheibe ab.


(1) ... ist eine zyklische Rechteck-Bewegung. Der Transporttisch besteht aus einer Anzahl von festen und losen Stäben. Die losen Stäbe sind mit Nadeln versehen, die den Fisch fixieren und mitnehmen können. Die losen Stäbe haben einen horizontalen und vertikalen Freiheitsgrad. Ausgelöst wird die Bewegung durch Druckluftzylinder, die in der Bewegungsrichtung ausgerichtet sind. Gemessen wird in diesem Ablauf an einer Stelle, und das ist der Zustand, wenn die losen Stäbe das hintere Ende der Horizontalbewegung erreicht haben.


(2) ... ist eine geneigte zyklische Vertikalbewegung. Sie bringt ein elektrisch betriebenes Doppelklingen-Messer in die Schneideposition und fährt es anschliessend wieder in die Endlage. Diese Bewegung wird ebenfalls mit einem Druckluftzylinder ausgelöst. Gemessen wird in der Endlage und in der Schneide-Lage.


Das sind die Bewegungen, die natürlich koordiniert werden müsen. Jetzt gibt es noch Randbedingungen: Es gibt einen Sicherheitskreis, der prüft, ob die Haube geschlossen ist, der Not-Aus-Schalter gedrückt wurde, ... usw. Um diesen brauchen wir uns nicht zu kümmern, denn in der Modelabnahme wurde festgelegt, dass der Sicherheitskreis ausserhalb der Steuerung realisiert ist. Wir dürfen diesen Umstand nicht ändern. Es ist für diese Entwicklung lediglich die Erkenntnis notwendig, dass wenn der Sicherheitskreis offen ist, die Speisespannung der Steuerung von 24V unterbrochen wird. Weiter geht es mit Dingen, die wir realisieren müssen. Der Betrieb wird über 2 physikalische Button ein- und wieder ausgeschaltet. Aus – bedeutet: Die Bewegung fährt in eine definierte Endlagen-Position, die wiederum Betriebsbedingung beim Betätigen des Start-Buttons ist. Ist diese nicht erfüllt, darf die Maschine nicht anlaufen.


Die Startposition (Endlagenposition) oder
Startbedingung:



  • Das Messer ist oben und ausgeschaltet.

  • Die losen Stäbe befinden sich unten und hinten.


Wenn diese Bedingungen erfüllt sind, blinkt die Beleuchtung des Start-Buttons. Wenn nicht ist die Beleuchtung aus und der Button inaktiv.


Sind die Startbedingungen erfüllt und der Start-Button wird gedrückt, geht die Beleuchtung auf permanent, das Messer wird eingeschaltet und die programmierte Bewegung beginnt.


Die Maschine hat einen Test-Modus, mit dem man einzelne Abläufe schrittweise durchlaufen kann. In diesen Modus kommt man, wenn die Maschine bei gedrücktem Start-Button eingeschaltet wird. Diesen Ablauf können wir ohne bedenken um eine Smartphon-App erweitern. Er hat keine Sicherheits- oder Betriebsrelevanz und wird nur von Technikern bei Reparatur und Wartungsarbeiten benutzt. Die App ist komfortabler und benötigt nicht den langen Arm zum Bedienpanel, ausserdem kann der Techniker während des Testlaufes um die Maschine herumgehen und den Ablauf aus allen Perspektiven betrachten. Damit ich nicht aus der ursprünglichen Maschinenabnahme rauslaufe, muss der Test- oder Service-Modus auch weiterhin über die Buttons erreichbar sein.


Die Bewegungen


Den Bewegungsablauf brauchen wir im Grunde genommen nicht zu Dimensionieren, denn schliesslich laufen die Maschinen ja schon seit 30 Jahren. Der Vollständigkeit halber machen ich es hier nochmal. Die Frage ist: Wieviele Sensoren und wieviele Akteure benötige ich um diese beiden überlagerten Bewegungen abzubilden? Die Antwort ist: 3 Sensoren und 3 Akteure. Warum ist das so? Überlagerte Bewegungen lassen sich als Gleichungssystem beschreiben. Damit sie zyklisch durchlaufen, muss das Ergebnis der 0-Vektor sein. Mit anderen Worten eineindeutig mit der einzigen Lösung 0. Wir haben 3 Raumvektoren in Koordinatenschreibweise: a0x+b0y+c0z ... anx+bny+cnz. Der Rang der Koeffizienten Matrix muss gleich der Anzahl der Gleichungen sein. Dieses ist in unserem Fall die 3. Der Transporttisch hat 2 Vektoren (vertikal, horizontal) und das Messer hat einen Vektor(geneigt vertikal). Die Akteure sind vorgegeben, als Druckluftzylinder, die auf der Richtung ihres Vektors zur 0 hin, oder von der 0 weg treiben können. Eine Gruppe von Druckluftzylindern gilt als ein Akteur. Das sind dann schon mal die Bekannten. Die Unbekannten sind die Endlagen der Vektoren, wobei sich bei 2 Bewegungen natürlich eine Endlage in der anderen Bewegungen befinden muss. In der nächsten Abbildung ist das Ganze nochmal skizziert.




Akteure und Sensoren




  • 1: Sensor Gatter hinten

  • 2: Sensor Messer oben

  • 3: Sensor Messer unten

  • 1: Akteur Gatter vor zurück

  • 2: Akteur Messer hoch runter

  • 3: Akteur Gatter hoch runter





Die grünen Pfeile haben selbstverständilich einen Freiheitsgrad um 180°. Der Sensor für die Auf- und Ab-Bewegung des Transporttisches liegt wie erwartet in der Bewegung des Messers, und zwar unten. Die ganze Betrachtung ist die Grundlage für die Programmierung des Controllers, denn die Bewegung wird exakt so programmiert, wie es oben beschrieben ist. Es sind genau 2 Schritte die die Bewegung beschreiben und 2 Schritte für die Eingangsbedingungen:


Die Eingangsbedingungen


 Die Maschine wird eingeschaltet: Schritt 0



  • schalte das Start-Button-Licht aus

  • fahre die Akteure in die Startbedingung.


Prüfe die Startbedingung, wenn ok: Schritt 1



  • schalte das Start-Button-Licht auf blinken

  • gebe den Start-Button frei



Wenn Sensor Messer oben zündet und Sensor Gatter hinten zündet: Schritt 2



  • fahre das Gatter hoch

  • fahre das Gatter vor

  • fahre das Messer runter


Wenn Sensor Messer unten zündet: Schritt 3



  • fahre das Messer hoch

  • fahre das Gatter runter

  • fahre das Gatter zurück


Die Randbedingungen



Der Start-Button wird gedrückt:



  • schalte das Messer ein.

  • gehe in den Normalbetrieb. Das ist die Bewegung (s.o.) Schritt 2 und Schritt 3

  • schalte das Start-Button-Licht auf Dauer-Leuchten


Der Stop-Button wird gedrückt:



  • schalte das Start-Button-Licht aus

  • schalte das Messer aus

  • fahre die Maschine in die Startbedingung (s.o. beinhaltet Messer aus) Schritt 0 und Schritt 1




Der Test-Modus aktiviert:



  • fahre die Maschine in die Startbedingung (s.o.) Schritt 0 und Schritt 1

  • deaktiviere den Start-Button für den Normalbetrieb

  • aktiviere den Testbetrieb



Der Test-Modus wird  beendet



  • fahre die Maschine in die Startbedingungen (s.o.) Schritt 0 und Schritt 1



Der gesamte Test- oder Servicebetrieb wird an anderer Stelle beschrieben. Denn hier geht es mit Innovationen los. Das bisher beschriebene konnten die alten PLCs auch schon. Jetzt kommt die Kom-Server MCU ins Spiel. Bevor es damit los geht, beschreibe ich noch das Innitiator-Board, welches mir das Verhalten der Maschine simmuliert und die Produkt Features der einzelnen Modelle.


Das Innitiator-Board


Dieses Board ist ein Slave, es weiß gar nichts über den Bewegungsablauf, es kennt nur die Ein- und Ausgänge und es weiß, dass verschiedene Eingänge verschiedene Antwortzeiten haben, bei denen es nach entsprechender Wartezeit über wohldefinierte Ausgänge wieder eine Rückmeldung absetzen muss. Das ist eigentlich schon alles, was das Innitiator-Board können muss. Eine simple Aufgabe. Damit wir kontrollieren können, ob das Board seine Arbeit gut und richtig macht, schreibt es zu jeder Aktion, die es durchführt Protokollausgaben. Dieses gilt für das Lesen von Eingängen als auch für das Schreiben von Ausgängen.


Das Innitiator Board simmuliert uns das Anlagenverhalten. Die Steuerung weiß nicht, ob am anderen Ende eine echte Maschine, oder eine Simmulation hängt, solange sie die richtigen Rückmeldungen erhält.


Ein Beispiel. In einer Kette von Abfragen finden wir diese für den Hauptzylinder:


if(digitalRead(HAUPTZYLINDER)==HIGH){      

     if(1==zustandsaenderung(HAUPTZYLINDER,true)){    
         strcat(proto,"Ventil_Messerbock=EIN\n" );
      setproto(proto) ;
     }
      digitalWrite(INNI_MESSER_UNTEN,LOW);

     if(1==zustandsaenderung(INNI_MESSER_UNTEN,false)){
         strcat(proto,"Messer_Inni_unten=AUS\n" );
       setproto(proto) ;
     }
      delay(DELAY_MITTEL);
      digitalWrite(INNI_MESSER_OBEN,HIGH);


     if(1==zustandsaenderung(INNI_MESSER_OBEN,true)){
         strcat(proto,"Messer_Inni_oben=EIN\n" );
      setproto(proto) ;
     }
  }



1 Der Eingang HAUPTZYLINDER meldet uns ein TRUE


2 Die Steuerung möchte nicht 1000-mal und mehr die gleiche Antwort erhalten, deshalb prüfen wir einen Meldestatus ab.


3 Die Antwort erfolgt über einen definierten Ausgang und zwar unverzüglich.


4 Es gibt eine weitere Antwort über einen definierten Ausgang mit einer definierten Wartezeit


So, wie für diesen Eingang HAUPTZYLINDER, gibt es klare und wohl definierte Regeln für alle Ein- und Ausgänge, damit die Steuerung keinen Zweifel daran hegt, dass am anderen Ende vieleicht ein Simmulant sitzten könnte. :-)



Das Innitiator-Board ist somit eines der wichtigsten Werkzeuge in der Contoller-Entwicklung, denn es kennt die Antworten, ähnlich wie bei den Junit-Tests in der Java-Entwicklung. Die Antworten sind Tautologien - sie sind immer wahr. Wenn die Steuerung mit den Antworten nicht umgehen kann, macht sie etwas verkehrt, und nicht der Simmulant. Deshalb ist das Innitiator-Board unbedingt als erstes zu entwickeln, bevor am Controller eine einzige Zeile programmiert wird. Voraussetzung ist, dass die Anforderungen der Anlage klar definiert und wohl bekannt sind.



 Als kleine Auflockerung: Der aktuelle Entwicklungsstand. Die Visualisierung ist für diese einfache Bewegung noch als Java-Implementierung möglich gewesen. Zu sehen ist ein Auszug aus dem Controller-Protokoll via RX/TX. Eine Übertragung über Wifi ist ebenfalls Live möglich. Für die HS wird dann wahrscheinlich eine OpenGL-Entwicklung nötig sein.










Der Controller wird zur Zeit vorbereitet auf die Kommunikation, im 24V- und 2.5A-Bereich und nächste Woche zum Life-Test nach Deutschland geschickt.





Das Kommunikationsmodell



Im Video oben ist eine Datenübertragung in ein Windowssystem über ein RXTX-Protokoll realisiert. Hierbei steht der Kom-Server aussen vor. In der Produkterstellung wird es dieses Feature nicht mehr geben, dafür gibt es zwei Gründe: Die meisten Windowsrechner haben, den USB-Clone mal ausgenommen, hierfür keine Schnittstelle mehr. Die technische Umsetzung auf einen 12V-TTL-Pegel ist ein Aufwandsfaktor, der sich nicht rentiert im Vergleich zu gängigen Alternativen. Es ist im Betrieb und in der Fertigung wesentlich einfacher die Wifi-Infrastruktur zu nutzen, die ja ohnehin schon vorhanden ist. Zur Realisierung einer komfortablen Konfiguration, spendiere ich der Steuerung einen Bluetooth-Zugang, der dann über die Smartphone-App erreichbar und einfach bedienbar ist. Der Aufwand liegt im einstelligen €-Bereich. In der Kommunikation zwischen den MCUs untereinander bleibt eine UART-abhängige Kommunikation allerdings unverzichtbar. Die verfügbaren Spezifikationen sind:



  •     SPI

  •     I2C

  •     RXTX


Jede Spezifikation hat Vor- und Nachteile und sollte nach Abwägung eingesetzt werden. Alle benötigen für eine sichere Kommunikation eine Protokoll-Implementierung, die das Regelwerk für den Datenaustausch beschreibt. Hierzu gehören:



  •     Der Handshake

  •     Die Empfängervalidierung

  •     Datenintegritätsprüfung

  •     Das Komunikationsmodell (2-Weg oder 1-Weg)


Die Kommunikation zur gesamtem PLC liegt im Bereich der Peripherie, hat also mit der eigentlichen Aufgabe der Steuerung einer Maschine nicht direkt etwas zu tun. Sie bringt aber im täglichen Betrieb viele Vorteile mit sich, wie z.B.: Status-Abfragen, Notfalleingriffe, Remote-Steuerung, Updates ... und vieles mehr. In der folgenden Abbildung sind die wesentlichen Kommunikations-Zonen dargestellt. Auf die Details in der UART-abhängigen Kommunikation und die Protokoll-Implementierung gehe ich später ein.




Kommunikations-Zonen






Simmulation einer Anlage mit Relais zwischen MCU und Maschine. In der Simmulation werden zwei Arduino UNO SMD und eine ESP8266 eingesetzt




Der Prozess - Service - process



Im Wesentlichen unterscheidet sich der Prozess auf einer MCU nicht von einem Standard--Unix-Service. Letzterer hat natürlich, den Vorteil, dass er sich nicht besonders aufwendig um seine Stack- und Heap- Inhalte kümmern braucht, wenn er unterbrochen wird, denn er hat ja ein Betriebssystem. Beim MCU-Prozess müssen wir uns darum vollständig selber kümmern. Ein Service lebt davon, dass er Informationen austauscht und die Gelegenheit dazu muss man ihm auch bieten. Dieses geschieht in einem sehr kurzen Moment, in dem die Loop unterbrochen wird und der CPU Gelegenheit gegeben wird, sich um dieses Anliegen zum kümmern. Der ganze Vorgang nennt sich Proc-Delay oder Soft-Interrupt. Dahinter hängt eine Informationsinfastruktur. Eine gelungene PLC besteht natürlich aus vielen Prozessen, die das Bedürfnis haben, untereinander zu plaudern, ohne dabei den Vorteil einer Echtzeitbearbeitung zu behindern. Die Abstimmung der Proc-Delays ist kein Hexenwerk, man kann sie sehr genau bestimmen.


Der SQL-Zugriff - oder Datenaustausch mit einem ORB


Der Prozess ist abgeklärt und die Frage stellt sich natürlich für viele, wie kann ich in Echtzeit einen Arduino, oder ESP dazu bewegen, sich Informationen aus einer SQL-Datenbank zu holen. Zum ESP bin ich natürlich noch etwas an Informationen schuldig, denn den Amtel haben wir im letzten Beitrag schon ein wenig kennengelernt - folgt später. Um mit einem ORB zu komunizieren brauchen wir Objekt-Skeletons - Ohje hätte ich das ganze nicht besser in C++ programmiert? Nein ist auf jeden Fall die richtige Antwort. Pure C ist eine Handwerkszeug, das allen Dingen in der Maschinensprache einen wiedererkennbaren Namen gibt. Es ist ein starkes Werkzeug um die Macro-Assembler-Programmierung zu vereinfachen. Die Grundlage, z.B.: ...um Unixsysteme performant zu programmieren. C-Structures werden auch vom ORB als Objekte akzeptiert. Der ORB in diesem Projekt ist so auf den Kern der Sache programmiert, dass er in sehr kurzen Antwortzeiten die erwarteten Informationen liefern kann - Steuerungsgerecht. Der ORB ist natürlich stark abhängig von einer guten Internet-Verbindung und sollte deshalb bevorzugt im Setup und nicht in der Loop verwendet werden. Ein Informationsvorgriff ist in dem Fall eine Abwägung, oder bei teilbaren Aufgaben, einen Parallelprozess anzustossen.


Wie funktioniert das Ganze? Der Fragesteller ist resourcenschwach und erwartet schnelle Antorten, deshalb mogeln wir ein bisschen in der Spezifikation und geben dem ORB schon in der Datenstruktur mit, welches DMS er befragen soll. Unser Mini-ORB läuft auf einem Unix.Server im Internet und die Datenbank findet er idealerweise lokal. Die Antwortzeit liegt bei: Informix, Oracle und MySQL im verschwindent kleinem Milli-Sekunden-Bereich. Möglich wird dieses durch eine persistente Architektur des ORBs. Die Aufgaben des ORBs sind rudimentär und ein Programmieraufwand von höchstens einem Tag.


Warum sollte die Steuerung eine Datenbank befragen? Ich habe beispielsweise eine teuere Mietmaschine irgendwo in der Welt im Einsatz und der Kunde benutzt täglich Verschleiss-abhängige Komponenten, wie: Messer und Pneumatikzylinder, bezahlt aber seine Rechnungen nicht. Man sollte es sich gut überlegen, aber in letzter Instanz würde ich als Eigentümer diese Maschine Remote ausschalten.







Remote - Stillegung einer Maschine


24Volt Ausgänge für den PatPatSon-Controller


Das Teil-Projekt für den kleinen Contoller neigt sich dem Ende. Ich habe ihm, wie versprochen eine Bluetooth-Schnittstelle spendiert und er verfügt mittlerweile über das Handling von 75Watt Ein- und Ausgängen. Diesen Monat werden die Life-Tests in Deutschland gestartet, also in realen Maschinen, die dann auch 24V für Ein- und Ausgänge fordern. Die Performance in den den Labor-Tests sind mehr als zufriedenstellend. Schauen wir einmal auf das Video:









Der Paweena-Controller ist zur Zeit ebenfalls aus der Experimentellen Phase raus und entwickelt sich zum Prototypen. Das Projekt hat insgesamt sehr viel Spass gemacht und einen enormen Zugewinn an Know How für mich verbucht. Alles nach altem Strickmuster: Vorgehensmodell, ist eine Garantie für erfolgreiche Projektabschlüsse. Mehr Details folgen dann irgendwann später. Ich bin offen für Fragen und Interessenten.

Vielen Dank

Nils Wehrmann