DE19949558A1 - Steuerungsprogramm für eine numerische Werkzeugmaschine mit einer wiederverwendbaren Softwarestruktur - Google Patents

Abstract

Um eine wiederverwendbare Softwarestruktur für das Steuerungsprogramm einer numerischen Werkzeugmaschine zu erstellen, wird das Steuerungsprogramm in einen anwendungsabhängigen Teil und einen anwendungsunabhängigen Teil gegliedert. Dabei weist der anwendungsunabhängige Teil der Software erfindungsgemäß mehrere Framework Klassen auf, die generische Funktionen beinhalten, beispielsweise für ein Mensch-Maschine-Interface, eine Geometrieverarbeitung, einen Interpolator. eine Bewegungsverarbeitung und einen speicherprogrammierbaren Steuerteil. Im anwendungsabhängigen Teil werden anwendungsspezifische Funktionen in abgeleiteten Klassen implementiert, die von den Klassen des anwendungsunabhängigen Frameworks abgeleitet werden. Von den abgeleiteten Klassen werden Instanzen gebildet, die die Daten für die implementierten Funktionen beinhalten und als Objekte bezeichnet werden. Zwischen den Objekten bestehen Kommunikationskanäle, über die Nachrichten ausgetauscht werden.

Description

Die Erfindung betrifft ein Steuerungsprogramm für eine numerische Werk­ zeugmaschine mit einer wiederverwendbaren Softwarestruktur nach An­ spruch 1.

Die EP 0 524 344 B1 offenbart eine konfigurierbare Werkzeugmaschinen­ steuerung, die aus mehreren aufgabenorientierten Einheiten besteht, bei­ spielsweise einem numerischen und einem speicherprogrammierbaren Steuerteil, einer Bedienereinheit und einem Kommunikationsbereich mit Netzwerkschnittstelle. Weiterhin ist mindestens ein in Soft- oder in Soft- und Hardware realisiertes Funktionsobjekt, das eine Funktion durchführen kann, vorgesehen. Dieses Funktionsobjekt untergliedert sich in einen Prozedurteil, einen Kommunikationsteil und evtl. einen Bedienteil. Zusätzlich ist minde­ stens ein Objektmanager vorhanden, der mindestens zwei Funktionsobjekte verwaltet, insbesondere deren Nachrichtenaustausch synchronisiert. Diese Steuerungsstruktur wird auf mindestens einer Datenverarbeitungsanlage realisiert, welche die Daten der Funktionsobjekte und Objektmanager bear­ beitet und selbst als aufgabenorientierte Einheit ausgebildet ist. Die Funkti­ onsobjekte werden zu Prozessen zusammengefasst. Dabei werden so viele Prozesse gebildet, wie Datenverarbeitungsanlagen vorhanden sind und durch jede Datenverarbeitungsanlage ein Prozess abgearbeitet.

Aus der EP 0 524 344 B1 ist nicht bekannt, wie die Software auszugestalten ist, damit deren prinzipielle Struktur wiederverwendet werden kann.

Aus der EP 0 657 043 B1 ist eine objektorientierte Steuerung für Werkzeug­ maschinen bekannt, bei der aus Objektklassen eine Reihe von Objekten ge­ bildet werden. Ausgehend von der in der EP 0 524 344 B1 offenbarten Steuerung werden in der EP 0 657 043 B1 Objektklassen und Objekte of­ fenbart, die erforderlich sind, um eine herkömmliche Funktionalität einer Steuerung zu realisieren. Dazu gehören beispielsweise Objektklassen für Bearbeitungs-, Geometrie, Kinematik- und Technologiedatentypen ebenso wie Steuerdatentypen und eine Objektklasse Ablaufsteuerung. Von jeder Objektklasse kann eine beliebige Anzahl Objekte gebildet werden, die je­ weils einen eigenen Datenbereich, einen Botschaftenmechanismus zur Kommunikation mit anderen Objekten und einen Prozedurteil zur Ausfüh­ rung von Methoden zur Bearbeitung, Kinematik, Geometrie oder Technolo­ gie beinhalten. Aufgrund der Abstammung mehrerer Objekte von einer Ob­ jektklasse weisen diese Objekte teilweise identischen oder zumindest ähnli­ chen Programmcode auf, den sie von der Objektklasse geerbt haben. Wei­ terhin sind auch die Objektklassen als abstraktes Datenmodell in der steue­ rungsinternen Datenhaltung abgebildet, wodurch abstrakte anwendungs­ spezifische Datentypen ergänzbar und anwendungsspezifische Objektaus­ prägungen modifizierbar sind. Durch die Ablaufsteuerung werden die Benut­ zereingaben interpretiert und führen zur Aktivierung der ausgewählten Ob­ jekte. Die ausgewählten Objekte kommunizieren untereinander und bilden durch diese netzwerkartige Verknüpfung eine ablauffähige Funktionseinheit der Steuerung.

Aus der EP 0 657 043 B1 ist zwar bereits bekannt, Eigenschaften einer Ob­ jektklasse an ein Objekt dieser Klasse weiterzuvererben und für die Objekt­ klassen abstrakte Datenmodelle in der steuerungsinternen Datenhaltung zu speichern, die vom Programmierer verändert werden können, was jedoch nur die Objekte betrifft. Da ein Objekt immer mindestens eine konkrete Funktion der Steuerung und damit der Maschine realisiert, müssen die Ob­ jekte maschinenspezifische Merkmale aufweisen, wodurch sie inkompatibel sind zu einer anderen Steuerung für eine andere Maschine. Somit können Objekte in der Regel nicht unverändert wiederverwendet werden. Weiterhin nachteilig ist, dass derart nicht die Struktur der Steuerungssoftware, also beispielsweise das Zusammenwirken von einzelnen Objekten untereinander, für eine erneute Verwendung bereitgestellt werden kann, da diese Informa­ tion nicht in den Objekten gespeichert ist.

Aus der EP 0 717 866 B1 ist ein CNC-Steuerungssystem bekannt, das ein objektorientiertes Programm beinhaltet, in welchem Objekte objektorientierte Nachrichten austauschen. Im objektorientierten Programm sind die Objekte in Klassen unterteilt, beispielsweise eine Prozessklasse, die Objekte für Be­ arbeitungsprozesse wie Bohren, Gewindeschneiden, Räumen usw. bein­ haltet, die durch Maschinenkomponenten ausgeführt werden. Dabei bein­ haltet eine Klasse immer ähnliche Objekte, das heisst Objekte, die in ihrer Grundstruktur übereinstimmen. Aufgrund der einheitlichen Grundstruktur der Objekte einer Klasse besteht die Möglichkeit, dass beim Erstellen neuer Objekte ausgewählte Eigenschaften der jeweiligen Klasse an das neue Ob­ jekt vererbt werden. Eine weitere Objektklasse weist Maschinenkomponen­ ten, wie beispielsweise eine Spindel, Achsen, einen Drehtisch usw., auf. Weiterhin sind Objektklassen für das Kernel mit einem Motion und einem Logic Controller als Objekte, für Plattform Services, das Operating System und die Device Driver vorgesehen. Im Betrieb der Steuerung ist es erforder­ lich, dass Nachrichten zwischen den einzelnen Objekten ausgetauscht wer­ den. Für einen Bohrvorgang wird beispielsweise vom Bohr-Objekt eine Nachricht die Drehzahl des Bohrers betreffend an das Objekt Spindel über­ tragen, weiterhin werden Nachrichten die Position des Loches betreffend an die Objekte der beteiligten Achsen übertragen usw.. Dabei ist ein Standard- Interface für die Nachrichten vorgesehen, damit diese einen universellen Aufbau aufweisen und unabhängig von den beteiligten Objekten ausgestal­ tet werden können. Diese Standard-Schnittstelle zum Nachrichtenaustausch zwischen Objekten wird bei einem Objekt, das Nachrichten bezüglich der Bewegung empfängt oder sendet durch einen Softwarekern realisiert, der in Echtzeit arbeiten soll und Nachrichten empfängt und sendet.

Auch aus der EP 717 866 B1 ist nicht bekannt, wie die Struktur von Steue­ rungssoftware auszugestalten ist, um eine Wiederverwendung des Software- Designs bei einer ähnlichen numerischen Steuerung zu ermöglichen.

Aus dem Buch "Entwurfsmuster", von Erich Gamma und Richard Helm, er­ schienen im Addison-Wesley Verlag 1996 und dem Buch "Objektorientierte Software-Entwicklung am Beispiels von ET++", von Erich Gamma, erschie­ nen im Springer Verlag, 1992 ist der Begriff des Frameworks bekannt. Unter Framework wird eine Menge kooperierender Klassen verstanden, welche die Elemente eines wiederverwendbaren Entwurfs für eine bestimmte Art von Software darstellen. Ein Framework bietet eine Architekturhilfe beim Auftei­ len des Entwurfs in abstrakte Klassen und beim Definieren ihrer Zuständig­ keiten und Interaktionen. Ein Entwickler passt das Framework für eine be­ stimmte Anwendung an, indem er Unterklassen der Framework-Klassen bil­ det und deren Objekte zusammensetzt. Ein Framework wird daher von ei­ nem Programmierer dazu benutzt, um die Softwarearchitektur einer Gruppe verwandter Anwendungen festzulegen. Diese Entwurfswiederverwendung ergänzt die bereits aus der objektorientierten Softwareentwicklung bekannte Codewiederverwendung.

Dabei ist von Nachteil, dass aus obigen Büchern keine Anwendung der Framework-Technologie bei numerischen Steuerungen offenbart wird. Daher ist aus diesem Stand der Technik kein Framework für eine Steuerung einer numerischen Werkzeugmaschine bekannt.

Aus dem Artikel "Framework - Basis eines Automatisierungssystems", von Georg Süss, erschienen in etz, Heft 21/1998, Seite 22-25, ist bekannt, dass ein Framework nicht nur eine gemeinsam genutzte Datenhaltung er­ möglicht, sondern auch einen integrierten Ansatz für die Beschreibung und abgestimmte Ausführung einer Gesamtapplikation in einer verteilten Archi­ tektur realisierbar macht. Dafür muss ein Framework für Automatisierungs­ anwendungen auf Windows NT aufsetzen, um eine Strukturierung der Ge­ samtapplikation in Objekten mittels dem Component Object Model und die Verteilung der Komponenten eines Systems über mehrere Rechner mittels dem Distributed Component Object Model zu ermöglichen. Ein Automatisie­ rungs-Framework bietet dann die Möglichkeit die einzelnen Bestandteile ei­ ner verteilten Automatisierungslösung zentral in einer systemweiten Daten­ ablage zu sammeln. Damit stehen diese Informationen sofort jedem Rechner eines Netzwerks identisch zur Verfügung. Weiterhin erfolgt durch das Framework - bei einer Unterteilung der Applikation in Einzelobjekte - eine Verwaltung dieser Objekte und Zuordnung zu einzelnen Netzwerkstationen. Dies ermöglicht eine dynamische Verschiebung einzelner Objekte zur Lauf­ zeit, wodurch eine bessere Auslastung der Rechner erreicht werden kann. Ausserdem können dadurch weitere Stationen dynamisch in das Applikati­ onsnetzwerk zur Laufzeit eingebunden werden.

Dabei ist nachteilig, dass das Framework auf einer Windows NT Plattform aufsetzen muss, um das Component Object Model und das Distributed Component Object Model nutzen zu können. Diese beiden Modelle sind in Windows NT verfügbar und stellen die Funktionalität für die beschriebenen Verbesserungen bereit. Weiterhin von Nachteil ist, dass nicht offenbart wird, wie ein Framework zu realisieren ist.

Aus dem Artikel "Softwarekonzepte für eine steuerungsintegrierte Werk­ zeugüberwachung" von I. Suwalski, R. Urban und J. Burger, erschienen in ZWF 92 (1997) 9, Seite 436-439, ist bekannt, dass sich aus dem Bereich objektorientierter Software-Techniken heraus die Software-Frameworks ent­ wickelt haben. Ein Framework besteht aus einer Menge zusammenarbeiten­ der Klassen, die die Architektur der Anwendung bestimmen. Durch Verwen­ dung von Frameworks wird daher die Entwurfswiederverwendung gegen­ über der Codewiederverwendung betont. Durch die Verwendung von Frameworks werden problemspezifische Algorithmen vom Entwurf entkop­ pelt. Die dadurch erreichte Abstraktion des Entwurfs des Systems von der Implementierung problemspezifischer Algorithmen ermöglicht eine schnel­ lere Entwicklung, führt zu ähnlichen Strukturen und einer einfacheren Wart­ barkeit. Ausserdem wird auch eine klare, strukturierte und schlanke Doku­ mentation ermöglicht. Dies wird anhand eines Beispiels mit Frameworks er­ läutert, die für einzelne Prozesse die Grundmechanismen der Kommunika­ tion und die Struktur der Implementierung als Zustandsmodell vorgegeben haben. Flexibilität wird durch Verhaltensmuster erreicht, deren algorithmi­ sche Ausprägung für den jeweiligen Anwendungsfall implementiert wird.

Dabei ist von Nachteil, dass nicht konkret offenbart wird, wie auch andere Funktionen als die steuerungsinterne Werkzeugüberwachung durch ein oder mehrere Frameworks realisiert werden können. Weiterhin wird weder die Struktur, die durch Frameworks definiert wird noch die Struktur eines Frameworks selbst konkret angegeben.

Aufgabe der vorliegenden Erfindung ist es daher, Steuerungssoftware für die Steuerung von Werkzeugmaschinen unter Benutzung von Frameworks für möglichst viele Steuerungsfunktionen derart auszugestalten, dass die Struktur und der maschinen- und steuerungsunabhängige Teil der Imple­ mentierung der Steuerungssoftware möglichst vollständig von einem Framework übernommen werden kann. Für eine konkrete Steuerungssoft­ ware in Form einer Applikation sollen nur noch maschinen- und technologie­ spezifische Funktionen sowie die Gestaltung der Bedienoberfläche imple­ mentiert werden.

Diese Aufgabe wird durch ein Verfahren mit den im Anspruch 1 angegebe­ nen Merkmalen gelöst.

Weiterbildungen und vorteilhafte Ausgestaltungen des erfindungsgemässen Verfahrens sind den abhängigen Ansprüchen zu entnehmen.

Das erfindungsgemässe Verfahren weist den Vorteil auf, dass die als Framework ausgestaltete Software für eine generische numerische Steue­ rung als Klassenbibliothek implementiert ist, die die Softwarestruktur einer generischen numerischen Steuerung vollständig beinhaltet. Die Software einer generischen numerischen Steuerung umfasst dabei die gesamte funk­ tionale Struktur der Steuerungssoftware, nicht aber die konkret program­ mierten Funktionen. Durch die Klassenbibliothek werden einheitliche Schnittstellen für die konkreten Funktionen definiert. Die einzelnen Funktio­ nen, die durch die Steuerung ausgeführt werden, sind durch eine steue­ rungsspezifische Klasse implementiert, die von einer Klasse der Klassen­ bibliothek abgeleitet ist. Dadurch kann diese Steuerungsstruktur auf unter­ schiedliche Steuerungen übertragen werden, selbst wenn die konkreten Funktionen anderer Steuerungen völlig unterschiedlich sind. Durch Abstrak­ tion der Struktur und der Klassenbibliotheken von den konkreten Funktionen wird die Softwarestruktur wiederverwendbar.

Die Erfindung wird im folgenden anhand der in der Zeichnung dargestellten Ausführungsformen näher erläutert. Die Figur zeigt eine mögliche Aufteilung des Steuerungsprogramms in Klassen, angeleitete Klassen und Instanzen abgeleiteter Klassen.

Die Erfindung soll im folgenden anhand einer einfachen numerischen Steue­ rung für eine Werkzeugmaschine erläutert werden. Dabei ist es für die Struktur der Steuerungssoftware unerheblich, ob es sich bei der Werkzeug­ maschine um eine Fräs-, Dreh-, Schleif- oder Erodiermaschine oder um ein Bearbeitungszentrum handelt.

Das Steuerungsprogramm für eine numerische Steuerung, welches in Fig. 1 teilweise grafisch dargestellt wird, kann auf Basis eines Frameworks reali­ siert werden, wobei das Framework durch mindestens eine Klassenbiblio­ thek 1 implementiert wird. Die wesentlichen Funktionen des Steuerungspro­ gramms einer Werkzeugmaschine lassen sich in die Funktionalitätsgruppen Geometrieverarbeitung 1.2, Interpolator 1.4, Mensch-Maschine-Interface 1.1, Bewegungssteuerung und speicherprogrammierbarer Steuerungsteil unter­ gliedern.

Erfindungsgemäss ist eine Framework Klassenbibliothek 1 vorgesehen. Diese Klassenbibliothek 1 beinhaltet die Software einer generischen Steue­ rung für die einzelnen abstrahierten Funktionalitäten und deren Zusammen­ wirken. Dabei wird durch die Klassenbibliothek 1 lediglich die funktionale Struktur des Steuerungsprogramms festgelegt; der Programmcode für die konkreten Funktionen ist aber nicht in dem Framework enthalten. Dieser Programmcode wird durch die spezifische Implementierung der Klassen in Form von abgeleiteten Klassen 1.1-1.4 definiert, bei denen nicht die Struktur, sondern die durchgeführte Funktion und der dafür erforderliche Programmcode das wesentliche Merkmal ist. Durch ein Framework wird da­ her die Existenz einer Funktion im Steuerungsprogramm und das Zusam­ menwirken mit anderen Funktionen des Steuerungsprogramms definiert. Die Realisierung der Funktion durch Programmcode ist hingegen nicht im Framework enthalten. Diese erfolgt in einer abgeleiteten Klasse 1.1-1.4, die von einer Klasse der Klassenbibliothek 1 abgeleitet ist und in das Framework eingebunden wird.

Durch die Implementierung der abgeleiteten Klassen wird eine Applikation realisiert. Beispielsweise wird eine abgeleitete Klasse für einen Interpolator 1.4 implementiert, die an eine bestimmte Form der Ansteuerung der Antriebe angepasst ist.

Weiterhin wird durch ein Framework die Interaktion, also das Zusammenwir­ ken, zwischen einzelnen abgeleiteten Klassen 1.1-1.4 als Funktionalität der generischen Steuerung realisiert. Dies erfolgt durch Kommunikationska­ näle 2.1-2.5 zwischen einzelnen Objekten 1.1.1-1.4.1, die Instanzen der abgeleiteten Klassen 1.1-1.4 des Frameworks bzw. der Klassenbibliothek 1 sind. Ein derartiger Kommunikationskanal 2.1-2.5 wird durch aus dem Stand der Technik bekannte Mechanismen zum Datenaustausch realisiert. Durch einen Kommunikationskanal 2.1-2.5 wird festgelegt, welche Objekte 1.1.1-1.4.1 des Frameworks überhaupt miteinander kommunizieren kön­ nen. Aus dem Stand der Technik sind bereits Verfahren bekannt, um zu de­ finieren, welche Objekte als Instanzen abgeleiteter Klassen 1.1.1-1.4.1 miteinander kommunizieren. Diese Definition ist Teil der Implementierung einer konkreten Steuerungssoftware.

Weiterhin wird durch das Framework das Datenformat und das Protokoll der Übertragungsdaten definiert, d. h. welche Daten über einen Kommunikati­ onskanal 2.1-2.5 zwischen Objekten 1.1.1-1.4.1 des Frameworks über­ tragen werden. Die Interpretation der Übertragungsdaten als Parameter oder Anweisung erfolgt durch die abgeleiteten Klassen 1.1-1.4.

Wird bei Erstellung eines neuen Steuerungsprogramms ein bereits vorhan­ denes Framework benutzt, liegen dem Programmierer bereits Framework Klassen 1 vor, die bei der Erstellung des Steuerungsprogramms für eine spezifische Steuerung einer bestimmten Werkzeugmaschine teilweise an diese angepasst bzw. für diese implementiert werden müssen. Dies ge­ schieht dadurch, dass der Programmierer aus den vorhandenen Framework Klassen 1 abgeleitete Klassen 1.1-1.4 bildet und dadurch eine Applikation erzeugt.

Die Klassen 1 des Frameworks definieren virtuelle Funktionen, deren Im­ plementierung in den abgeleiteten Klassen 1.1-1.4 erfolgt, oder deren Im­ plemetierung durch die abgeleiteten Klassen 1.1-1.4 bei Bedarf auch ge­ ändert (überladen) werden kann. Die Implementierung der abgeleiteten Klasse 1.1-1.4 erfolgt, indem der Programmierer die für die gewünschte Funktionalität notwendigen Implementierungen dieser virtuellen Funktion programmiert und die dafür notwendigen Daten (Attribute) definiert.

In einem zweiten Schritt der Implementierung legt der Programmierer fest, von welchen abgeleiteten Klassen 1.1-1.4 Objekte 1.1.1-1.4.1 instantiiert werden und welche Objekte 1.1.1-1.4.1 miteinander kommunizieren. Die Information, welche Objekte 1.1.1-1.4.1 erzeugt werden und welche mit­ einander kommunizieren, kann dabei in den abgeleiteten Klassen vorhanden sein, aus einer externen Datei ausgelesen oder vom Benutzer eingegeben werden.

Die prinzipielle Funktionsweise ist durch die generische Steuerung definiert und in den Klassen 1 des Frameworks implementiert. Die konkrete Funktio­ nalität einer Steuerung ergibt sich daraus, dass im Betrieb virtuelle Funktio­ nen der generischen Steuerung aufgerufen werden und das von der kon­ kreten Implementierung abhängige Ergebnis weiterverwendet und gegebe­ nenfalls an Objekte 1.1.1-1.4.1 übermittelt wird, deren Auswahl ebenfalls, wie oben beschrieben, von der konkreten Realisierung abhängt.

Durch Verwendung eines bereits existierenden Frameworks beschränkt sich die Erstellung eines Steuerprogramms dann auf die Programmierung der durchzuführenden technologie- und maschinenspezifischen Funktionen in abgeleiteten Klassen 1.1-1.4 und die Definition der Interaktion zwischen Objekten 1.1.1-1.4.1 über Kommunikationskanäle 2.1-2.5.

Entsprechend wird im Betrieb einer derart programmierten numerischen Steuerung wie in der Figur dargestellt vorgegangen. Die generische Steue­ rung, die durch die Klassenbibliothek 1 des Frameworks definiert ist, weist beispielsweise unter anderem die folgenden Funktionen auf:

• - Start der Steuerung,
• - Senden einer Nachricht von einem Sender an einen Empfänger und
• - Auslösen der Nachrichtenverarbeitung beim Empfänger.

Nachdem ein Benutzer die Steuerung eingeschaltet hat, werden durch den im Framework vorhandenen Mechanismus zur Instantiierung von abgeleite­ ten Klassen 1.1-1.4 die für die Anwendung benötigten Objekte 1.1.1-1.4.1 erzeugt. Weiterhin wird in der Klassenbibliothek 1 des Frameworks die Start- Funktion aufgerufen, was aufgrund der Funktionalität der generischen Steuerung den Aufruf einer Start-Funktion in jedem erzeugten Objekt 1.1.1-1.4.1 bewirkt. Dabei kann die Start-Funktion in einer abgeleiteten Klasse 1.1-1.4 mit einer spezifischen Implementierung überladen werden.

Bei der abgeleiteten Klasse 1.1 Mensch-Maschine-Interface wird durch die Start-Funktion beispielsweise ein Fenster geöffnet, in dem der Benutzer eine Eingabe tätigen kann. Auf diese Eingabe wird gewartet, aus der Eingabe wird eine Nachricht gebildet und diese Nachricht wird verschickt.

Bei der abgeleiteten Klasse 1.4 Interpolator werden durch die Start-Funktion die Positionen der Maschinenachsen gehalten. Dafür werden die La­ geistwerte der Achsen der Maschine ermittelt und diese Istwerte als Lage­ sollwerte den Regelkreisen vorgegeben.

Bei der abgeleiteten Klasse 1.3 Simulation wird durch die Start-Funktion ein Fenster zur Darstellung einer Simulationsgrafik geöffnet.

Die abgeleitete Klasse 1.2 der Geometrieverarbeitung (Geo) implementiert die Start-Funktion nicht, sondern verwendet die in der Klassenbibliothek vorhandene Implementierung.

Wie bereits erläutert, wird vom Mensch-Maschine-Interface 1.1.1 eine Nach­ richt gesendet, sobald eine Eingabe abgeschlossen wurde. Diese Nachricht wird durch das Framework über einen Kommunikationskanal 2.1 an den richtigen Empfänger übermittelt und im Empfänger durch das Framework eine Behandlung der Nachricht ausgelöst.

Bei der im jeweiligen Objekt 1.1.1-1.4.1 ausgelösten Behandlung nach dem Empfang einer Nachricht wird eine in der Klassenbibliothek 1 des Frameworks definierte Funktion auf die mit der Nachricht übertragenen Da­ ten angewendet. Diese Funktion muss in jeder abgeleiteten Klasse 1.1-1.4 implementiert werden. Das Framework stellt hierfür keine Implemetierung zur Verfügung.

Im Geometrie-Objekt 1.2.1 werden die Daten einer empfangenen Nachricht als anzufahrende Positionen interpretiert, auf deren Basis Parameter der Bahnkurve berechnet und als Nachricht verschickt werden.

Diese Parameter der Bahnkurve werden über einen Kommunikationskanal 2.2 an das Interpolator-Objekt 1.4.1 weitergeleitet, durch das die Achsan­ triebe der Maschine angesteuert werden und das die angefahrenen Bahn­ punkte als Nachricht verschickt.

Wird im Objekt 1.1.1 des Mensch-Maschine-Interface eine Nachrichtenbe­ handlung durch den Empfang einer neuen Nachricht ausgelöst, werden die empfangenen Daten als Position interpretiert, die dem Benutzer angezeigt wird.

Soll eine Bearbeitung nur simuliert werden, wird für die Simulation aus der abgeleiteten Klasse 1.1 Mensch-Maschine-Interface ein Objekt 1.1.2 instan­ tiiert, das die eingegebenen Daten als Nachricht an das Simulations-Objekt 1.3.1 weiterleitet.

Das Simulations-Objekt 1.3.1 führt bei der Simulation der Bearbeitung ge­ mäss den Eingaben die entsprechenden Berechnungen durch und ver­ schickt die berechneten Bahnpunkte als Nachricht.

Diese Nachricht wird vom Framework an das Mensch-Maschine-Interface 1.1.2 für die Simulation übertragen. Aufgrund der dort ausgelösten Nach­ richtenbehandlung werden die Simulationsdaten dem Benutzer angezeigt.

Um das Verschicken einer Nachricht zu realisieren, wird eine Funktion aus der Klassenbibliothek 1 des Frameworks aufgerufen. Da der Transport von Nachrichten eine Funktion der generischen Steuerung ist, gibt es keine Not­ wendigkeit und auch keine Möglichkeit diese Funktion mit einer spezifischen Implementierung zu überladen.

Gemäss der Figur kann die Steuerungssoftware untergliedert werden. Die Klassenbibliothek 1 beinhaltet Funktionen, die nicht speziell für eine Steue­ rung oder Maschine ausgestaltet sind, beispielsweise das Versenden einer Nachricht.

Zur Klassenbibliothek 1 gehören ferner virtuelle Funktionen, die aufgrund der speziellen Steuerungs-Hardware oder Maschinen-Mechanik durch den Programmierer einer abgeleiteten Klasse 1.1-1.4 eine spezifische Ausge­ staltung erfahren können, wie beispielsweise die Start-Funktion, oder müs­ sen, wie beispielsweise die Behandlung einer Nachricht, damit sie mit der speziellen Steuerungs-Hardware und/oder Maschinen-Mechanik zusam­ menarbeiten.

Die Objekte 1.1.1-1.4.1 sind Instanzen der abgeleiteten Klassen 1.1-1.4, die die spezifischen Daten für eine bestimmte Funktion beinhalten.

So wurde beispielsweise die virtuelle Funktion des Mensch-Maschine-Inter­ faces 1.1 zunächst implementiert, um mit der speziellen Steuerungs-Hard­ ware zusammenzuarbeiten, um mit einer speziellen Hardware eine Ein- und Ausgabe zu realisieren. Danach wurden die benötigten Objekte für ein Mensch-Maschine-Interface für die Simulation 1.1.2 und eines für die Bear­ beitung 1.1.1 instantiiert.

Um die notwendige Interaktion über die Kommunikationskanäle 2.1-2.5 zu erreichen, muss dem Framework bekannt sein, welche dieser Objekte 1.1.1-1.4.1 jeweils untereinander Nachrichten austauschen. Beispielsweise sen­ det ein Objekt 1.1.1 für die Eingabe Nachrichten an das Objekt 1.2.1 für die Geometrieberechnung, und empfängt Nachrichten vom Objekt 1.4.1 für die Interpolation, während die Instanz 1.1.2 derselben Klasse für die Simulation Nachrichten mit dem Objekt 1.3.1 für die Simulationsberechnung austauscht.

Die hier getroffene Aufteilung in Klassen 1, abgeleitete Klassen 1.1-1.4 und Objekte 1.1.1-1.4.1 stellt nur eine von mehreren Möglichkeiten dar. Alternativ ist beispielsweise denkbar, dass die Geometrieverarbeitung und/oder der Interpolator hardwareunabhängig programmiert werden, so dass diese Funktionalitäten in einer Klasse 1 realisiert werden können.

Durch die hier beschriebene Aufteilung des Programmcodes in Framework und ausserhalb des Frameworks angeordneten, maschinenspezifischen Programmcode wird für die Funktionen der Steuerung unterschieden zwi­ schen wiederverwendbarer Struktur, die zum Framework zusammengefasst wird, und maschinenspezifischem Programmcode, der ausserhalb des Frameworks realisiert wird. Der Programmcode des Frameworks kann bei einer Gruppe von Realisierungen benutzt werden, die sich in der benutzten Steuerungs-Hardware und Maschinen-Mechanik unterscheiden. Dabei ist der Grad wie weit die Unterschiede gehen dürfen abhängig vom Abstrakti­ onsgrad des Frameworks.

Programmcode der abgeleiteten Klassen 1.1-1.4 kann nur auf andere An­ wendungsfälle übertragen werden, wenn bei der Steuerungs-Hardware und Maschinen-Mechanik zumindest Kompatibilität gewährleistet ist.

Es ist vorteilhaft die allgemein gültige Funktionalität des Steuerungspro­ gramms für eine numerische Steuerung derart in Form eines Frameworks zu realisieren, um das durch das Framework definierte Zusammenwirken der Klassen 1 und abgeleiteten Klassen 1.1-1.4 wiederverwenden zu können. Dadurch können die komplexen Verknüpfungen der einzelnen Funktionen untereinander über Kommunikationskanäle 2.1-2.5 wiederverwendet wer­ den.

Das Framework kann zusätzlich einen Mechanismus zur Fehlerbehandlung beinhalten. Dafür ist im Framework eine Klasse mit generischen Funktionen zur Fehlerbehandlung vorgesehen, aus der durch eine maschinenspezifi­ sche Implementierung der Funktionen die abgeleitete Klasse zur Fehlerbe­ handlung erzeugt wird. Durch die Instantiierung der Funktionen der abgelei­ teten Klasse wird mindestens ein Objekt erzeugt.

Da bei jeder beliebigen Anwendung einer Funktion auf die ein Objekt bilden­ den Daten ein Fehler auftreten kann, wird vorteilhaft von jedem Objekt ein Kommunikationskanal zum Objekt Fehlerbehandlung vorgesehen. Abhängig von den zur Fehlerbehandlung vorhandenen Funktionen, sind entsprechend auch Kommunikationskanäle von dem Objekt zur Fehlerbehandlung zu den für die Fehlerbehandlung benötigten Objekten vorzusehen.

Soll beispielsweise durch eine Funktion zur Fehlerbehandlung bei einem beliebigen Fehler jede Bewegung der durch das Steuerungsprogramm ge­ steuerten Maschine verhindert werden, dann müssen Kommunikationska­ näle von allen Objekten 1.1.1-1.4.1 zum Objekt zur Fehlerbehandlung vor­ handen sein. Dadurch wird ermöglicht, dass Fehler, die in jedem Objekt auf­ treten können, auch erkannt werden können. Weiterhin muss ein Kommuni­ kationskanal vom Objekt zur Fehlerbehandlung zum Objekt 1.4.1 Interpola­ tor, durch den die Bewegungssteuerung erfolgt, vorhanden sein, um im Fehlerfall jegliche Bewegung zu verhindern.

Alternativ zum Stillsetzen aller Achsen der Maschine kann auch vorgesehen sein, dass im Fehlerfall ein bestimmter Rückzugsweg abgefahren wird, um beispielsweise das Werkzeug einer Fräsmaschine vom Werkstück zu entfer­ nen, damit weder am Werkzeug noch am Werkstück durch den Fehler eine Beschädigung verursacht wird. Dann wird durch die Nachricht des Objekts zur Fehlerbehandlung an das Interpolator-Objekt 1.4.1, dass ein Fehler vor­ liegt, im Interpolator eine Rückzugsbewegung ausgelöst.

Bei der Realisierung einer Steuerung, die das erfindungsgemässe Steue­ rungsprogramm abarbeitet, besteht die Möglichkeit die Steuerung als ver­ teiltes System auszugestalten, bei dem Teile der Steuerung und damit des Steuerungsprogramms an unterschiedlichen Orten von unterschiedlichen Prozessoren abgearbeitet werden. In diesem Fall ist es sinnvoll das Steue­ rungsprogramm in Prozesse zu unterteilen, wobei jedem Prozessor minde­ stens ein Prozess zum Abarbeiten zugeteilt wird. Für diesen Fall ist im Framework ein Mechanismus zur Interaktion über Prozessgrenzen hinweg vorgesehen. Durch diesen Mechanismus ist es möglich, dass Nachrichten auch zwischen Objekten unterschiedlicher Prozesse ausgetauscht werden können. Die Prozessgrenzen stellen somit keine Hindernisse für den Nach­ richtenaustausch dar.

Beispielsweise zur Fehleranalyse oder für Wartungs- oder Reparaturaufga­ ben können dann Teile des Steuerungsprogramms beim Steuerungsher­ steller in einem ersten Prozess ablaufen und mit einem Teil des Steue­ rungsprogramms beim Anwender, das als zweiter Prozess des Steuerungs­ programms abgearbeitet wird, Nachrichten über ein allgemeines Datennetz, z. B. das Internet, austauschen.

Bei verteilten Systemen ist besonders auch der im Framework enthaltene Mechanismus zur Synchronisation der Abarbeitung des Steuerungspro­ gramms mit eingehenden Nachrichten von Bedeutung, bei dem die Reihen­ folge der Bearbeitung von eingegangenen Nachrichten aus unabhängigen Kommunikationskanälen gesteuert wird. Dadurch wird sichergestellt, dass die Nachrichten bearbeitet werden, deren Daten gerade von einer Funktion benötigt werden, oder - sofern keine dringlicheren Aufgaben vorliegen - die Funktionen abgearbeitet werden, für die gerade Daten mittels einer Nach­ richt übertragen wurden. Weiterhin wird derart durch das Framework sicher­ gestellt, dass alle Nachrichten abgearbeitet werden.

Claims (12)

1. Steuerungsprogramm für eine numerische Werkzeugmaschine mit einer wiederverwendbaren Softwarestruktur, welches in ein anwendungs­ unabhängiges Framework und anwendungsspezifische Funktionen un­ terteilt wird, wobei das Framework den Teil des Programmcodes bein­ haltet, den mindestens zwei der Funktionalitätsgruppen Mensch-Ma­ schine-Interface, Geometrieverarbeitung, Interpolator, Bewegungsver­ arbeitung und speicherprogrammierbarer Steuerteil der Werkzeugma­ schine identisch aufweisen oder der in einer dieser Funktionalitätsgrup­ pen für mindestens zwei Applikationen des Steuerungsprogramms iden­ tisch ist.

2. Steuerungsprogramm nach Anspruch 1, bei dem das Framework in Form einer Klassenbibliothek (1) nach den Regeln der objektorientier­ ten Programmierung realisiert wird.

3. Steuerungsprogramm nach Anspruch 2, bei dem anwendungsspezi­ fische Funktionen in abgeleiteten Klassen (1.1-1.4) realisiert werden, die nach den Regeln der objektorientierten Programmierung von Klas­ sen (1) der Klassenbibliothek abgeleitet sind.

4. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem Funktionen in Klassen (1) definiert werden und in abgeleiteten Klassen (1.1-1.4) implementiert werden, wobei der Programmcode ei­ ner Klasse (1) für eine spezifische Funktion überladen werden kann.

5. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem das Framework (1) einen Mechanismus für die Bildung von Objek­ ten als Instanzen (1.1.1-1.4.1) abgeleiteter Klassen (1.1-1.4) bein­ haltet.

6. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem das Framework einen Mechanismus für die Interaktion zwischen Objekten (1.1.1-1.4.1) beinhaltet.

7. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem der Mechanismus zur Interaktion zwischen Objekten (1.1.1-1.4.1) den Transport von Nachrichten über Kommunikationskanäle (2.1-2.5) und das Veranlassen der Verarbeitung der jeweiligen Nachricht beim Empfänger beinhaltet.

8. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem anwendungsspezifisch festgelegt wird, welche Objekte (1.1.1-1.4.1) erzeugt werden und welche miteinander interagieren.

9. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem die Information, welche Objekte erzeugt werden und welche mit­ einander interagieren vom Benutzer eingegeben wird oder in einer ab­ geleiteten Klasse gespeichert ist oder in einer externen Datei gespei­ chert ist.

10. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, wel­ ches als verteiltes System in Form von mehreren voneinander unab­ hängigen Prozessen realisiert wird und bei dem das Framework einen Mechanismus zur Interaktion der Objekte (1.1.1-1.4.1) über Prozess­ grenzen hinweg beinhaltet.

11. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem das Framework einen Mechanismus zur Synchronisation der Abar­ beitung des Steuerprogramms mit eingehenden Nachrichten beinhaltet und das Framework die Reihenfolge der Bearbeitung von Nachrichten aus unabhängigen Kommunikationskanälen (2.1-2.5) steuert.

12. Steuerungsprogramm nach einem der vorhergehenden Ansprüche, bei dem das Framework einen Mechanismus zur Fehlerbehandlung bein­ haltet.