SPS Ersatz mit LabVIEW in einer Kompostieranlage

 

Die Aufgabe war klar gestellt: Eine alte SPS, die einen grossen Schienenkran steuert, mit minimalem Software-Erstellungsaufwand ersetzen. Der Kran muss über Nacht ohne Bedien- und Überwachungspersonal arbeiten, so dass die Zuverlässigkeit äusserst wichtig ist. Das System muss für maximale Bedienerfreundlichkeit und Anpassbarkeit ausgelegt sein.

Einführung

Das Ziel des Projekts war einen grossen Schienenkran zu automatisieren, der für die Kompostierung von Champignonsubstrat dient. Der Kran hat eine Nettotragkraft von 3 Tonnen und steht in einer Halle über einer betonierten Grube mit einer Grundfläche von 80 x 12 m und einer Tiefe von 5 m. Der Kran hat vier Bewegungsachsen (horizontal längs und quer, vertikal hoch/runter und öffnen/schliessen der Gabel).

Die Rohmaterialien werden an einem Ende der Halle angeliefert, gemischt und in Haufen geschichtet entlang der Querrichtung der Halle. Der Kran schichtet dann diese Haufen automatisch über Nacht um. Er entfernt einen Komposthaufen Stück für Stück und baut einen neuen Haufen anschliessend zum alten wieder auf. Dieses Umschichten der Haufen ist notwendig um ein homogenes Substrat herzustellen und den Kompost gleichmässig zu bewässern und um den Prozess immer aerob zu halten. So bewegt sich ein Komposthaufen Nacht für Nacht vorwärts entlang der Halle, und nach einer Woche ist er genügend fermentiert um in die nächste Phase zu kommen und wird am anderen Ende der Halle entnommen.

 

Kompostkran in Halle

Komposthalle mit Schienenkran

Im Rahmen des Projekts, musste eine bestehende, aber überalterte Siemens S5 SPS mit einem moderneren System ersetzt werden. Die vorgängige Evaluation zeigte, dass keine Softwarekompatibilität zwischen diesem SPS-Typ und den aktuellen Produkten des gleichen Herstellers besteht. Dies bedeutete, dass die Software in jedem Fall neu geschrieben werden musste, und so entschlossen wir uns, eine tiefergehende Evaluation der Systeme auf dem Markt durchzuführen. Der Wechsel auf ein neues System würde uns auch erlauben, mehr Funktionalität zu implementieren, welche den automatischen Betrieb des Krans zuverlässiger machen würde.

Wir mussten feststellen, dass im SPS-Bereich für viele Jahre erstaunlich wenig Entwicklung stattgefunden hat und dass die relativ simple Architektur der SPS auf dem Markt die Erstellung einer grösseren Applikation für die heutigen komplexen Anforderung sehr schwierig und zeitaufwendig macht und der entstehende Code schwierig zu verstehen und zu warten ist.

 

Implementierung

Im Lichte der Nachteile der traditionellen SPS entschlossen wir uns die ganze Applikation mit LabVIEW zu schreiben, da eine solche Lösung effektiv die Schwächen der traditionellen SPS-Systeme vermeidet.

Die Software ist in mehrere unterschiedliche Teile gegliedert; der erste ist die grundlegende Bewegungskontrolle der vier Achsen (z. B. fahre zu einer bestimmten Position, schliesse die Gabel etc.) plus die Kontrolle der Hilfssysteme. Dieser Teil ist immer aktiv, im Automatik- sowie im Handbetrieb. Der Kran kann vom PC, vom Steuerpult im Kontrollraum sowie von den Steuerknüppel-Kontrollen neben dem Kran gesteuert werden.

Zweitens sind komplett automatisierte Prozeduren implementiert so dass der Kran in der Lage ist, die Misch- und Umschichtoperationen über Nacht selbstständig ohne Übwachung durch eine Bedienperson auszuführen (Abtragen der Komposthaufen und anschliessend Neuaufbau).

Der dritte Teil der Software sind die automatischen Fehlerkorrekturfunktionen. In unserem Fall sind diese besonders wichtig, da die Kompostierhalle eine schwierige Umgebung ist, in welcher abnormale Bedingungen auftreten können. Zum Beispiel kann der Kran stecken bleiben oder die Räder können auf den Schienen rutschen, die Gabel kann nicht schliessen weil sie zu voll ist, oder der Kran kann die Ladung nicht hochheben weil sie zu schwer ist und so weiter. Die Software des Systems muss so konstruiert sein, dass sie mit solchen Bedingungen umgehen und sie automatisch lösen kann (z.B. den steckengebliebenen Kran ein paar Mal vor- und rückwärts bewegen; die Gabel ein bisschen öffnen und die Überlast abschütteln etc.)

Der vierte Teil sind alle Visualisierungsfunktionen, welche einen integralen Teil der Applikation bilden. Visualisierungen, Animationen und graphische Benutzeroberflächen können mit dem LabVIEW System ganz besonders einfach erstellt werden. In dieser Hinsicht schlägt das System auch Entwicklungsumgebungen wie Visual C++ und ähnliche.

Bildschirm der Krankontrolle

Bildschirmansicht der Kransteuerung. Die Bildschirmsteuerung ist in unserem Fall ähnlich dem Layout des Steuerpultes, aber
wesentlich weitergehende Visualisierungen können ohne Probleme implementiert werden.

 

 

LabView Code Kransteuerung

Top-Level LabVIEW-Code. Man erkennt, dass das System in eine Reihe von unabhängigen und parallel ausgeführten Tasks unterteilt ist –
Insbesondere sind die I/O Funktionen, die Steuerungsfunktion und alle Visualisierungen separiert.
Durch die Modularität von LabVIEW wird eine übersichtliche Programmstruktur erreicht.

 

Während der erste Teil (die elementaren Steuerungsfunktionen) mit einer SPS implementiert werden könnte, wäre es sehr schwierig, die anderen Aufgaben mit einer SPS zu lösen. Viele der heutigen Automatisierungsaufgaben sind nicht beschränkt auf simple Steuerungsaufgaben; statt dessen müssen komplexe Prozesse vollautomatisch ablaufen. Von modernen Systemen dieser Art wird auch erwartet, dass sie das Verhalten eines Bedieners imitieren können und „intelligent“ reagieren können, so dass die Zahl der nötigen Bedienereingriffe auf das absolute Minimum reduziert wird.

 

Diskussion

In Systemen die auf einer SPS basieren gibt es, nebst anderen Nachteilen,  immer eine künstliche Barriere zwischen dem Steuerungsteil und den höheren Funktionen wie Visualisierung, Statistik etc., welche vollkommen anders programmiert werden und auf anderen Systemen laufen. In LabVIEW können alle Aspekte einer Automatisierungslösung wie Steuerung, Prozessautomatisierung, Fehlerkorrektur, Visualisierung, Datenbank­integration, Statistik und andere, nahtlos integriert werden und alles kann direkt in LabVIEW programmiert werden. Die Programmierer müssen sich nur in ein einziges System einarbeiten und können die gesamte Applikation mit dem gleichen Tool erstellen. Dies ist ein gewaltiger Unterschied zur SPS-Welt in dem mindestens zwei Systeme – die SPS für die Steuerung und ein anderes System für die Visualisierung – nötig sind. Für die Softwareerstellung ist das sehr mühsam da die wenigsten Leute auf allen Systemen routiniert sind; ein SPS-Programmierer tut sich in der Regel schwer mit Visualisierungsapplikationen für Windows oder Unix und umgekehrt.

Wir denken, dass heutzutage der Aspekt der Software-Entwicklung für den Erfolg von Projekten hinreichender Komplexität in jeder Hinsicht zentral ist – die Hardware ist normalerweise ausgereift und unterscheidet sich vielfach auch nicht grundsätzlich.

Das LabVIEW-System läuft einerseits auf Windows Linux und Macintosh Maschinen, andererseits auch auf Real-Time und FPGA Hardware und erlaubt es damit, Plattform-unabhängige Software zu erstellen. Ebenso existieren vorgefertigte Bibliotheken für viele verschiedene Typen von I/O Hardware und Bussysteme, so dass man in der Wahl der Hardware-Komponenten sehr grosse Freiheit geniesst. Da das System aus der Messdaten-Erfassungstechnik kommt, ergibt sich in den Fällen, wo bei einer Automatisierungsaufgabe auch Daten erfasst werden müssen, eine zusätzliche, sehr wichtige Synergie.

Zusammenfassung

Die LabVIEW Plattform ist sehr geeignet, um Automatisierungs­anwendungen zu erstellen. Darauf basierende Systeme sind in der Lage, eine SPS in allen Aspekten zu ersetzen; insbesondere können solche Systeme auch im Zeitverhalten mit Leichtigkeit gleichziehen.

Die herausragenden Stärken des hier diskutierten Systems liegen bei den fundamental verbesserten Möglichkeiten der Softwareentwicklung. Es erlaubt, Systeme reichhaltiger Funktionalität zu erstellen, die mit konventionellen Methoden mit vernünftigem Aufwand kaum mehr realisierbar sind. Im heutigen Marktumfeld werden aber gerade diese zusätzlichen, neuen Aspekte entscheidend sein. Eine grobe Abschätzung für unseren Fall ergibt, dass sich die Software-Entwicklungszeit gegenüber konventionellen Systemen ungefähr halbiert; dies dürfte alle Hardware-Kostenaspekte in den Schatten stellen und dürfte für viele Projekte erfolgsentscheidend sein.