Inhalt
Projekte
MPC565
"Kleine Starthilfe" für die Inbetriebnahme des PowerPC phyCORE MPC565 mit GPIO-Expansion-Board und dem Echtzeit-Betriebssystem RTOS/UH.
Download Dokumentation MPC565/GPIO
Die vollständigen Beispiele als Source-Code finden Sie auf der kostenlosen CD "Realtime-Evaluation Kit mit RTOS-UH für MPC 565" der Firma IEP, Hannover
( http: //www.iep.de/Hauptebene/Software/eva.htm ).
_____________________________________________________________
TPU
Die Time Processor Unit (TPU) ist ein Peripheriemodul für Timeranwendungen, das auf Micro-Controllern (z.B. 68332, MPC555, MPC565, MPC5554) integriert ist. Die TPU ist jedoch wesentlich leistungsfähiger als ein Timer, es handelt sich um eine RISC-CPU mit einem für Timeranwendungen optimierten Befehlssatz. Diese Zwei-Prozessor-Struktur auf einem Chip (CPU + TPU) ermöglicht die Verwendung eines Betriebssystems auch in Anwendungen, bei denen selbst die geringe Verwaltungszeit eines Echtzeitbetriebssystems sonst Probleme bereitet.
Genutzt wird im Labor Echtzeitsysteme (LEZ) das Echtzeitbetriebssystem RTOS/UH auf der CPU und parallel dazu die TPU zur schnellen Interaktion mit dem technischen Prozess. Die TPU besitzt einige Funktionen im PROM (z.B. Puls-Weiten-Modulation), die sich konfigurieren und mit Parametern versorgen lassen. Zusätzlich kann die TPU wie ein frei programmierbarer Prozessor betrieben werden.
Zur Konfiguration der vorhandenen Funktionen der TPU müssen diverse Register programmiert und die Reihenfolge von Aktionen eingehalten werden. Weiterhin sind die Parameter den jeweiligen Channels zuzuordnen und im Parameter-Ram abzulegen. Diese Arbeiten auf "Bit-Ebene" müssen dem Hochsprach-Programmierer abgenommen werden, um zu einer schnellen und effizienten Programmierung zu kommen. Im LEZ ist daher eine Library zum einfachen Anschluss der TPU an Hochsprach-Programme entstanden.
Der Anwender kann nicht nur die vorgefertigten Funktionen benutzen, sondern auch selbst Programme für die TPU schreiben. Im Labor Echtzeitsysteme ist dafür ein TPU-Assembler entwickelt worden, der eine Assemblersprache verarbeitet, die dem 68xxx-Befehlssatz angenähert wurde. Die Assemblersprache wurde im LEZ so definiert, dass alle Operationen und Teiloperationen der Microengine genutzt und damit alle Möglichkeiten der TPU ausgeschöpft werden können. Die in der Mikro-Programmierung üblichen Einschränkungen und Besonderheiten sind dabei zu beachten. Die übersetzten Programme werden in ein 2k-Byte großes internes RAM geladen, aus dem die Microengine nach dem Umschalten in den Emulationsmode die Programme bearbeitet. Zur Anbindung an die Hochsprach-Programme der CPU stehen Library-Funktionen zur Verfügung. Mit dieser Entwicklungsumgebung ist es möglich, beliebige anwendungsspezifische Lösungen zu erstellen, wenn die vom Hersteller gelieferten TPU-Funktionen nicht ausreichen.
Als Beispiel wird ein State der Puls-Weiten-Modulation gezeigt:
_____________________________________________________________
RTOS/UH
Das Echtzeitbetriebssystem RTOS-UH (entwickelt am Institut für Regelungstechnik der Uni Hannover) wurde an der Hochschule OWL im Labor Echtzeitsysteme auf die 32Bit-Microcontroller-Familie 683xx portiert. Damit war es möglich, Automatisierungsaufgaben mit diesen Prozessoren unter Betriebssystemkontrolle mit einer Echtzeit-Multitasking-Hochsprache (PEARL, Crest-C) zu lösen. Weiterentwickelt wurde das System durch eine Reihe von Diplomarbeiten. Dabei entstanden z.B. Library-Funktionen zur vereinfachten Prozessankopplung mit Hilfe der vordefinierten Funktionalitäten der Time-Processor-Unit (TPU). Weiter verbessert wurde die Möglichkeit zur Prozessankopplung durch die Programmierung der TPU.
Da Insellösungen für Automatisierungsgeräte nur noch wenig Bedeutung haben, wurden die Microcontroller über einen Feldbus in den Automatisierungsverbund eingebracht. Dazu sind in Diplomarbeiten und in einem Entwicklungsprojekt Systemsoftware und Management-Tools für den CANbus (CANopen) entwickelt worden.
Für aktuelle Projekte wird RTOS/UH auf PowerPC-Prozessoren (z.B. MPC565) verwendet .
_____________________________________________________________
Forschungs- und Entwicklungsprojekt:
Einsatz von intelligenten Netzknoten am CANbus
Projektlaufzeit: Januar 1997 - April 1998
Gefördert durch: Weidmüller-Stiftung
Der Bedarf an dezentralen freiprogrammierbaren Automatisierungssystemen ist in den letzten Jahren stark angesteigen, da nur mit diesem Konzept eine weitere Kostenreduzierung gegenüber zentralen Automatisierungssystemen zu erreichen ist. Besondere Bedeutung für die Auswahl eines bestimmten Automatisierungssystems hat, neben dem Preis und der Verbreitung, die Bedienerfreundlichkeit, denn nur ein schnell erlernbares und einfach zu bedienendes Produkt hat Aussicht sich auf dem starkumkämpften Markt der Automatisierungstechnik zu behaupten.
Ein verteiltes Automatisierungssystem besteht aus mehreren eigenständigen intelligenten Komponenten, die jede für sich betrachtet zum Aufbau eines zentralen Automatisierungssystem geeignet sind. Um solche Komponenten in einem verteilten System einsetzen zu können, muß eine überlagerte Anwenderschicht zur netzwerkweiten Kommunikation, Synchronisation und Steuerung eingeführt werden.
Im Verlauf der Arbeiten am Forschungsprojekt Einsatz von intelligenten Netzknoten am CANbus mit dem Arbeitstitel 'EZ_CAN 2.0' zeichneten sich zwei mögliche Realisierungskonzepte ab.
Die erste Variante setzt sich ein Höchstmaß an Dynamik zum Ziel und basiert auf der dynamischen Identifiervergabe zur Laufzeit die ein Schwerpunkt dieses Projektes ist. Für die Steuerung des Systems wurde ein Kommunikationsdienst mit Anbindung an das Betriebssystem installiert, das die zentrale Steuerung des gesammten Systems erlaubt.
Der zweite Ansatz orientiert sich am Grundkonzept der IEC 1131, bei der die Identifiervergabe in einem Tool auf dem Host-PC während der Projektierungsphase abläuft.
Das Konzept von EZ_CAN
Im Gegensatz zur Version 1.0 basiert der Application Layer "EZ_CAN 2.0" auf dem von der CiA standardisierten CANopen-Spezifikationen und nicht mehr ausschließlich auf CAL .
Grundlage der ON-LINE-Projektierung bei EZ_CAN ist die, von der CiA für das "Extended-Device-Boot-Up" standardisierte, "dynamische Identifiervergabe" durch den DBT-Manager.
Um die dynamische Identifiervergabe auch während des Netzbetriebes zu nutzen ist es notwendig, die Datenhaltung durch den DBT-Manager und durch die DBT-Agenten dynamisch zu gestalten, d.h. der DBT-Manager muß jederzeit über ein Prozessabbild aller im Netzwerk angemeldeten Busobjekte verfügen. Die dazu notwendigen Änderungen und Erweiterungen führten zu einer neuen Gruppe von Diensten und Protokollen, den sogenannten "Special_Application_Services" (SAS). Diese Dienste und Protokolle sind als Erweiterung der CAL/CANopen-Spezificationen ausgeführt, so daß keine Konflikte mit Baugruppen dieser Norm zu erwarten sind.
Zur Speicherverwaltung und Systemsteuerung bedient sich EZ_CAN der Shell-Befehle des Echtzeitbetriebssystemes RTOS/UH.
Als Schnittstellen zum System stehen dem Anwender leicht editierbare ASCII-Textfiles zur Verfügung (um nicht auf intergrierte Tool's angewiesen zu sein) die nach Aktivierung einer Userinterface-Task automatisiert ausgewertet werden.
Eine Sonderrolle besitzt die Userinterface-Task "ez_shell" , mit dessen Hilfe "interaktiv" alle Funktionen des Betriebssystem auf einem entfernten Knoten ausgelöst werden können.
Um die Betriebssystemfunktionen netzweit zu nutzen, wird die CANopen-Funktionalität des "Object-Dictionary" um einen Kommunikationsdienst erweitert. Der Kommunikationsdienst erlaubt die zentrale Konfiguration, Parametrierung, Inbetriebnahme und Steuerung eines CANbus-Systemes über die Terminalfunktion des Buszugangsknotens (Manager-Knoten).
Die Konfigurations- und Parameterdaten werden ebenfalls über pattformunabhängige ASCII-Textfiles, durch Aktivieren einer UserInterface-Task, an EZ_CAN übergeben.
Dieser Schritt erlaubt den plattformunabhängigen Einsatz eines beliebigen Editors.
Die eigentlichen Anwenderprogramme werden extern (auf dem Host-Rechner) zu einem "User-Module" aufbereitet, in dem neben dem Anwenderprogramm selbst, auch die für den Datentransport notwendigen Busobjekte inklusive ihrer Parameter untergebracht sind. Die Informationen zu den Busobjekten liegen dabei nicht als passive Datensätze vor, sondern werden von dem Pre-Compiler in Library-Funktionsaufrufe umgesetzt, die nach ihrer Aktivierung, die notwendigen Protokolle durchführen bzw. auslösen. EZ_CAN verfolgt damit den objektorienten Ansatz des CANbus. Der Einsatz des Pre-Compilers ist optional.
Die Forderungen
Die Anzahl der Busobjekte auf einem freiprogrammierbaren Knoten soll unabhängig vom verwendeten CAN-Controller sein.
Der Zugriff auf Objektdaten soll über Library-Funktionen durchgeführt werden, die fester Bestandteil der Firmware eines Knotens sind.
Die Anmeldung bzw. Abmeldung von CANbus-Objekten soll während der Laufzeit des Netzes durch den Aufruf von Library-Funktionen aus den Anwenderprogrammen herraus möglich sein.
Anwenderprogramme auf entfernten Knoten sollen von einem zentralen Buszugangsknoten aus geladen, gestartet, beendet und entladen werden können.
Unterstützung der CANopen-Funktionalität (Slave).
Der Ansatz
Es ist vorteilhaft, die Netzwerkverwaltung von der Objektverwaltung zu trennen. Diese Trennung erlaubt die automatisierte Inbetriebnahme des CANbus-Netzwerks. Gesteuert wird die Inbetriebnahme durch Kommandosequenzen die der Anwender in einem ASCII-Textfile (NODE_INI) zusammen mit den Netzwerkparametern der Systemsoftware (NODE-Manager) zur Verfügung stellt.
Die Datenhaltung und lokale Objektverwaltung erfolgt in einer internen Tabelle (OBJ_TAB), durch den DBT-Agenten. Dies erlaubt den Einsatz preisgünstiger CAN-Contoller, da nur noch ein Empfangsregister benötigt wird. Bei EZ_CAN 2.0 wird dadurch die Anzahl der möglichen Busobjekte nicht durch die Anzahl der Empfangsregister des CAN-Controller's bestimmt.
Eine weitere Neuerung ist die eindeutige Zuordnung jedes Busobjektes zu einem Anwenderprogramm. Damit ist nicht mehr die Systemsoftware eines Knotens der Besitzer, sondern nur noch der Verwalter dieser Busobjekte.
Die globale Objektverwaltung erfolgt dynamisch zur Laufzeit (ON-LINE) durch den DBT-Manager. Dieser verwaltet alle im Netz verfügbaren Identifier (COB-ID's) in einer internen Tabelle (DATA_BASE).
Der DBT-Manager übernimmt die Zuordnung zwischen einer Programmvariablen (Name) aus einem Anwenderprogramm und einem Busobjekt (COB-ID) für die Kommunikation über den CANbus.
Abgewickelt wird die Zuordnung von Programmvariablen (Namen) zu Busobjekten (COB-ID) über Protokolle zwischen dem DBT-Agent (lokale Objektverwaltung) und dem DBT-Manager (globale Objektverwaltung). Im weiteren Verlauf wird der Vorgang der Zuordnung von Programmvariablen (Namen) zu Busobjekten (COB-ID) auch als Anmeldung bezeichnet.
Basis für die Protokolle ist das aus CAL bekannte "create_user_definition_protocol", das für eine klare Abgrenzung zu CAL in "create_object_definition_protocol" umbenannt und der neu definierten Gruppe der "Special_Application_Services" (SAS) zugeordnet wurde.
Um zur Laufzeit des Netzes ein Anwenderprogramm vollständig aus dem System zu entfernen (z.B.um eine neuere Version zu installieren) müssen zunächst die Busobjekte abgemeldet werden. Dazu stellt EZ_CAN 2.0 das "delete_object_definition_protocol" zur Verfügung.
In der Gruppe der "Special_Application_Services" (SAS) finden sich zusätzlich Protokolle für die netzweite Synchronisation der angeforderten Dienste.
Die CANopen-Funktionalität soll durch Implementierung des "Object_Dictionary" erreicht werden, die es erlaubt, einen EZ_CAN 2.0-Knoten als "Slave" an einem beliebigen CANopen-Netz zu betreiben. Selbstverständlich kann in diesem Fall nicht auf die SAS-Dienste zugegriffen werden.
Der bei EZ_CAN 1.0 eingeführte Kopierdienst "COPY" wird in der Version 2.0 abgelöst.
"COPY" soll ersetzt werden durch das Zusammenspiel zwischen default-SDO-Kanälen, Erweiterungen des CANopen "Object Dictionary" und der dynamischen Identifiervergabe zur Laufzeit.
Das "Object_Dictionary" erhält neue Einträge für den Anschluß der "Remote-Shell"(XC) und des "File-Managers" (ED) des Echtzeitbetriebssystemes.
Für die Übertragung von Dateinamen und Pfaden, an den File-Manager, ist die Erweiterung der 'domain_download_protocol' bzw. 'domain_upload_protocol' erforderlich.
Multimaster-Feldbussystem
Ein häufig anzutreffendes Mißverständnis bei Multimaster-Systemen ist die Namensgebung von zentralen Verwaltungseinheiten, denn die Multimaster-Fähigkeit bezieht sich ausschließlich auf den Zugriff auf das Medium während des Betriebes. Für die Steuerung der Inbetriebnahme, und bei EZ_CAN auch während des Betriebes, werden zentrale Verwaltungseinheiten benötigt, die Systemweit nur einmal vorhanden sind. Diese zentralen Verwaltungseinheiten werden bei EZ_CAN 2.0 als 'Manager' bezeichnet und befinden sich, zur Vereinfachung des Gesamtsystemes, auf dem Buszugangsknoten.
Für die lokale Abwicklung der angeforderten Dienste stehen auf den einzelnen Knoten 'Agenten' bereit, die dem 'Manager' als Ansprechpartner dienen.
Abgewickelt wird die Kommunikation zwischen 'Manager' und 'Agent' über Protokolle, in denen Netzwerk- und Objekt-Informationen ausgetauscht werden.
Im Gegensatz zum objektorientierten Prozessdatenaustausch werden Protokolle teilnehmerbezogen übertragen, d.h. in einer Protokollnachricht wird neben den Daten, auch die Empfängeradresse (Node-ID) und die Art des Auftrages übertragen.
In einem Multimaster-System kann jeder Teilnehmer (fast) zu jeder Zeit auf das Medium zugreifen. Diese Eigenschaft, die für die Übertragung von Prozessdaten große Vorteile birgt, erfordert für die Anforderung und Abwicklung eines bestätigten Dienstes besondere Synchronisationsmaßnahmen.
So darf auf der einen Seite keine Anforderung 'verloren' gehen und auf der anderen Seite kein Dienst ausgeführt werden, bevor der aktuell bearbeitete Dienst nicht abgeschlossen ist.
Ein Beispiel für diese Anforderung ist die Anmeldung eines Busobjektes zur Laufzeit. oder das kopieren einer Datei über den CANbus auf einen entfernten Knoten.
Zur Umsetzung dieser Forderung benutzt EZ_CAN ausgiebig das von RTOS/UH bereitgestellte Warteschlangenkonzept.
Ausblick
Über das Ende des geförderten Projektes hinaus plant das Labor für Echtzeitsysteme Aktivitäten im Bereich Feldbussysteme.
____________________________________________________________
Automatisierung von lebensmitteltechnischen Anlagen
Prozessregelung und Visualisierung einer Sattdampfentkeimungsanlage
Automatisierung eines Verfahrensprozesses der Lebensmitteltechnologie
In der Sattdampfentkeimungsanlage des Fachbereichs Lebensmitteltechnologie der FH Lippe und Höxter werden verschiedene keimbelastete Metall- oder Glasträger gezielt einer Dampfbehandlung bei unterschiedlichen Druck- und Temperaturebenen unter Sättigungsbedingungen ausgesetzt, um so die Reduktionsrate und die Reaktionsmechanismen der Keime zu untersuchen.
Das Besondere an dem Lemgoer Entkeimungsverfahren ist neben einer Sattdampfbehandlung bei Temperaturen von 70-130 ºC ein schlagartiges Evakuieren des Prozessraumes. Dies führt zu einem plötzlichen Wiederverdampfen des vorab gebildeten Kondensates. Die Folge ist ein mechanisches Entfernen von Keimen (Sporen) von der Oberfläche. Durch die Applizierung dieses Prozesses wird die schonende Entkeimung von Gewürzen und anderen Lebensmitteln möglich.
Die Entkeimungsapparatur der FH Lippe und Höxter besteht aus folgenden Baugruppen:
Dampferzeugereinheit mit Druckreduzierventil und Kondensatabscheider zur Speisung der Apparatur mit Dampf
Reaktoreinheit mit Sichtzellen-Autoklav
Vakuumeinheit mit Wärmeübertrager, Vakuumpumpe und Vakuumpuffer zum schnellen evakuieren
Hier ein kurzer Einblick in einen typischen Prozessablauf, welcher wie folgt segmentiert werden könnte:
Aufheizen aller dampfberührten Anlagenteile außer dem Autoklaven
Pause
Spülen: 2 x 0,5 Sekunden Dampfzugabe bei geöffnetem Vakuumventil.
Pause
Entkeimen bei geschlossenem Vakuumventil. Dampfzugabe für beispielsweise 24 Sekunden bei 115 ºC.
Nachvakuum zum Kühlen und Trocknen.
Aufgaben von Interbuskomponenten, PC Worx und Genesis 32:
Regelung des gesamten Verfahrensprozesses, dazu gehört:
Temperaturregelung des Dampferzeugers (60 bis 100ºC)
Steuerung der Vakuumpumpe
Zeitgenaue Steuerung mehrerer Ventile
Messwertaufnahme verschiedener Temperatur- und Drucksensoren im Millisekundenbereich
Kühlwasserüberwachung
Verschiedene Ablaufprogramme für unterschiedliche Versuchsabläufe
Prozessvisualisierung: Temperaturen, Druck an verschiedenen Prozessstellen, Zustand der Ventile, Prozesszeit, Not-Aus-Zustand, Datenaufnahme und Speicherung im Microsoft-Excel-Format.
____________________________________________________________
Automatisierung von lebensmitteltechnischen Anlagen
Automatisierung eines Labormischers
(Frank Weber)
Im Rahmen einer Diplomarbeit wurde erneut eine fachbereichsübergreifende Diplomarbeit der Fachbereiche Elektrotechnik (FB5) und Lebensmitteltechnologie (FB4) in Zusammenarbeit mit verschiedenen Industriefirmen durchgeführt. Nachdem bereits die Brennereianlage im Bereich Getränketechnologie der FH Lippe und Höxter automatisiert wurde, ist nun im Juli ein weiteres Projekt erfolgreich zum Abschluss gekommen.
Die Diplomarbeit 'Automatisierung und Visualisierung eines Labormischers mit Phoenix Interbus' hatte zum Ziel, einen handelsüblichen Labormischer als Modell einer industriellen Grossanlage für die Lebensmittelherstellung um eine vollautomatische Steuerung zu erweitern. Die Bedienung und Überwachung erfolgt dabei über den Bildschirm eines angeschlossenen PCs. Über eine integrierte Rezepturverwaltung mit Editor können fertige Produktionsabläufe aufgerufen und gestartet werden, sowie neue Rezepturen erstellt oder geändert werden.
Als Student der Elektrotechnik/Automatisierungstechnik habe ich (Frank Weber) die Arbeit im Labor für Verfahrenstechnik (Prof. Dr.-Ing. Möller, Dipl.-Ing. Lehre) bei den Lebensmitteltechnologen durchgeführt. Betreut wurde das Projekt dabei vom Labor für Echtzeitsysteme (Prof. Dr.-Ing. Hausdörfer) sowie Herrn Dipl.-Ing. StR Bröker (Lebensmittelchemie). Große Unterstützung kam auch von verschiedenen Firmen aus der Industrie, die dabei die Einsatzfähigkeit und Anwendung ihrer Produkte im Lebensmittelbereich demonstrieren konnten.
Der Mischer Labin-1-SV der italienischen Firma Comec mit 2 l- Mischbehälter wurde von der Firma MTI Mischtechnik aus Detmold zur Verfügung gestellt, die Elektronik und das Feldbussystem INTERBUS zur Steuerung stammen von Phoenix Contact aus Blomberg. Zahlreiche weitere Firmen haben Komponenten wie Frequenzumrichter (SEW), Pumpen (Bran+Luebbe, Fristam), Schaltschrank (Rittal) und Sensoren (Jumo) gestiftet.
Als Ergebnis steht nun ein universell einsetzbarer, programmierbarer Mischer bereit, der die verschiedensten Funktionen eines Herstellungsprozesses bietet. Neben dem Rühren mit variablen Geschwindigkeiten bietet die Steuerung die Möglichkeit, über die angeschlossenen Dosierpumpen gezielt Flüssigkeiten zuzumischen. Durch den doppelwandigen Aufbau des Mischbehälters wird das heizen und kühlen des Produktes ermöglicht. Die Temperaturgenauigkeit beträgt dabei bis zu 0,3 °C. Der komplette Ablauf des Mischprozesses wird dabei über Rezepturen festgelegt, in denen die einzelnen Schritte sekundengenau vorgegeben werden.
Mit dem entstandenen Gerät zeigt sich wiederum die steigende Notwendigkeit der Prozessautomatisierung in der Lebensmittelherstellung. Die Produktionsabläufe können genauer eingehalten werden als dies bei reiner Handbedienung möglich wäre und die Qualitätssicherung und die Überwachung werden durch die automatische Protokollierung der Prozessdaten erleichtert. Darüber hinaus lässt sich der Bedienungsaufwand teilweise erheblich reduzieren.
Weiterhin bestätigt sich der Vorteil einer fachübergreifenden Ausbildung der Ingenieure der Fachhochschule Lippe und Höxter, die damit auf die vielseitigen Aufgabenstellungen in der Industrie vorbereitet werden. Es werden alle notwendigen Grundkenntnisse vermittelt, die es den Studenten nach dem Studium ermöglichen, sich in die verschiedensten Gebiete einzuarbeiten und Kompetenz zu zeigen.
So waren bei der Realisierung der Mischersteuerung nicht nur reine Elektrotechnik- und Programmierkenntnisse gefragt, es waren auch die Bereiche Informatik, Mechanik und Verfahrenstechnik abzudecken. Vor dem eigentlichen Aufbau der Steuerung und der Programmierung mussten die notwendigen verfahrenstechnischen Prozesse analysiert werden, um zu verstehen, was die Apparatur endgültig leisten muss. Dazu wurden dann verschiedene Pumpentypen für die Dosieraufgaben ausgewählt, was ein Verständnis der verschiedenen mechanischen Grundprinzipien bedingt.
Im praktischen Teil der Arbeit war dann die Planung und der Aufbau eines neuen Schaltschranks gefordert. Dafür war ein Rollgestell notwendig, welches dann nach technischen Zeichnungen extern angefertigt worden ist. Zur Dokumentation des elektrischen Aufbaus der Steuerung wurde dann schließlich die Einarbeitung in ein Elektro- CAD- Programm unumgänglich. Die Programmierung der SPS erfolgte nach den genormten Programmiersprachen der IEC61131 während die Bedienoberfläche am PC mit Hilfe eines Visualisierungsprogramms und 'Visual Basic for Applications' entstanden ist. Alles in Allem ist mit dieser Diplomarbeit ein sehr praxisnahes Projekt abgelaufen, bei dem alle erforderlichen Stationen von der Idee über die Planung und Materialbeschaffung bis zum Endprodukt durchlaufen wurden.
Wieder einmal zeigen sich bei dieser Arbeit auch die guten Kontakte der Fachhochschule zu den regionalen Unternehmen, die das Projekt mit vielerlei technischen Geräten unterstützt haben und darüber hinaus auch die praxisgerechte Anwendung ermöglicht haben.
___________________________________________________
Automatisierung von lebensmitteltechnischen Anlagen
Steuerung und Visualisierung einer Destillationsanlage
(Joachim Pucker)
Im Bereich der Destillationstechnik ist der Automatisierungsgrad der Brennereien noch nicht sehr hoch. Bedingt durch Zollauflagen dürfen die Alkoholdestillationsanlagen nur bis zu einer bestimmten Größe gebaut werde, so daß die Automatisierung oft einen größeren finanziellen Aufwand bedeutet, als die Anschaffung. In kleinen Brennereien oder bäuerlichen Betrieben wird aus diesem Grund auf eine Automatisierung verzichtet und die Anlage von Hand gesteuert. Durch die großzügige Unterstützung mehrerer Unternehmen, hat die Fachhochschule Lippe und Höxter bei der Neuanschaffung einer Destillationsanlage die Möglichkeit erhalten, eine der ersten automatisierten Anlagen dieser Art zu erstellen. In einer Zusammenarbeit der Fachbereiche Lebensmitteltechnologie und Elektrotechnik ist dieses Vorhaben im Rahmen dieser Diplomarbeit durchgeführt worden.
Die Destillationsanlage der FH Lippe und Höxter ist so ausgestattet, daß mit ihr jede übliche Art der Alkoholbrennerei durchgeführt werden kann. Durch verschiedene Dreiwegehähne wird der Weg des Dampfes z.B. über die Kolonne oder an der Kolonne vorbei, durch den Katalysator oder nicht vorgegeben. Über eine Vielzahl von Sensoren können die Prozessparameter an jeder wichtigen Stelle der Anlage aufgenommen werden.
Aufgabe der Diplomarbeit war der Aufbau und die Inbetriebnahme der Destillationsanlage, die Visualisierung des Prozesses, die Handbedienbarkeit der Anlage über den Bildschirm, eine Meßwertprotokollierung, die Anlagendokumentation und der Einsatz von Softwarereglern sowie die Durchführung von Regelversuchen. Der nächste Schritt, der im Rahmen einer weiteren Diplomarbeit ausgeführt werden soll, ist die Erstellung des automatischen Ablaufes eines Destillationsprozesses zusammen mit einer Rezeptursteuerung.
Die Automation der Destillationsanlage erfolgte mit einer PC-Steuerung und dem Feldbussystem INTERBUS. Es kommen zwei Schaltschränke zum Einsatz, wodurch die I/O-Einheiten des Feldbussystems, ihrem primären Zweck folgend, dezentral angeordnet sind. Der eigentliche Zweck eines Feldbussystems, die Einsparung von Kosten und die schnelle Inbetriebnahme einer Anlage, können so auch an dieser Destillationsanlage demonstriert werden.
Die PC-Steuerung wird durch eine Einsteckkarte (Field Controller, Phoenix Contact) realisiert und übernimmt mit Hilfe eines eigenen Prozessors im Visualisierungs-PCs die Abarbeitung der Steuerungs- und Automatisierungsprogramme unabhängig vom Host. Das PC-System ist somit frei für die Visualisierung der über INTERBUS angeschlossenen Prozesssignale und Prozessparameter. Der Vorteil dieser Variante ist die Einsparung einer speicherprogrammierbaren Steuerung (SPS). Da unsere Anlage mit einer Visualisierung ausgestattet werden sollte, war der Einsatz eines PCs obligatorisch. Der Field Controller ersetzt hier also die SPS, was sowohl eine Einsparung von Platz im Schaltschrank, sowie eine Einsparung von Kosten ermöglicht, da sein Preis weit unter dem einer handelsüblichen SPS liegt.
Für die durchgängige Konfiguration und Programmierung unter IEC 61131 wird bei diesem Field Controller die Automatisierungssoftware PC WORX der Fa. Phoenix Contact eingesetzt. Für die Visualisierung stand das Softwarepaket Genesis32 der Fa. ICONICS zur Verfügung.
Wichtigste Features der Anlage sind die Darstellung aller Prozessparameter auf der Bildschirmoberfläche, die automatische Prozessdatenaufnahme und die Regelung wichtiger Prozessparameter. Alle Messdaten und Aktorstellungen während eines Brennvorgangs werden im Rechner in tabellarischer Form hinterlegt und können jederzeit wieder abgerufen werden. Auf diese Weise kann der Einfluss verschiedenster Zustände der Anlage auf die Qualität der Produkte erforscht werden. Die Voraussetzungen um eine gleichbleibende hohe Qualität zu erreichen wurden so geschaffen.
An der Destillationsanlage beteiligte Unternehmen:
Phoenix Contact GmbH & Co
Christian Carl Ing. GmbH
Bürkert GmbH & Co KG
Kieselmann Anlagenbau GmbH
Rittal, Werk Rudolf Loh GmbH
SEW Eurodrive GmbH & Co.
VEGA Grieshaber KG
Krohne
Max Müller GmbH
