DE10114871A1 - Verfahren zum Betrieb einer industriellen Steuerung - Google Patents

Abstract

Es werden Mechanismen zum Betrieb einer industriellen, mit einem Runtime-System (RTS) ausgestatteten Steuerung (S), insbesondere für Produktionsmaschinen, bereitgestellt, die es einem Anwender ermöglichen, im Programmfluss auf eine beliebige Bedingung zu warten, wobei bei Erfülltsein der Bedingung der Programmfluss unmittelbar fortgesetzt wird, bei Nichterfülltsein der Bedingung der Programmfluss so lange angehalten wird, bis das Erfülltsein der Bedingung festgestellt wird, wobei beim Warten auf das Erfülltsein der Bedingung die Priorität der Bedingungsüberprüfung im Vergleich zur aktuellen Taskpriorität erhöht wird. Bei Erfülltsein der Bedingung wird eine definierte Programmsequenz bis zu einem expliziten Ende hochprior bearbeitet, wobei nach dem expliziten Ende der Programmsequenz die alte Taskpriorität wieder aufgenommen wird.

Description

Die Erfindung bezieht sich auf ein Verfahren zum Betrieb ei­ ner industriellen Steuerung, insbesondere für Produktionsma­ schinen.

Ferner bezieht sich die Erfindung auf eine industrielle Steu­ erung zur Durchführung des erfindungsgemäßen Verfahrens.

Es ist heutzutage üblich, sowohl für die speicherprogrammier­ bare Steuerung (SPS) als auch für die Bewegungssteuerung (MC) jeweils unterschiedliche hierarchische Ablaufebenen zu model­ lieren, denen Software-Tasks zur Steuerung des jeweiligen technischen Prozesses zugeordnet werden. Diese Tasks können Systemaufgaben erfüllen, sie können aber auch anwenderpro­ grammiert sein.

Aus DE 197 40 550 A1 ist es bekannt, dass Prozesssteuerungs­ funktionalitäten der speicherprogrammierbaren Steuerungen "SPS" und Bewegungsfunktionalitäten von MC-Steuerungen in ei­ nem einheitlichen konfigurierbaren Steuerungssystem integ­ riert werden können.

Diese SPS/MC-Integration geschieht in Form des Zusammenschal­ tens von SPS- und MC-Steuerungsbaugruppen. Bei einer solchen Ausführung der Integration wird aber keine optimale und effi­ ziente Taskstruktur für die Gesamtheit der Steuerungsaufgaben erreicht. Außerdem werden bei dieser Art der Integration hauptsächlich die klassischen MC-Funktionalitäten, wie sie insbesondere für Werkzeugmaschinen relevant sind, unter­ stützt. Anforderungen an die Steuerung, wie sie aus dem Be­ trieb von Produktionsmaschinen bekannt sind, werden durch diese Art des Zusammenschaltens von SPS- und MC-Steuerungs­ baugruppen nicht optimal unterstützt.

Aus EP 0 735 445 A2 ist es bekannt, zum Betrieb einer Werk­ zeugmaschine oder eines Roboters einen gesonderten Wartebe­ fehl (WAIT) zu gebrauchen. Der hier beschriebene Wartebefehl (WAIT) unterstützt aber insbesondere die Steuerung von Pro­ duktionsmaschinen noch nicht optimal.

In der Anmeldung DE 199 31 933.2 wird vorgeschlagen, den Takt des Kommunikationssystems zwischen dem PC-System und den peripheren Geräten für einen Wechsel zwischen einem Echtzeit­ betriebsprogramm und einem Nicht-Echtzeitbetriebsprogramm heranzunehmen. Hier ist es aber die Aufgabe dieser Taktab­ greifung aus dem Kommunikationssystem, in einem industriellen Prozess einen möglichst reibungslosen Wechsel zwischen Echt­ zeit- und Nicht-Echtzeitanwendungen stattfinden zu lassen. Bei dieser Ausgestaltung wird der Grundtakt aber nur aus dem Takt des Kommunikationsmediums abgeleitet und er wird nur für den Wechsel des Betriebssystemmodus eines PC-Systems verwen­ det.

Der Erfindung liegt daher die Aufgabe zugrunde, für jeweils unterschiedliche Steuerungsaufgaben und unterschiedliche Randbedingungen bzw. Anforderungen des zugrunde liegenden technischen Prozesses in einfacher Weise optimale Ausprägun­ gen einer industriellen Steuerung zu erstellen, die sowohl SPS- als auch MC-Funktionalität zur Verfügung stellt und so­ mit auch für die Steuerung von Produktionsmaschinen geeignet ist.

Diese optimalen Ausprägungen werden prinzipiell zum einen durch ein einheitliches konfigurierbares Ablaufebenenmodell für die Steuerungs-Tasks der industriellen Steuerung erreicht und zum anderen durch Mechanismen (Wait_for_Condition- Befehl), die es einem Anwender ermöglichen, im Programmfluss auf beliebige Bedingungen zu warten und höherprior zu reagie­ ren.

Von diesem Ansatz ausgehend wird die oben genannte Aufgabe dadurch gelöst, dass Mechanismen bereitgestellt sind, die es einem Anwender ermöglichen im Programmfluß auf eine beliebige Bedingung zu warten, wobei bei Erfülltsein der Bedingung der Programmfluß unmittelbar fortgesetzt wird, bei Nichterfüllt­ sein der Bedingung der Programmfluß solange angehalten wird, bis das Erfülltsein der Bedingung festgestellt wird, wobei beim Warten auf das Erfülltsein der Bedingung die Priorität der Bedingungsüberprüfung im Vergleich zur aktuellen Taskpri­ orität erhöht wird. Durch diesen Mechanismus wird es ermög­ licht, eine zusammengehörige und geschlossene Aufgabenstel­ lung in einem Stück Code eines Anwenderprogrammes auszudrü­ cken, ohne dass weitere Mechanismen wie z. B. Event-Handler erforderlich sind. Ein Anwender kann somit in einem sequen­ tiellen Programmablauf auf einer relativ niedrigen Priori­ tätsebene einer "Motion Task" durch Programmkonstrukte in seinem Programmfluß (Anwenderprogramm) das Warten auf hochpriore Ereignisse formulieren, ohne in ein anderes Pro­ gramm wechseln zu müssen. Dadurch wird einerseits in der Steuerung Verwaltungs-Overhead vermieden, was direkt die Sys­ tem-Performance erhöht und andererseits aus programmiertech­ nischer Sicht das Lokalitätsprinzip unterstützt, wodurch z. B. das Debugging erleichtert wird.

Der beschriebene Mechanismus und der dazugehörige Befehl wer­ den im weiteren als "wait_for_condition" bezeichnet.

Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfin­ dung liegt darin, dass nach dem Erfülltsein der Bedingung die folgende Programmsequenz bis zu einem expliziten Ende hoch­ prior bearbeitet wird, wobei nach dem expliziten Ende der Programmsequenz die alte Taskpriorität wieder aufgenommen wird. Dadurch wird eine hohe Deterministik in der Sequenz "Warten auf externes Ereignis" und der "Aktion, die nach die­ sem Ereignis folgt", z. B. Korrekturbewegungen bei einer Druckmarkensynchronisation, erreicht. Ein Anwender hat somit die Möglichkeit sich in seinen Programmen temporär auf eine hohe Prioritätsebene zu legen und dabei deterministische Vor­ gänge leicht und elegant beschreiben zu können. Anwendungs­ beispiele sind z. B. Druckmarkensynchronisation und schnelle Bewegungsstart (beispielsweise nach Flankenwechsel).

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass für die Formulierung der Bedingungen Prozeßsigna­ le und/oder interne Signale der Steuerung und/oder Variablen aus Anwenderprogrammen verwendet werden. Dadurch ist es dem Anwender möglich, bei der Beschreibung der Bedingungen in ei­ ner einheitlichen Weise neben Anwenderprogrammvariablen auch direkt Systemzustände und Prozeßsignale zu verwenden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Bedingungen logische und/oder arithmetische und/oder beliebige funktionelle Verknüpfungen enthalten. Da­ mit ist es dem Anwender möglich, innerhalb einer Anweisung komplexe Synchronisationsbeziehungen zu spezifizieren.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass ein Anwenderprogramm für den Betrieb der Steue­ rung mehr als einen solchen Mechanismus enthält. Dadurch wer­ den bei der Programmierung der Anwendungen die Flexibilität und die Möglichkeiten des Anwenders insbesondere hinsichtlich der Beschreibung von Synchronisationsaktivitäten erhöht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass es mehrere Anwenderprogramme beim Betrieb der Steuerung geben kann, die diese Mechanismen enthalten. Da­ durch werden bei der Programmierung der Anwendungen die Fle­ xibilität und die Möglichkeiten des Anwenders insbesondere hinsichtlich der Beschreibung von Synchronisationsaktivitäten erhöht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der jeweilige Mechanismus einem Anwender in einem Anwenderprogramm als übliches programmiersprachliches Kon­ strukt zur Verfügung steht. Der "wait_for_condition-Befehl", der diesen Mechanismus auslöst, kann somit von einem Anwender in den Anwenderprogrammen z. B. wie eine while-Schleife ver­ wendet werden, wodurch die Programmerstellung sehr erleich­ tert wird.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Runtime-System der Steuerung ein Ablaufebe­ nenmodell enthält, das mehrere Ablaufebenen unterschiedlichen Typs mit unterschiedlicher Priorität aufweist, wobei folgende Ablaufebenen vorgesehen sind:

• a) eine Ebenengruppe mit synchron getakteten Ebenen, beste­ hend aus mindestens einer Systemebene und mindestens ei­ ner Anwenderebene, wobei die Ebenen dieser Ebenengruppe untereinander eine Priorisierung aufweisen können,
• b) einer Anwenderebene für Systemexceptions
• c) einer zeitgesteuerten Anwenderebene
• d) einer ereignisgesteuerten Anwenderebene
• e) einer sequentiellen Anwenderebene
• f) einer zyklischen Anwenderebene,

wobei Anwenderebenen der Ebenengruppe a) optional synchron zu einer der Systemebenen der Ebenengruppe a) laufen können. Ein wesentlicher Vorteil dieser Schichtung liegt darin, dass die Kommunikation zwischen den Tasks der Prozesssteuerung (SPS) und denen der Bewegungssteuerung (MC) minimiert wird. Ein weiterer Vorteil liegt darin, dass die Programmierung der Steuerungsaufgaben für die Prozesssteuerung und für die Bewe­ gungssteuerung in einer einheitlichen Programmiersprache mit einer einheitlichen Erstelloberfläche erfolgen kann und dass der Anwender ein für seine jeweiligen Anforderungen zuge­ schnittenes Ablaufebenenmodell flexibel erstellen kann.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Grundtakt des Ablaufebenenmodells aus einem internen Timer oder aus einem internen Takt eines Kommunika­ tionsmediums oder aus einem externen Gerät oder von einer Größe, die zum technologischen Prozeß gehört abgeleitet wird. Dadurch kann sehr flexibel und sehr einfach der Grundtakt für das Ablaufebenenmodell abgeleitet werden. Dadurch, dass der Grundtakt für das Ablaufebenenmodell auch von einer Größe, die zum technologischen Prozess gehört, ableitbar ist, kann auf eine sehr einfache Weise eine direkte Rückkopplung aus dem technologischen Prozess zur Steuerung erhalten werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die zeitgesteuerte Anwenderebene, die ereignisge­ steuerte Anwenderebene, die sequentielle Ablaufebene, die zyklische Hintergrundebene und die Anwenderebene für System­ exceptions optional sind. Der Anwender kann sich dadurch sehr flexibel eine Steuerung erstellen, die für seine konkreten vorliegenden Anforderungen sehr effizient ist und die die ge­ rade benötigten Ablaufebenen enthält und somit keinen unnöti­ gen Overhead beinhaltet.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die synchronen Ebenen zum Grundtakt übersetzt und/oder untersetzt und/oder im Verhältnis 1 : 1 getaktet sind. Dadurch können die Ebenen jeweils sehr leicht zu einem Viel­ fachen des Grundtaktes getaktet werden oder aber auch jeweils zu einem reziproken Vielfachen getaktet werden. Ausgehend von einer gemeinsamen Ausgangsgröße können somit sehr einfach Übersetzungen, aber auch Untersetzungen für die jeweiligen Ebenen erreicht werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass weitere priorisierende Schichtungen innerhalb der Ablaufebenen vorgesehen sind. Die Softwarestruktur der indus­ triellen Steuerung lässt sich dadurch optimal an die unter­ schiedlichen Steuerungsaufgaben bzw. an die Anforderungen des zugrunde liegenden technischen Prozesses anpassen. Somit las­ sen sich z. B. unterschiedliche Fehlerursachen unterschiedli­ chen Ebenen mit z. B. aufsteigender Priorität zuordnen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass optional Anwendertasks beim Systemhochlauf und/oder beim Systemrunterfahren durchlaufbar sind. Dadurch können beim Systemhochlauf z. B. Initialisierungsfunktionen angestoßen werden oder beim Systemrunterfahren wird sicherge­ stellt, dass die im System vorhandenen Achsen eine definierte Position einnehmen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in die Anwenderebenen Anwenderprogramme ladbar sind, die je nach Typ der Anwenderebene zyklusorientiert oder sequentiell programmiert sind. Dadurch kann der Anwender in seinen Anwenderprogrammen die Funktionalität der Steuerung sehr flexibel an die zugrunde liegenden Anforderungen des technischen Prozesses anpassen und er kann auch die Anwender­ programme in unterschiedliche Anwenderebenen laden, um da­ durch eine für seine jeweiligen Applikationen effektive Aus­ prägung der Steuerung zu erreichen. Ein weiterer Vorteil liegt darin, dass der Anwender in ein einheitliches Ablauf­ ebenenmodell bzw. Runtime-System einer industriellen Steue­ rung sowohl zyklusorientierte Anwenderprogramme als auch er­ eignisorientierte Anwenderprogramme laden kann. Ein Anwender kann somit nach unterschiedlichen Paradigmen programmierte Programme (zyklusorientiert für SPS-Funktionalität und ereig­ nisorientiert bzw. sequentiell für Bewegungsfunktionalität) sehr flexibel und konform in die Anwenderebenen des Ablauf­ ebenenmodells hinzuladen.

Ein Ausführungsbeispiel der Erfindung ist in der Zeichnung dargestellt und wird im folgenden erläutert.

Dabei zeigen:

Fig. 1 die wesentlichen Ablaufebenen einer klassischen speicherprogrammierbaren Steuerung,

Fig. 2 die wesentlichen Ablaufebenen einer Bewegungssteue­ rung,

Fig. 3 schematische Darstellung einer industriellen Steue­ rung,

Fig. 4 das Ablaufebenenmodell der erfindungsgemäßen indus­ triellen Steuerung,

Fig. 5 ein Ausführungsbeispiel für das Zuladen von Anwen­ derprogrammen in die Anwenderebenen,

Fig. 6 ein Ausführungsbeispiel für den Gebrauch und den Mechanismus des Wait_for_Condition-Befehls, im Ab­ laufebenenmodell der erfindungsgemäßen industriel­ len Steuerung,

Fig. 7 ein weiteres Ausführungsbeispiel für den Gebrauch und den Mechanismus des Wait_for_Condition-Befehls, im Ablaufebenenmodell der erfindungsgemäßen indus­ triellen Steuerung,

Fig. 8 die syntaktische Beschreibung des Wait_for_Condition-Befehls in einem Syntaxdiagramm,

Fig. 9 ein Beispiel für die Formulierung einer Expression in programmiersprachlicher Notation und

Fig. 10 in einer Schemadarstellung Möglichkeiten, wie der Grundtakt für die industrielle Steuerung gewonnen wird.

In der Darstellung gemäß Fig. 1 sind die wesentlichen Ablauf­ ebenen einer klassischen speicherprogrammierbaren Steuerung (SPS), angeordnet nach ihrer Priorität, gezeigt. Der Priori­ tätsanstieg ist dabei durch einen Pfeil symbolisiert. In der niederpriorsten Ebene werden, wie durch eine gestrichelte Li­ nie angedeutet, zwei unterschiedliche Aufgaben, nämlich ein freier Zyklus, d. h. "Anwenderebene freier Zyklus" und eine Hintergrund-Systemebene, d. h. "Systemebene Hintergrund" abge­ wickelt. Der Hintergrund-Systemebene sind z. B. Kommunikati­ onsaufgaben zugeordnet. Bei einer folgenden Anwenderebene, bezeichnet als "Anwenderebene zeitgesteuert", ist der Aufruf­ takt der Tasks bzw. der Programme dieser Ebene parametrier­ bar. Es erfolgt eine Überwachung dahingehend, ob die Bearbei­ tung eines Anwenderprogrammes dieser getakteten Ebene recht­ zeitig abgeschlossen ist, bevor das Startereignis erneut auf­ tritt. Läuft die Taktzeit ab, ohne dass das Anwenderprograrnm der zugeordneten Ebene fertig abgearbeitet ist, wird eine entsprechende Task einer prioritätsmäßig übernächsten "Anwen­ derebene für asynchrone Fehler" gestartet. In dieser "Anwen­ derebene für asynchrone Fehler" kann der Anwender die Behand­ lung von Fehlerzuständen ausprogrammieren.

Auf die "Anwenderebene zeitgesteuert" folgt eine "Anwender­ ebene Events". Die Reaktion auf externe oder interne Ereig­ nisse (Events) erfolgt innerhalb der "Anwenderebene Events". Ein typisches Beispiel für ein solches Ereignis ist das Schalten eines binären bzw. digitalen Eingangs, wodurch typi­ scherweise ein Ereignis ausgelöst wird. In einer "Systemebene hochprior" liegen die Aufgaben des Betriebssystems, welche die Arbeitsweise der programmierbaren Steuerung (SPS) sicher­ stellen.

Die Darstellung gemäß Fig. 2 zeigt die wesentlichen Ablaufebe­ nen einer Bewegungssteuerung (MC). Auch hierbei sind die ein­ zelnen Ebenen nach ihrer Priorität hierarchisch, wie durch einen Pfeil symbolisiert, angeordnet. Eine "Systemebene Hin­ tergrund" und eine "Anwenderebene sequentiell" haben eine gleiche Priorität, nämlich die niedrigste. Diese aufgabenmä­ ßige Zugehörigkeit ist wie bei Fig. 1 durch eine gestrichelte Linie symbolisiert. Die Tasks der "Anwenderebene sequentiell" werden zusammen mit den Tasks der "Systemebene Hintergrund" im Round-Robin-Verfahren abgearbeitet. Typische Tasks der "Systemebene Hintergrund" sind z. B. solche für Kommunika­ tionsaufgaben. In der "Anwenderebene sequentiell" laufen die vom Anwender programmierten Programmteile für die eigentliche Steuerungsaufgabe. Stößt die Steuerung in einem dieser Pro­ grammteile auf einen Bewegungs- oder Positionierbefehl, wird ein "Suspend" gesetzt, d. h. das Anwenderprogramm wird an die­ ser Stelle unterbrochen. In diesem Fall wird ein Befehl syn­ chron genutzt. Die Abarbeitung dieses Bewegungs- oder Positi­ onierbefehls geschieht in einer höchstprioren "Systemebene getaktet". Ein jeder Lageregler oder Interpolator, der in der "Systemebene getaktet" abläuft, führt diesen Bewegungs- bzw. Positionierbefehl aus. Nach Ausführung des Befehls wird in die "Anwenderebene sequentiell" zurückgesprungen und das durch "Suspend" unterbrochene Anwenderprogramm wird durch ein "Resume" an der gleichen Stelle fortgesetzt. Die "Systemebene getaktet" enthält neben den schon erwähnten Lagereglern auch den Interpolationsteil der Steuerung.

Auf die niederpriorste Ebene setzt die "Anwenderebene Events" auf. Hier sind solche Tasks untergebracht, die auf externe oder interne Ereignisse reagieren. Solche Ereignisse können beispielsweise Alarme sein.

In einer folgenden "Anwenderebene synchrongetaktet" laufen synchron getaktete Anwender-Tasks ab, z. B. Reglerfunktionali­ täten. Diese Tasks sind synchronisiert zu getakteten System­ funktionen wie zum Beispiel Interpolator, Lageregler oder zyklische Buskommunikation.

In der Darstellung gemäß Fig. 3 wird in Form eines Struktur­ bildes gezeigt, dass die Steuerung eines technischen Prozes­ ses P1 über das Runtime-System RTS einer industriellen Steue­ rung erfolgt. Die Verbindung zwischen dem Runtime-System RTS der Steuerung und dem technischen Prozess P1 geschieht bidi­ rektional über die Ein-/Ausgänge EA. Die Programmierung der Steuerung und damit das Festlegen des Verhaltens des Runtime- Systems RTS geschieht im Engineering-System Es. Das Enginee­ ring-System ES enthält Werkzeuge für die Konfigurierung, Pro­ jektierung und Programmierung für Maschinen bzw. für die Steuerung technischer Prozesse. Die im Engineering-System er­ stellten Programme werden über den Informationspfad I in das Runtime-System RTS der Steuerung übertragen. Bezüglich seiner Hardware-Ausstattung besteht ein Engineering-System ES übli­ cherweise aus einem Computersystem mit Graphikbildschirm (z. B. Display), Eingabehilfsmitteln (z. B. Tastatur und Maus), Prozessor, Arbeits- und Sekundärspeicher, einer Einrichtung für die Aufnahme computerlesbarer Medien (z. B. Disketten, CDs) sowie Anschlusseinheiten für einen Datenaustausch mit anderen Systemen (z. B. weiteren Computersystemen, Steuerungen für technische Prozesse) oder Medien (z. B. Internet). Eine Steuerung besteht üblicherweise aus Eingabe- und Ausgabeein­ heiten, sowie aus Prozessor und Programmspeicher. Es ist auch vorstellbar, dass die Steuerung eines technischen Prozesses P1 über mehrere Runtime-Systeme RTS von industriellen Steue­ rungen erfolgt.

Die Darstellung gemäß Fig. 4 zeigt das Ablaufebenenmodell der industriellen Steuerung. Die Priorisierung der Ebenen wird durch einen Pfeil in Richtung zur höchsten Priorität angedeu­ tet. Die niederpriorsten Ebenen sind die "zyklische Anwender­ ebene" und die "sequentielle Anwenderebene". Diese beiden Ebenen laufen mit der gleichen Priorität. Deshalb sind diese Ebenen in der Darstellung gemäß Fig. 4 durch eine gestrichelte Linie getrennt. Die "zyklische Anwenderebene" beinhaltet die "Background Task", die zykluszeitüberwacht ist. In der "se­ quentiellen Anwenderebene" werden die "Motion Tasks" durch­ laufen. "Motion Tasks" sind nicht zykluszeitüberwacht und dienen im Wesentlichen zur Beschreibung sequentieller Abläu­ fe. "Motion Tasks" werden quasiparallel abgearbeitet. Gene­ rell enthalten alle Anwenderebenen eine oder mehrere Tasks. Die Tasks nehmen die Anwenderprogramme auf. Die Tasks der "zyklische Anwenderebene" und der "sequentiellen Anwenderebe­ ne" werden in einem gemeinsamen Round-Robin-Zyklus abgearbei­ tet.

Die nächstfolgende Ebene ist die "zeitgesteuerte Anwenderebe­ ne". Die Tasks dieser Ebene werden zeitgesteuert aktiviert. Die Zeitsteuerung ist einer Granularität von Millisekunden einstellbar. Auf die "zeitgesteuerte Anwenderebene" folgt die "ereignisgesteuerte Anwenderebene". In dieser Ebene werden nach Erkennen eines User Interrupts so genannte "User Inter­ rupt Tasks" aktiviert. User Interrupt Ereignisse können als logische Verknüpfung von Prozessereignissen und/oder internen Zuständen formuliert werden.

Die nächsthöhere Ebene ist die "Anwenderebene für System Ex­ ceptions". In dieser "Anwenderebene für System Exceptions" werden System Interrupts überwacht, bei deren Eintreffen so genannte "Exceptions", d. h. Ausnahmefallbehand­ lungen, generiert werden. In der "Anwenderebene für System Exceptions" gibt es z. B. folgende Tasks, die bei Auftreten eines entsprechenden System Interrupts aktiviert werden:

• a) "Time Fault Task", die beim Ansprechen von Zeitüberwachun­ gen aktiviert wird,
• b) "Peripheral Fault Task", die z. B. bei Prozess- und Diagno­ sealarmen aktiviert wird, aber auch bei Stationsausfall o­ der Stationswiederkehr,
• c) "System Fault Task", die bei allgemeinen Systemfehlern ak­ tiviert wird,
• d) "Program Fault Task", die bei Programmierfehlern (z. B. Di­ vision durch Null) aktiviert wird,
• e) "Time Fault Background Task", die beim Ansprechen der Zyk­ luszeitüberwachung der Background Task aktiviert wird und
• f) "Technological Fault Task", die bei Technologiefehlern ak­ tiviert wird.

Als nächstes folgt die Ebenengruppe "synchron getaktete Ebe­ nen". Diese Ebenengruppe besitzt die höchste Priorität im Ab­ laufebenenmodell. Die einzelnen Ebenen dieser Ebenengruppe können untereinander weitere Priorisierungen aufweisen. Die Ebenengruppe "synchron getaktete Ebenen" besteht aus mindes­ tens einer Systemebene und mindestens einer Anwenderebene. Die Systemebenen beinhalten die Systemfunktionen wie z. B. La­ geregler oder Interpolator. In die Anwenderebenen dieser Ebe­ nengruppe können von einem Anwender flexibel Anwenderprogram­ me (AP1-AP4; Fig. 5) zugeladen werden.

Für die Taktung der "synchron getakteten Ebenen" gibt es eine Reihe unterschiedlicher Taktgenerierungsmöglichkeiten. Der Grundtakt kann z. B. aus einem internen Timer (T1; Fig. 10) kommen oder aus einem internen Takt (T3; Fig. 10) eines Kommu­ nikationsmediums (z. B. Profibus) oder aber der Takt kann auch aus einem Prozessereignis des technologischen Prozesses abge­ leitet werden. Ein solches Prozessereignis kann z. B. die Taktrate (TG; Fig. 10) eines Vorgangs an einer Produktionsma­ schine oder Verpackungsmaschine sein. Anwenderebenen der Ebe­ nengruppe "synchron getaktete Ebenen" können dabei basierend auf dem Grundtakt getaktet werden, sie können aber auch syn­ chron zu einer der Systemebenen der Ebenengruppe "synchron getaktete Ebenen" laufen. Die Anwendertasks dieser zu einer Systemebene synchronen Anwenderebene haben somit eine syn­ chrone, d. h. deterministische Beziehung zu einer vom Anwender flexibel festlegbaren Systemebene. Das hat den Vorteil, dass deterministische Reaktionen auf Systemtasks (Systemtasks lau­ fen in den Systemebenen), die der Anwender in seinen Anwen­ dertasks programmiert hat, die in den Anwenderebenen der Ebe­ nengruppe "synchron getaktete Ebenen" laufen, vom System ga­ rantiert werden. Das heißt z. B., dass das System garantiert, dass diese "synchrone Anwenderebene" entsprechend beispiel­ haft vor dem Interpolator aktiviert wird oder aber auch vor einer beliebigen anderen Systemfunktion.

Die "zeitgesteuerte Anwenderebene", die "ereignisgesteuerte Anwenderebene", die "sequentielle Anwenderebene"; die "zykli­ sche Anwenderebene" sowie die "Anwenderebene für System Ex­ ceptions" sind optional.

Die Task der "zyklischen Anwenderebene" (Background Task) ist zykluszeitüberwacht. Die "Motion Tasks" dagegen sind nicht zykluszeitüberwacht und dienen im wesentlichen zur Beschrei­ bung sequentieller Abläufe. Das heißt, das vorliegende Ab­ laufebenenmodell unterstützt einen Anwender sowohl bei der Programmierung von sequentiellen Abläufen als auch bei der Ereignisprogrammierung. Es können somit synchrone Ereignisse als auch asynchrone Ereignisse durch die Programmierung er­ fasst werden. In die Anwenderebenen sind die vom Anwender er­ stellten Anwenderprogramme (AP1 - AP4; Fig. 5) zuladbar. Die Anwenderprogramme AP1 bis AP4 werden üblicherweise mit Hilfe einer Programmierumgebung des Engineering-Systems (ES; Fig. 3) erstellt.

Die Darstellung gemäß Fig. 5 zeigt ein Ausführungsbeispiel für das Zuladen von Anwenderprogramm in die Anwenderebenen. Fig. 5 zeigt exemplarisch eine Ausprägung von Anwenderebenen des Ab­ laufebenenmodells. Durch die drei Punkte am unteren Rand der Zeichnung ist dargestellt, dass auch noch weitere Anwender­ ebenen, aber auch Systemebenen vorhanden sein können. Die Priorisierung der Ebenen wird wie im Vorangegangenen durch einen Pfeil in Richtung zur höchsten Priorität angedeutet. Den Anwenderebenen werden die Anwenderprogramme AP1 bis AP4, am rechten Bildrand durch kleine Rechtecke angedeutet, zuge­ ordnet. Die Zuordnung wird dargestellt durch Zuordnungspfeile ZP1 bis ZP4. In den Anwenderebenen befinden sich Tasks, die die zugeladenen Anwenderprogramme AP1 bis AP4 aufnehmen. Die­ se Tasks werden dann nach einer gewissen Strategie (z. B. se­ quentiell) durchlaufen bzw. abgearbeitet. Sie können weiter­ hin die Eigenschaft besitzen, dass sie laufzeitüberwacht sind.

Die Darstellung gemäß Fig. 6 zeigt ein Ausführungsbeispiel für den Gebrauch und den Mechanismus des Wait_for_Condition- Befehls, im Ablaufebenenmodell der erfindungsgemäßen indus­ triellen Steuerung. Der Wait_for_Condition-Befehl (in Fig. 6 dargestellt als wait_for_cond()) wird in dieser Darstellung exemplarisch in der "sequentiellen Anwenderebene" verwendet. Der Wait_for_Condition-Befehl wird in den vom Anwender er­ stellten "Motion Tasks" MT1 und MT2 verwendet, die Bestand­ teil der "sequentiellen Anwenderebene" sind. Die "Motion Tasks" MT1 und MT2 hängen in einem Round-Robin-Zyklus, darge­ stellt durch den Pfeil von MT1 nach MT2 und durch den abge­ winkelten Pfeil von MT2 zu MT1. Die drei Punkte innerhalb dieses Pfeiles deuten an, dass noch weitere "Motion Tasks" im Round-Robin-Zyklus hängen können. Die "Motion Task" MT1 ent­ hält den Wait_for_Condition-Befehl "wait_for_cond(cond_1)", die "Motion Task" MT2 den Wait_for-Condition-Befehl "wait_for_cond(cond_2)". Jeweils drei Punkte, die innerhalb von MT1 bzw. MT2 verwendet werden, deuten an, dass neben den beiden Wait_for_Condition-Befehlen und den drei Positionier­ befehlen pos1( ) bis pos3( ) noch weitere Befehle in den "Moti­ on Tasks" enthalten sein können.

Insgesamt besteht das in Fig. 6 exemplarisch dargestellte Ab­ laufebenenmodell eines Runtime-Systems für eine industrielle Steuerung aus folgenden Ebenen (aufgezählt von niedrigster bis höchster Priorität): "zyklische Anwenderebene", "sequen­ tielle Anwenderebene" (die Tasks dieser beiden Ebenen haben die gleiche Priorität, dargestellt durch die gestrichelte Li­ nie zwischen diesen Ebenen), "zeitgesteuerte Anwenderebene", "ereignisgesteuerte Anwenderebene", "Anwenderebene für Syste­ mexceptions", "synchron getaktete Anwenderebene 2", "syn­ chron getaktete Anwenderebene 1", "synchron getaktete System­ ebene 2" und als höchstpriore Ebene eine "synchron getaktete Systemebene 1".

Die Arbeitsweise des Wait_for_Condition-Befehls wird bei­ spielhaft an "wait_for_ond(cond_3)" aus der "Motion Task" MT2 gezeigt. Ist die "Motion Task" MT1 im Round-Robin-Zyklus an der Reihe, werden die Befehle der "Motion Task" MT1 solan­ ge bedient, bis die Zeitscheibe abgelaufen ist, oder eine Un­ terbrechung kommt. Trifft dies zu, wird die "Motion Task" MT2 als nächste Task im Zyklus bedient, usw. Wird in der "Motion Task" MT1 der wait_for_cond(cond_1)-Befehl abgearbeitet, wird die Bedingung cond_1 überprüft. Ist cond_1 = true, also er­ füllt, dann wird sofort der nächstfolgende Befehl pos2( ) aus­ geführt und eventuell weitere in MT1 vorhandene Befehle suk­ zessive abgearbeitet, bis die Kontrolle an die nächste Task abgegeben wird.

Ist die Bedingung cond_1 = false, also nicht erfüllt, wird sofort die "Motion Task" MT1 unterbrochen und im Round-Robin- Zyklus wird MT2 bedient. Die Bedingung cond_1 wird aber in die "synchron getaktete Systemebene 2" eingehängt (angedeutet durch den durchgehenden abgewinkelten Pfeil vom wait_for_cond(cond_1)-Befehl zu der "synchron getakteten Sys­ temebene 2") und im Takt dieser Systemebene auf ihr Erfüllt­ sein überprüft. Ist die Bedingung cond 1 erfüllt, wird im Round-Robin-Zyklus die aktuelle Task verdrängt, d. h. ihr wird die Zeitscheibe entzogen und die Motion Task MT1 wird sofort unmittelbar nach dem wait_for_cond(cond_1) mit dem Positio­ nierbefehl pos2( ) fortgesetzt. Durch den gestrichelten Pfeil wird der Rücksprung aus der "synchron getakteten Systemebene 2" zum Positionierbefehl pos2( ), d. h. zur "sequentiellen An­ wenderebene" angedeutet.

Dadurch, dass bei Nichterfülltsein der Bedingung des Wait_for_Condition-Befehls die Überprüfung der Bedingung in einer hochprioren "synchron getakteten Systemebene" stattfin­ det, und bei Erfülltsein der Bedingung sofort die unterbro­ chene "Motion Task" fortgesetzt wird, ist es einem Anwender möglich, bei der Programmierung von Bewegungssequenzen extrem zeitkritische Applikationen mit einfachen Sprachmitteln zu spezifizieren. Die Performance und Deterministik wird noch dadurch erhöht, dass beim Überprüfen der Bedingungen in den jeweiligen hochprioren "synchron getakteten Systemebenen" nur aktuell anstehende Bedingungen eingehängt und berücksichtigt werden.

Der hier beschriebene Mechanismus erfordert auch keinen ex­ pliziten Event-Handler. Der große Vorteil aus Anwendersicht liegt somit darin, dass der Anwender jetzt in einem sequen­ tiellen Ablaufprogramm auf einer relativ niedrigen Priori­ tätsebene einer "Motion Task" in seinem Programmfluss hochpriore Ereignisse mit Hilfe von Programmkonstrukten for­ mulieren kann und nicht in ein anderes Programm wechseln muss, das er dann über andere Mechanismen (z. B. per Hand oder interruptgesteuert) auf synchrone Anwendertask abbilden muss, sondern er hat die Möglichkeit, in einem geschlossenen Anwen­ derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" und "hochpriore Reaktion" auf dieses Ereignis in einem Pro­ gramm geschlossen zu formulieren.

Die Bedingungen, die in einem Wait_for_Condition-Befehl abge­ fragt werden, können vom Anwender sehr flexibel und elegant formuliert werden. So kann der Anwender zur Formulierung die­ ser Bedingungen Programmvariablen aus einem Anwenderprogramm verwenden oder interne Größen der Steuerung oder er kann auch Prozesssignale referenzieren. Diese Größen können dann lo­ gisch, arithmetisch oder mit beliebigen Funktionen inhaltlich verknüpft werden, um daraus eine Bedingung zu formulieren. Neben dem hochprioren Abfragen, ob die Bedingung erfüllt ist, kann man sich auch vorstellen, dass bei Erfülltsein der Be­ dingung auch noch dazugehöriger Programmcode, d. h. eine da­ hinterliegende Reaktion, die anwenderprogrammierbar ist, hochprior ausgeführt wird. Und dass erst nach der Ausführung dieses Programmcodes der Rücksprung in die niederpriore Ebene erfolgt.

Die Darstellung gemäß Fig. 7 zeigt ein erweitertes Ausfüh­ rungsbeispiel für den Gebrauch und den Mechanismus des Wait_for_Condition-Befehls, im Ablaufebenenmodell der erfin­ dungsgemäßen industriellen Steuerung. Der Wait_for_Condition- Befehl (in Fig. 7 ebenfalls dargestellt als wait_for_cond()) wird in dieser Darstellung exemplarisch in der "sequentiellen Anwenderebene" verwendet. Der Wait_for_Condition-Befehl wird in den vom Anwender erstellten "Motion Tasks" MT3 und MT4 verwendet, die Bestandteil der "sequentiellen Anwenderebene" sind. Die "Motion Tasks" MT3 und MT4 hängen in einem Round- Robin-Zyklus, dargestellt durch den Pfeil von MT3 nach MT4 und durch den abgewinkelten Pfeil von MT4 zu MT3. Die drei Punkte innerhalb dieses Pfeiles deuten an, dass noch weitere "Motion Tasks" im Round-Robin-Zyklus hängen können. Die "Mo­ tion Task" MT3 enthält den Wait_for_Condition-Befehl "wait_for_cond(cond_3)", die "Motion Task" MT4 den Wait_for- Condition-Befehl "wait_for_cond(cond_4)". Jeweils drei Punk­ te, die innerhalb von MT3 bzw. MT4 verwendet werden, deuten an, dass neben den beiden Wait_for_Condition-Befehlen und den Positionierbefehlen pos4( ) bis pos8( ) noch weitere Befehle in den "Motion Tasks" enthalten sein können. Durch die program­ miersprachlichen Konstrukte "wait_for_cond( )" und "end_wait_for_cond" wird eine Programmsequenz in den "Motion Tasks" geklammert. In der "Motion Task" MT3 sind die Befehle pos5( ) und pos6( ) auf diese Weise geklammert. Auch in der "Motion Task" MT4 wird die Verwendung von "wait_for_cond( )" und "end_wait_for_cond" angedeutet. Durch jeweils 3 Punkte ist in der "Motion Task" MT4 skizziert, dass vor, innerhalb und nach dem "wait_for_cond( ) - end_wait_for_cond"-Konstrukt weitere Anweisungen vorhanden sein können.

Das in Fig. 7 exemplarisch dargestellte Ablaufebenenmodell ei­ nes Runtime-Systems für eine industrielle Steuerung besteht wie in Fig. 6 aus folgenden Ebenen (aufgezählt von niedrigster bis höchster Priorität): "zyklische Hintergrundebene", "se­ quentielle Anwenderebene" (die Tasks dieser beiden Ebenen ha­ ben die gleiche Priorität, dargestellt durch die gestrichelte Linie zwischen diesen Ebenen), "ereignisgesteuerte Anwender­ ebene", "zeitgesteuerte Anwenderebene", "Anwenderebene für Systemexceptions", "synchron getaktete Anwenderebene 2", "synchron getaktete Anwenderebene 1", "synchron getaktete Systemebene 2" und als höchstpriore Ebene eine "synchron ge­ taktete Systemebene 1".

In Fig. 7 wird die Arbeitsweise des Wait_for_Condition-Befehls mit einer dazugehörigen Programmsequenz gezeigt beispielhaft an "wait_for_cond(cond_3)" aus der "Motion Task" MT3 gezeigt. Das Überprüfen der Bedingung cond_3 und das Abarbeiten der dazugehörigen Programmsequenz (geklammert zwischen "wait_for_cond(cond_3)" und "end_wait_for_cond") erfolgen da­ bei auf einer höherprioren Ebene des Ablaufebenenmodells. Die zu "wait_fo_cond(cond_3)" dazugehörigen Programmsequenz wird durch die Abfolge der Befehle pos5( ) und pos6( ) gebildet.

Ist die "Motion Task" MT3 im Round-Robin-Zyklus an der Reihe, werden die Befehle der "Motion Task" MT3 solange bedient, bis die Zeitscheibe abgelaufen ist, oder eine Unterbrechung kommt. Trifft dies zu, wird die "Motion Task" MT4 als nächste Task im Zyklus bedient, usw. Wird in der "Motion Task" MT3 der "wait_for_cond(cond_3)"-Befehl abgearbeitet, so wird die Bedingung cond_2 überprüft. Ist cond_3 = true, also erfüllt, dann wird der normale programmablauf fortgesetzt, d. h. als nächstes wird der Befehl pos5( ) ausgeführt und eventuell wei­ tere in MT3 vorhandene Befehle sukzessive abgearbeitet, bis die Kontrolle an die nächste Motion Task abgegeben wird.

Ist die Bedingung cond_3 = false, also nicht erfüllt, wird sofort die "Motion Task" MT3 unterbrochen und im Round-Robin- Zyklus wird MT4 bedient. Die Bedingung cond_3 und die Befehle pos5( ) und pos6( ) (als dazugehörige Programmsequenz) werden in der Priorität der "synchron getakteten Systemebene 2" be­ arbeitet (angedeutet durch den durchgehenden abgewinkelten Pfeil, ausgehend von der Klammer, die die Zusammengehörigkeit von wait_for_cond(cond_3), end_wait_for_cond und dazugehöri­ ger Programmsequenz ausdrückt, hin zu der "synchron getakte­ ten Systemebene 2"). Im Takt dieser Systemebene wird cond_3 auf ihr Erfülltsein überprüft. Ist die Bedingung cond_3 er­ füllt, wird mit der Priorität der "synchron getakteten Sys­ temebene 2" die dazugehörige Programmsequenz (hier: die Ab­ folge der Befehle pos5( ) und pos6( ) abgearbeitet. Durch den gestrichelten Pfeil wird der Rücksprung aus der "synchron ge­ takteten Systemebene 2" zum Positionierbefehl pos7( ), d. h. zur "sequentiellen Anwenderebene" angedeutet.

Dadurch, dass bei Nichterfülltsein der Bedingung des Wait_for_Condition-Befehls die Überprüfung der Bedingung in einer hochprioren "synchron getakteten Systemebene" stattfin­ det, und bei Erfülltsein der Bedingung sofort eine dazugehö­ rige, vom Anwender erstellbare Programmsequenz auf dieser hochprioren Systemebene ausgeführt wird, können sogar extrem zeitkritische Applikationen mit einfachen Sprachmitteln spe­ zifiziert und durchgeführt werden.

Ein möglicher Anwendungsfall ist die Druckmarkensynchronisa­ tion. Dabei geht es darum, eine Druckmarke auf einem Material hochprior zu erkennen. Beim Erkennen dieser Druckmarke wird typischerweise ein Istwert erfasst ("Latchen" z. B. eines La­ ge- oder Geberistwertes). Ausgehend von diesem erfassten Ist­ wert wird ein Korrekturwert berechnet, der dem System als ü­ berlagerte Bewegung aufgeprägt wird. Der Vorgang Istwert- Erkennung, Korrekturwert-Berechnung und Durchführung der ü­ berlagerten Bewegung muß in einer deterministischen Zeitdauer erfolgen. Deswegen muß dieser Vorgang hochprior stattfinden.

Ein weiterer Anwendungsfall ist der "schnelle Bewegungs­ start". Hier geht es darum, z. B. Flankenwechsel sehr schnell zu erkennen und daran sofort anschließend einen Bewegungs­ start (z. B. Positionierbewegung) zu beginnen. Die Determinis­ tik Erkennen eines Ereignisses und Auslösen von Folgeaktionen ist entscheidend für die Produktivität einer Maschine. Bei Produktionsmaschinen müssen solche zyklischen Vorgänge in ei­ ner deterministischen Zeit, z. B. <100 ms oder <50 ms erfol­ gen. Beim Abarbeiten der Tasks auf einer normalen Hinter­ grundebene kann diese Deterministik nicht garantiert werden. Der beschriebene Mechanismus ist besonders für einen Einsatz bei Maschinen geeignet, die periodische Maschinenzyklen auf­ weisen.

Die Performance wird noch dadurch erhöht, dass beim Überprü­ fen der Bedingungen in den jeweiligen hochprioren "synchron getakteten Systemebenen" nur aktuell anstehende Bedingungen eingehängt und berücksichtigt werden.

Der hier beschriebene Mechanismus erfordert, wie schon in Fig. 6 erwähnt, keinen expliziten Event-Handler. Der große Vorteil aus Anwendersicht liegt somit darin, dass der Anwender jetzt in einem seguentiellen Ablaufprogramm auf einer relativ nied­ rigen Prioritätsebene einer "Motion Task" in seinem Programm­ fluss hochpriore Ereignisse mit Hilfe von Programmkonstrukten formulieren kann und nicht in ein anderes Programm wechseln muss, das er dann über andere Mechanismen (z. B. per Hand oder interruptgesteuert) auf synchrone Anwendertask abbilden muss, sondern er hat die Möglichkeit, in einem geschlossenen Anwen­ derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" und "hochpriore Reaktion" auf dieses Ereignis in einem Pro­ gramm geschlossen zu formulieren.

Der Wait_for_Condition-Befehl kann vorn Anwender sehr flexibel und einfach eingesetzt werden, da er als normales program­ miersprachliches Konstrukt zur Verfügung steht. Auch die For­ mulierung der Bedingungen ist für einen Anwender flexibel und einfach. So kann der Anwender zur Formulierung dieser Bedin­ gungen Programmvariablen aus einem Anwenderprogramm verwenden oder interne Größen der Steuerung oder er kann auch Prozess­ signale referenzieren. Diese Größen können dann logisch, arithmetisch oder mit beliebigen Funktionen inhaltlich ver­ knüpft werden, um daraus eine Bedingung zu formulieren.

Durch das Wait_for_Condition-Konstrukt hat ein Anwender die Möglichkeit in normalen Anwenderprogrammen für Bewegungsse­ quenzen, ein Anwenderprogramm temporär auf eine höhere Prio­ ritätsebene zu legen, uni deterministische Vorgänge garantie­ ren zu können.

Darstellung gemäß Fig. 8 zeigt das programmiersprachliche Kon­ strukt des wait_for_condition-Mechanismus als Syntaxdiagramm. Die terminalen Elemente sind dabei mit abgerundeten Ecken dargestellt: "WAITFORCONDITION", "WITH", "DO", "END_WAITFORCONDITION" und ";". Als Rechtecke sind die nicht­ terminalen Elemente dargestellt: "Expressions-Bezeichnung, "SCHALTER" und "ANWEISUNGSTEIL". Die Elemente "WITH" und "SCHALTER" sind optional.

Darstellung gemäß Fig. 9 zeigt die Verwendung des Wait_for_Condition-Konstruktes in einem Programmablauf. Im oberen Teil von Fig. 9 ist die Formulierung der Bedingung "my- Expression" dargestellt, im unteren Teil ist gargestellt, wie diese Bedingung in einem Wait_for_Condition-Konstrukt verwen­ det wird.

Darstellung gemäß Fig. 10 zeigt in einer Schemadarstellung Möglichkeiten, wie der Grundtakt für die industrielle Steue­ rung gewonnen wird. Fig. 10 zeigt exemplarisch eine Kommunika­ tionstopologie, in die die Steuerung S integriert ist. Die Steuerung S ist durch ein Rechteck dargestellt. Durch eine Anschlussleitung A2 ist die Steuerung S mit dem Bus B1 ver­ bunden, an dem über eine Anschlussleitung A1 das externe Ge­ rät EG hängt. Über den Bus B2 erfolgt die Verbindung zum technischen Prozess P2. Der technische Prozess P2 ist am un­ teren Bildrand durch ein Rechteck dargestellt. Über die An­ schlussleitung A3 ist die Steuerung S mit dem Bus B2 verbun­ den, der wiederum über die Anschlussleitung A4 die Verbindung zum technischen Prozess P2 herstellt.

Die Generierung für den Grundtakt der Steuerung S kann aus unterschiedlichen Taktquellen erfolgen. So z. B. aus einer in­ ternen Taktquelle, dargestellt durch den internen Timer T2 der Steuerung S oder auch durch eine externe Taktquelle wie z. B. den Timer T1, der zum externen Gerät EG gehört. Als ex­ terne Taktquelle kann aber auch der Grundtakt eines Kommuni­ kationsmediums dienen. Wenn der Bus B2 z. B. durch einen äqui­ distanten Profibus realisiert wird, dann kann der Takt für die Steuerung aus dem Grundtakt dieses Busses gewonnen wer­ den. In Fig. 10 ist dies dargestellt dadurch, dass der Timer T3 direkt an der Anschlussleitung A3 positioniert ist, und diese Anschlussleitung A3 stellt die Verbindung zum Bus B2 her. Die Steuerung hängt somit als Slave am Bus und kann di­ rekt den Bustakt verwenden. Weiterhin kann als externe Takt­ quelle ein Taktgeber TG dienen, der im technischen Prozess P2 integriert ist. Ein Taktgeber TG in einem technischen Prozess kann z. B. der Arbeitstakt einer Produktionsmaschine oder Ver­ packungsmaschine sein. In der Darstellung gemäß Fig. 10 sind als Kommunikationsmedien beispielhaft Busverbindungen darge­ stellt. Es können aber als Kommunikationsmedien aber auch Ring-, Stern- oder andere Verbindungsarten gewählt werden, auch wireless-Verbindungen. Aus diesen Verbindungssystemen kann dann der oben genannte Grundtakt abgeleitet werden.

Claims (14)

1. Verfahren zum Betrieb einer industriellen, mit einem Run­ time-System (RTS) ausgestatteten Steuerung (S), insbesondere für Produktionsmaschinen, dadurch gekennzeichnet, dass Mechanismen bereitgestellt sind, die es einem Anwender ermöglichen im Programmfluß auf eine beliebige Bedingung zu warten, wobei bei Erfülltsein der Bedingung der Programmfluß unmittelbar fortgesetzt wird, bei Nichterfülltsein der Bedin­ gung der Programmfluß solange angehalten wird, bis das Er­ fülltsein der Bedingung festgestellt wird, wobei beim Warten auf das Erfülltsein der Bedingung die Priorität der Bedin­ gungsüberprüfung im Vergleich zur aktuellen Taskpriorität er­ höht wird.

2. Industrielle Steuerung nach Anspruch 1, dadurch gekennzeichnet, dass nach dem Erfülltsein der Bedingung die folgende Pro­ grammsequenz bis zu einem expliziten Ende hochprior bearbei­ tet wird, wobei nach dem expliziten Ende der Programmsequenz die alte Taskpriorität wieder aufgenommen wird.

3. Industrielle Steuerung nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass für die Formulierung der Bedingungen Prozeßsignale und/oder interne Signale der Steuerung und/oder Variablen aus Anwenderprogrammen (AP1-AP4) verwendet werden.

4. Industrielle Steuerung nach einem der vorstehenden Ansprü­ che, dadurch gekennzeichnet, dass die Bedingungen logische und/oder arithmetische und/oder beliebige funktionelle Verknüpfungen enthalten.

5. Industrielle Steuerung nach einem der vorstehenden Ansprü­ che, dadurch gekennzeichnet, dass ein Anwenderprogramm (AP1-AP4) für den Betrieb der Steuerung mehr als einen solchen Mechanismus enthält.

6. Industrielle Steuerung nach einem der vorstehenden Ansprü­ che, dadurch gekennzeichnet, dass es mehrere Anwenderprogramme (AP1-AP4) beim Betrieb der Steuerung geben kann, die diese Mechanismen enthalten.

7. Industrielle Steuerung nach einem der vorstehenden Ansprü­ che, dadurch gekennzeichnet, dass der jeweilige Mechanismus einem Anwender in einem Anwen­ derprogramm (AP1-AP4) als übliches programmiersprachliches Konstrukt zur Verfügung steht.

8. Industrielle Steuerung zur Durchführung des Verfahrens nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Runtime-System (RTS) der Steuerung (S) ein Ablauf­ ebenenmodell enthält, das mehrere Ablaufebenen unterschiedli­ chen Typs mit unterschiedlicher Priorität aufweist, wobei folgende Ablaufebenen vorgesehen sind:

• a) eine Ebenengruppe mit synchron getakteten Ebenen, beste­ hend aus mindestens einer Systemebene und mindestens ei­ ner Anwenderebene, wobei die Ebenen dieser Ebenengruppe untereinander eine Priorisierung aufweisen können,
• b) einer Anwenderebene für Systemexceptions,
• c) einer zeitgesteuerten Anwenderebene
• d) einer ereignisgesteuerten Anwenderebene
• e) einer sequentiellen Anwenderebene
• f) einer zyklischen Anwenderebene,

wobei Anwenderebenen der Ebenengruppe a) optional synchron zu einer der Systemebenen der Ebenengruppe a) laufen können.

9. Industrielle Steuerung nach Anspruch 8, dadurch gekennzeichnet, dass der Grundtakt des Ablaufebenenmodells aus einem internen Timer (T2) oder aus einem internen Takt (T3) eines Kommunika­ tionsmediums oder aus einem externen Gerät (EG) oder von ei­ ner Größe (TG), die zum technologischen Prozeß (P1, P2) ge­ hört abgeleitet wird.

10. Industrielle Steuerung nach Anspruch 8 oder Anspruch 9, dadurch gekennzeichnet, dass die zeitgesteuerte Anwenderebene, die ereignisgesteuerte Anwenderebene, die sequentielle Ablaufebene, die zyklische Hintergrundebene und die Anwenderebene für Systemexceptions optional sind.

11. Industrielle Steuerung nach Anspruch 8, 9 oder 10, dadurch gekennzeichnet, dass die synchronen Ebenen zum Grundtakt übersetzt und/oder untersetzt und/oder im Verhältnis 1 : 1 getaktet sind.

12. Industrielle Steuerung nach Anspruch 8, 9, 10 oder 11, dadurch gekennzeichnet, dass weitere priorisierende Schichtungen innerhalb der Ab­ laufebenen vorgesehen sind.

13. Industrielle Steuerung nach Anspruch 8, 9, 10, 11 oder 12, dadurch gekennzeichnet, dass optional Anwendertasks beim Systemhochlauf und/oder beim Systemrunterfahren durchlaufbar sind.

14. Industrielle Steuerung nach Anspruch 8, 9, 10, 11, 12 o­ der 13, dadurch gekennzeichnet, dass in die Anwenderebenen Anwenderprogramme (AP1-AP4) lad­ bar sind, die je nach Typ der Anwenderebene zyklusorientiert oder sequentiell programmiert sind.