TwinCat Beckhoff-Soft-SPS 2. Teil

drfunfrock

Level-1
Beiträge
934
Reaktionspunkte
72
Zuviel Werbung?
-> Hier kostenlos registrieren
Auf Anregung von Zottel schreibe ich den 2.Teil als extra Artikel.

Ok, die Anlage war fertig und das Loggingsystem stand. Realisiert habe ich es über eine Fifo in der SPS, die über ein Array nachgebildet wurd. ST ist ja im Prinzip nichts weiter als ein Pascal-Dialekt und so findet sich jeder, der einmal auf der Uni oder in der Ausbildung Turbo-Pascal anwenden musste recht schnell zurecht. Andere Programiersprachen wie AWL oder Diagramme möchte ich gar nicht mehr verwenden, wenn es nicht anders geht, weil man in ST alles recht elegant und - für mich der wichtigste Punkt - übersichtlich programmieren kann. Da TwinCAT ST in der Normalversion schon integriert hat, umgeht man auch extra Lizenzzahlungen wie bei Siemens. Zudem kann man ST auch per Copy und Paste in jedem beliebigen Editor bearbeiten. Somit dürfte der Code recht portabel sein.

Ich liebe es, aussagekräftige Variablennamen zu finden und so kommen schon mal 20 Zeichen lange Variablen- und Funktionsnamen dabei heraus, die dann allerdings auch dem Leser die Funktion mit dem Namen mitteilen. Um eine noch bessere Lesbarkeit zu gewährleisten, habe ich versucht meine Automaten mit ähnlichen Kodestrukturen zu versehen, so das schnell die Aufgabe jeder Variablen und jedes Blockes schnell zu nachzuvollziehen ist.

Jedenfalls ist so eine Funktion um eine Fifo nachzubilden in ST eine Sache von 10 Zeilen. Ich benutze dieselbe Fifo-Funktion auch für die Verwaltung der Wagen. Nun kann man darangehen und die FIFO über das ADS-Protokoll (über TCP/IP) auszulesen und zwar immer dann wenn die beiden Pointer (Anfang und Ende) ungleich sind. Zum Schluss muss nur noch der Ende-Pointer auf den Anfangspointer gesetzt werden und schon ist die FIFO wieder leer.

Eine .NET-Basic-Anwendung liesst die FIFO mit den Logdaten aus und schreibt diese in eine Datei mit exklusiven Zugriffsrecht.
Das Problem dabei ist, dass ADS diverse Zustände kennt:

1) Keine Verbindung
2) Verbindung aufgenommen
3) Richtiges Programm in der SPS geladen
4) Jede Variable muss eine Verbindung zur SPS bekommen
5) RUN-State der SPS
6) Lesezustand

Geht in Zustand 2-6 etwas schief muss man alles rückwärts abwickeln oder es bleiben Ressourcen zurück, die entweder ein Reboot der SPS oder des Client-PC erfordern. Das äussert sich dann so, dass die CPU-Belastung der SPS von 3% auf über 40% ansteigt. Deswegen wird auf dem Client-PC auch immer noch die CPU-Belastung der SPS dargestellt. Mit den neueren Versionen von TwinCAT wurde Reboot nicht mehr notwendig. Ich habe mit rudimentäre .Net Klassen entwickelt, die einem das Leben etwas leichter machen. Dumm nur dass man die Garbage-Collection etwas aushebeln muss, wass mir nur teilweise gelang. Eigentlich wäre das ein gutes Open-Source-Projekt hier eine Klassenbibliothek für ADS zu machen. Ich bin mir allerdings nicht sicher, ob hier nicht Python besser wäre, da man auch die Bildschirmanwendungen dann mit QT machen könnte.

Die Logdaten werden über einen Linux-PC der sich mit einem Samba-Client das Windows-Verzeichnis auf dem Client-PC mounted in eine PostgreSQL Datenbank eingelesen. Postgres habe ich gewählt, weil es schon seit langem selbstdefinierte Funktionen ermöglicht und selbst vor komplexen Datenbankstrukturen nicht kapitulieren muss. MySQL ist auch nicht schlecht, liegt aber technisch zurück. PostgreSQL hatte nur bis vor kurzem das Problem, dass die Windowsversion ein Hack war und somit die Verbreitung auf Unixes beschränkt war. Das ist seit etwa einem halben Jahr anders.

Um die Daten in die DB zu schreiben, benutze ich Python, da diese Sprache noch in Zope verwendet wird. Dazu komme ich später. Als erstes wird beim Schreiben in die DB ein korrigiertes Datum mitgeschrieben, weil die 3.Schicht von 2200 bis 0700 dauert und damit auf 2 verschiedenen Tagen liegt. Ich schiebe einfach alle Schichten um 7 Stunden vor, so das SQL-Abfragen geradezu trivial werden. Da die 3. Schicht logisch immer zum Tag an dem sie anfing gehört, ist das auch kein Problem. Dieses zusätzliche Feld wird über eine getriggerte Funktion der DB gefüllt, dass heisst beim Schreiben in die DB wird dieses Feld von der DB automatisch berechnet. Ähnliches geschieht mit der Berechnung des Feldes für die Schicht, um spätere Abfragen einfacher zu gestalten. PostgreSQL macht es dem Programmierer mit der Programmierung solcher Funktionen recht einfach. Die Doku auf postgresql.org ist einfach und übersichtlich.

Als nächstes waren noch die Reporte zu realisieren. Anfangs benutzte ich einen Java-Reportgenerator, der aber den Nachteil hatte, dass man sich das JDK installieren musste und umständlich zu bedienen war. Daher schaute ich nach etwas aus, was einfacher wäre. Am besten wäre eine Darstellung auf einem Webbrowser ohne zusätzliche Software. Daher brauchte ich ein Content-Management-System auf dem Linux-PC, dass eine einfache und strukturierte Progrmmierung erlaubte. Ich habe mich recht schnell für Zope 2.80 (www.zope.org) entschieden, weil mir die meisten PHP-Projekte mit Strukturproblemen zu kämpfen hatten und Zope in Python programmiert wird, einer Sprache die sehr strukturiert ist. Als nächstes hatte ich nur noch die Linux-Distribution zu wählen. Debian war eigentlich erste Wahl, wenn ich nicht so viele veraltete Packete gehabt hätte. Gerade das Zope-Packet war nicht besonders aktuell und es hatte sich bzgl. der Stabilität von Zope danach viel getan. Zudem war die Konfiguration aus meiner Sicht nicht sehr durchdacht. Daher wählte ich Gentoo, welches zwar am Anfang etwas Arbeit verursacht, aber man bekommt ein stabiles System und man kann auf das Einspielen von Distri-fremden Packeten verzichten. Der LinuxPC hat weder Tastatur noch Schirm und wird vollständig über SSH gesteuert und bedient.

Es gab nur ein Problem mit Zope, dass ich bis Heute nicht gelöst habe. Zope kann nur ein Subset von HTTP1.1 so das der Internet Explorer auf HTTP1.0 umschaltet. Damit kann keine Session länger als 60s dauern und manche Reporte dauern aber bis zu 120s. Das ist der Grund, warum wir dann den Firefox benutzen müssen. Ich hoffe irgendwann einen Weg zu finden, dass Problem zu umgehen. Entweder in einem Jahr, wenn Zope3.2 laufen sollte oder mit zwischengespeicherten Reporten.

Mein Ziel ist noch die C++-Bibliothek libADS von Zottel zu einem Python-Modul umzubauen, um auch den Windows-PC von der Logging-Aufgabe zu befreien und somit eine kritische Komponente weniger zu haben, da wir notfalls auch ohne Visualisierungs-PC auskommen können. Die Bibliothek von Zottel kann man sich aus dem Forum herunterladen. Genau weiss ich aber noch nicht, ob ich die Zeit dazu finde.

Die Montrac-Anlage ist unglaublich flexibel, aber das Prinzip ist verbesserungsbedürftig. Wenn man eine Steuerung nach Menge der Wagen und nach Prozessablauf haben möchte, ist man darauf angewiesen, in jeder Station zu wissen, welche und wieviele Wagen in ihr sind. Sensor- oder Wagenfehler (Wagen hält zu früh oder spät) führen zu einem Zustand, der einen Stop der Anlage nach sich zieht, um diese in einen kontrollierten Zustand zu überführen. Als unangenehme Fehlerquelle haben sich die Wagen herausgestellt, die nach einer gewissen Betriebszeit ab- und zu nicht mehr exakt anhalten und dieses ist leider nicht vorhersagbar. Es bräuchte redundante Sensoren und eine Fehlererkennung in der Wagenelektronik und den Stationen.
 
Mahlzeit,

sorry, aber ich denke Zottel hat gemeint, im bestehenden Thread einen neuen Beitrag zu schreiben, statt einen bestehenden zu editieren. Jetzt hat man ja auch keinen Zusammnehang/Überblick.

Vielleicht im alten Thread nochmals posten und diesen löschen lassen.

Viele Grüße

Gerhard Bäurle
 
Zurück
Oben