DE10038439A1

DE10038439A1 - Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, im Kontext der Flow Chart Programmierung

Info

Publication number: DE10038439A1
Application number: DE2000138439
Authority: DE
Inventors: Regina Schmitt; Peter Wagner
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2000-08-07
Filing date: 2000-08-07
Publication date: 2002-02-28
Anticipated expiration: 2020-08-08
Also published as: DE10038439B4

Abstract

Durch die Erfindung wird ein Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen im Kontext der Flow Chart Programmierung aufgezeigt, wobei den grafischen Elementen (E1-En) sog. Suspend-Befehle zugeordnet werden. Durch den Einsatz eines Tasksteuermechanismus im Run-Time-System (RTS) kann der Anwender (A1, A2) auf Flow Chart-Ebene beim Debuggen einen Single-Step-Modus und/oder einen Breakpoint-Modus verwenden.

Description

Die Erfindung bezieht sich auf ein Verfahren für das Debuggen von Programmen für industrielle Steuerungen, insbesondere Be wegungssteuerungen, wobei ein Anwender mit einem Editor gra phische Elemente, insbesondere Kontrollstrukturen und Funkti onsblöcke, zu einem auf einer Anzeigeeinrichtung visualisier baren Flow Chart verknüpft.

Im industriellen Umfeld ist es bekannt, sowohl für die Steue rung eines technischen Prozesses als auch für die Steuerung der Bewegung einer Verarbeitungs- bzw. Produktionsmaschine graphische Eingabehilfsmittel sowie einen Bildschirm zur Vi sualisierung zu verwenden (Hans D. Kief: "NC/CNC Handbuch", 2000, Hansa Verlag, Seite 254, Bild 7 bzw. Seite 327, Bild 6). Grundelemente grafischer Struktur-, Fluss- und Ab laufpläne sind in der Norm DIN 66 001 aufgeführt.

In "Visuelle Sprachen - ein unaufhaltsamer Trend in der In dustrie" (Josef Hübl, SPS/IPC/Drives - Tagungsband, Seite 88 -95, 23.-25. November 1999, Nürnberg, Verlag Hüthig GmbH, Heidelberg) ist außerdem angegeben, dass Kontrollfluss- bzw. Datenflussdiagramme für die Steuerung von Automatisierungs aufgaben mit Hilfe graphischer Editoren erstellt werden.

Es ist seit langem üblich in Programmierumgebungen Debugger als Hilfsprogramme für die Fehlersuche und Fehlerlokalisie rung einzusetzen (Volker Claus et al., DUDEN Informatik, 2. erw. Auflage, S. 188, Dudenverlag, 1993).

Bei den heutzutage existierenden Debuggern werden aber die Haltepunkte (Breakpoints), die zum anwenderkontrollierten Ausführen des zu testenden Programmes notwendig sind, in den Prozessorcode hineincompiliert. Dadurch findet die zum Debug gen notwendige schrittweise bzw. sukzessive Ausführung des Programmes auf einer niedrigen Abstraktionsebene statt und ist dadurch für einen Anwender z. B. hinsichtlich Visualisie rung unflexibel.

Außerdem unterstützen die heutzutage existierenden graphi schen Eingabehilfsmittel und graphischen Editoren für die Programmierung von industriellen Steuerungen einen Anwender ungenügend hinsichtlich adaptiver Mechanismen bezüglich sei ner Applikation zugrundeliegenden Hardwarekonfiguration und stellen ihm im grafischen Editor nur einen starren und einge schränkten Vorrat an Sprachmechanismen zur Verfügung.

Weiterhin unterstützen die heutzutage existierenden graphi schen Eingabehilfsmittel und graphischen Editoren für die Programmierung von industriellen Steuerungen nur dediziert die Programmierung der Steuerung eines technischen Prozesses (SPS-Funktionalität) oder die Programmierung der Steuerung der Bewegung einer Verarbeitungs- bzw. Produktionsmaschine. Die Programmerstellung für beide Anwendungsgebiete wird von existierenden Flow Chart-Editoren jeweils nicht adäquat un terstützt.

Ein weiterer Nachteil der heutzutage bei der Programmierung industrieller Automatisierungsaufgaben eingesetzten Flow Chart-Editoren ist, dass die mit ihnen erzeugten Diagramme direkt in ablauffähigen Prozessorcode umgesetzt werden oder dass aus den Diagrammen ASCII-Code erzeugt wird, der dann im jeweiligen Zielsystem laufzeitintensiv interpretiert werden muss. Neben der dadurch resultierenden Unflexibilität bezüg lich der Portierung und Übertragung der Programme auf andere Anlagen oder Maschinen bedeutet dieser Mechanismus als weite ren Nachteil für den Anwender nur eingeschränkte Debugging- Möglichkeiten.

Außerdem liegen zusätzliche Nachteile existierender Flow Chart-Editoren im meist starren und unflexiblen Sprachvorrat an für den Anwender verwendbaren Icons und in der fest vorge gebenen sequentiellen Abarbeitungsreihenfolge der Icons bzw. der entsprechenden Funktionsblöcke. Auch bieten existierende Flow Chart-Editoren häufig nur wenig Möglichkeiten zur Formu lierung von Synchronisationsmechanismen, die aber insbesonde re für die Programmierung von Applikationen in der indus triellen Automatisierung sehr oft benötigt werden.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Verfahren gemäß Oberbegriff von Anspruch 1 zu schaffen, wobei einem An wender gemäß der jeweiligen Abstraktionsebene im Programmer stellungsprozess adäquate Debugging-Mechanismen zur Verfügung gestellt werden.

Gemäß der Erfindung wird diese Aufgabe für ein Verfahren der eingangs genannten Art dadurch gelöst, dass die folgenden Verfahrensschritte durchgeführt werden:

a) vom Anwender wird ausgehend vom Flow Chart ein Debug- Vorgang vorbereitet,
b) dadurch wird jedem grafischen Element ein Suspend-Befehl zugeordnet,
c) der Debug-Vorgang wird gestartet,
d) der Programmablauf folgt bis zur unmittelbar folgenden Suspend-Befehl,
e) dem Anwender wird visualisiert, wo im Flow Chart die ak tuelle Flow Chart befindlich ist,
f) der Anwender startet das Fortschalten zur nächst mögli chen Suspend-Befehl,
g) die Schritte d) bis f) werden solange fortgeführt, bis das Flow Chart-Ende erreicht ist.

Ein Anwender hat dadurch die Möglichkeit das Verhalten bzw. das Fehlverhalten eines Programmablaufs auf grafischer Flow Chart-Ebene zu untersuchen.

Üblicherweise werden die Haltepunkte, die ein Debug-Programm für seine Arbeitsweise benötigt auf Prozessorcodeebene ge setzt, d. h. in den Prozessorcode (durch einen Compiler) ein gebracht. In der vorliegenden Erfindung werden aber die Hal tepunkte in Form von Suspend-Befehlen den Flow Chart Elemen ten zugeordnet, d. h. die Einbringung der Haltepunkte ge schieht auf Hochsprachenebene.

In der vorliegenden Erfindung kann ein Anwender das Debugging im Single-Step-Modus oder im Breakpoint-Modus durchführen, denn ein Suspend-Befehl kann auch durch Variablenwerte, Be dingungen oder Speicheradressen vorbelegt werden. In Abhän gigkeit dieser Vorbelegungen führt sie eine "Suspendierung" (Halt) des Programmablaufs herbei oder nicht.

In beiden Modi kann der Anwender das "Durchhangeln" durch das Programm am Bildschirm visuell verfolgen. Das aktuelle grafi sche Element kann z. B. durch einen Cursor angezeigt werden. Auch andere Möglichkeiten einer Visualisierung sind denkbar.

Eine erste vorteilhafte Ausgestaltung der Erfindung liegt darin, dass ein durch einen Suspend-Befehl angehaltenes gra fisches Element, bzw. die zu diesem Element gehörige Task mit einem Tasksteuermechanismus des Run-Time-Systems fortgesetzt wird. Der Tasksteuermechanismus kann vom Anwender durch Ein gaben im Engineering System bedient werden (im Single-Step- Modus und/oder im Breakpoint-Modus), er kann aber auch durch Programme des Run-Time-Systems angesteuert werden. Z. B. kön nen dadurch Regressionstests durchgeführt werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Anwender im Engineering System über den Tasksteuermechanismus des Run-Time-Systems einen Resume- Befehl bedient, der den aktuellen Suspend-Befehl fortschal tet. Der Anwender kann durch die einfache Bedienung des Resu me-Befehls auf Flow Chart-Ebene sehr einfach ein Einzel- Schritt-Debugging durchführen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der Tasksteuermechanismus des Run-Time-Systems über vom Anwender im Engineering System vorbelegbare Variab len in Form eines Breakpoint-Debuggings verwendet wird. Da durch kann der Anwender auf sehr komfortable Art und Weise Breakpoints setzen und auf Flow Chart-Ebene ein Breakpoint- Debugging durchführen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Variablenvorbelegungen im Tasksteuermechanis mus durch andere Programme des Run-Time-Systems erfolgen. Da durch wird das automatische Testen von Programmen (z. B. auto matische Regressionstests) sehr leicht ermöglicht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die folgenden Schritte aufeinander folgend durch geführt werden:

a) aus dem Flow Chart wird eine textuelle Sprache erzeugt,
b) die textuelle Sprache wird in einen prozessorunabhängigen Zwischencode kompiliert,
c) der prozessorunabhängige Zwischencode wird auf die Steue rung geladen,
d) der prozessorunabhängige Zwischencode wird in ablauffähi gen Prozessorcode umgesetzt.

Dadurch, dass aus den Flow Chart-Diagrammen in einem Zwi schenschritt eine textuelle Sprache erzeugt wird, hat der An wender die Möglichkeit, bereits auf dieser Ebene der textuel len Sprache Plausibilitätsüberprüfungen durchzuführen. Er kann aber auch weitere Sprachelemente, die in der textuellen Sprache vorliegen, zu seiner Anwendung hinzubinden. Dadurch, dass die textuelle Sprache in einem weiteren Zwischenschritt in einen prozessorunabhängigen Zwischencode kompiliert wird, bleibt die angesprochene Flexibilität für den Anwender wei terhin erhalten. Auch auf dieser Zwischencodeebene kann der Anwender Plausibilitätschecks bzw. ein Debugging durchführen. Der letztendlich in der Steuerung ablaufende Prozessorcode wird aus dem prozessorunabhängigen Zwischencode generiert, dadurch wird das Target der Anwendung erst zu einem sehr spä ten Zeitpunkt festgelegt. Durch die Zwischenschritte bei der Codegenerierung können außerdem sehr leicht unterschiedliche Ziel-Hardwaren bedient werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass dem Anwender auf Ebene der textuellen Sprache und/oder auf Ebene des Zwischencodes und/oder auf Ebene des Prozessorcodes jeweils eine Debug-Schnittstelle zur Verfügung steht. Dadurch ist für einen Anwender das Debuggen von Pro grammen in der jeweiligen Codeebene in der dazugehörigen Abs traktionsstufe möglich. Ein Anwender ist somit in der Lage je nach Ausbildungsstand oder Erfahrung sich eine geeignete Abs traktionsebene zum Debuggen zu wählen. Außerdem ist es be kannt, dass auf jeder Codeebene bestimmte Typen von Fehlern mehr oder weniger häufig auftauchen. Durch die Möglichkeit des Debuggens auf unterschiedlichen Codeebenen kann ein An wender gezielt nach Fehlern suchen, die für die jeweilige Codeebene typisch sind. Die Fehlersuche bzw. Fehlerlokalisie rung wird dadurch effizienter.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass dem Anwender im Flow Chart-Editor, in Abhängig keit von der zugrundeliegenden Maschinenprojektierung und/oder Hardwarekonfiguration adäquate Sprachmechanismen zur Verfügung gestellt werden. Dadurch wird einem Anwender eine Programmierumgebung zur Verfügung gestellt, die auf die zugrunde liegende Hardware abgestimmt ist und somit optimal den vorliegenden Anforderungen und Randbedingungen genügt. Der Sprachvorrat des Flow Chart-Editors adaptiert sich somit selbständig an die vorhandenen HW-Gegebenheiten (z. B. die zugrunde liegende Maschinenkonfiguration).

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass aus anwenderdefinierten Unterprogrammen einer textuellen Sprache automatisch über einen Umsetzer nach Art eines Compilers weitere grafische Elemente in Flow Chart- Notation generiert werden, welche die Funktionsschnittstelle der entsprechenden Unterprogramme enthalten und die dem An wender ebenfalls zur Verfügung gestellt werden. Dadurch ist es möglich, dass aus schon vorhandenen Unterprogrammen der textuellen Sprache oder aus zusätzlichen Unterprogrammen, die in die textuelle Sprache eventuell vom Maschinenbauer einge bracht wurden, automatisch Icons und die dazugehörigen Masken vom System generiert werden und dem Anwender im Flow Chart- Editor zur Verfügung gestellt werden. Die Funktionsschnitt stelle und die Übergabeparameter der Unterprogramme der tex tuellen Sprache werden dabei automatisch für die Flow Chart Icons generiert. Durch diesen Mechanismus lassen sich leicht von OEM-Kunden (Original Equipment Manufacturer) schon in textueller Sprache vorliegende Unterprogramme in den Flow Chart-Editor übernehmen. Damit wird dem Endanwender für seine Flow Chart-Programmierung ein angepasster und erweiterter Sprachvorrat an Icons zur Verfügung gestellt.

Für den Hersteller bzw. für den Vertreiber von Flow Chart Editoren für die Programmierung von industriellen Steuerungen ergibt sich weiterhin der Vorteil, dass sie den Flow Chart Editor mit einem Basisvorrat an grafischen Sprachelementen ausliefern können, der dann in Abhängigkeit evtl. schon vor handener Unterprogramme der textuellen Sprache auf die Belan ge eines Anwenders angepasst wird. Ein Flow Chart Editor kann somit in einer anpassbaren Standard- oder Basisversion an Kunden ausgeliefert werden (economies of scale). Für den An wender ergibt sich dadurch die Möglichkeit einer technologi schen Skalierung für seine jeweiligen Anwendungen bezüglich des ihm zur Verfügung stehenden Sprachvorrats an grafischen Elementen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die automatisch generierten grafischen Elemente vom Anwender als Sprachelemente des Flow Charts verwendet werden. Dadurch, dass der Anwende r die automatisch generier ten Icons als normale Sprachelemente des Flow Chart-Editors verwenden kann, wird der ihm zur Verfügung stehende Sprach vorrat an Flow Chart-Elementen, d. h. an Icons, erweitert. So mit wird die Flexibilität und Ausdrucksmöglichkeit bezüglich der Programmierung von Applikationen für den Anwender erhöht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass als textuelle Sprache Structured Text nach IEC 6-1131 verwendet wird. Dadurch, dass mit IEC 6-1131 eine genormte Sprache auf der Ebene der textuellen Sprache verwen det wird, ist der Austausch bzw. die Kopplung mit anderen Programmiersystemen sehr leicht möglich. Außerdem wird durch die Verwendung von IEC 6-1131 als Zwischensprache die Portie rung auf unterschiedliche Zielsysteme sehr erleichtert.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass ein Anwender zum Formulieren von Bedingungen be liebig zwischen den Darstellungsformen textuelle Sprache, Kontaktplan "KOP" und/oder Funktionsplan "FUP" wechseln kann. Dadurch, dass auf der Structured Text-Ebene IEC 6-1131 als textuelle Sprache verwendet wird, können auch andere Darstel lungsformen von IEC 6-1131 neben der textuellen Sprache, näm lich Kontaktpläne und/oder Funktionspläne, verwendet werden. Ein Anwender hat somit die Flexibilität, innerhalb dieser Sprachen der SPS-Welt, nämlich Structured Text, Kontaktplan oder Funktionsplan, beliebig zu wechseln. Diese Flexibilität ist insbesondere für die Formulierung von Bedingungen ein großer Vorteil für den Anwender, denn er kann sich die Darstellungs- bzw. Beschreibungsform wählen, in der er die meiste Erfahrung hat, oder die dem zugrunde liegenden Problem angemessen ist. Üblicherweise verwendet ein Anwender für die Darstellung von binären Verknüpfungen Kontaktpläne und/oder Funktionspläne und für die Formulierung von arithmetischen Berechnungen Structured Text.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation als Sprachelemente mindestens eine Schleife und/oder mindestens eine Parallel verzweigung vorhanden sind. In den heutzutage gängigen Flow Chart-Editoren werden Schleifen und oft auch Verzweigungen mit Hilfe von Sprungmarken dargestellt. Durch die Verwendung von Sprüngen (Goto-Problematik!) und die dazugehörigen Ziel marken wird die Programmgestaltung aber sehr unübersichtlich und schwer nachvollziehbar. Dadurch, dass dem Anwender als eigene Sprachelemente Schleifen und Parallelverzweigung zur Verfügung stehen, wird die Programmerstellung und auch die Lesbarkeit der Programme erheblich vereinfacht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass innerhalb der jeweiligen Parallelverzweigung die einzelnen Befehle im selben Interpolatortakt gestartet wer den. Dadurch, dass alle Zweige des Sprachkonstrukts Parallel verzweigung im selben Interpolatortakt bedient werden, ist eine quasi parallele Abarbeitung der in den einzelnen Zweigen des Parallelverzweigungs-Konstrukts enthaltenen Befehle mög lich. Neben der sequentiellen wird somit auch die parallele Abarbeitung von Befehlen ermöglicht und durch adäquate Sprachmechanismen in der Programmierumgebung für den Anwender unterstützt.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation die Funktionsblöcke durch Maskeneingabe parametriert werden. Dadurch wird für den Anwender die Eingabe von Parametern in einer übersichtlichen und leicht verständlichen Form ermöglicht. Für jeden Typ von Funktionsblock existieren Standardmasken, die einem Anwender nur die für den aktuellen Typ möglichen Parametereingaben er lauben. Die Gefahr von fehlerhaften Eingaben wird durch diese Kontextsensitivität reduziert.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation Funktionsblöcke zu Mo dulen zusammengefasst werden, die wiederum als Funktionsblö cke erscheinen. Dadurch wird die Übersichtlichkeit des Pro grammablaufs im Flow Chart für den Anwender erhöht. Ein An wender kann nämlich logisch zusammengehörende Funktionsblöcke zu einem Modul zusammenfassen und kapseln, wobei dieses Modul wiederum als Funktionsblock im Flow Chart-Editor, d. h. als Icon, erscheint. Durch diesen Mechanismus der Zusammenfassung und Kapselung wird aber nicht nur die Übersichtlichkeit im Ablauf erhöht, auch der Programmablauf lässt sich dadurch strukturieren.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation Module ineinander ge schachtelt werden. Das heißt, ein Modul kann wiederum als Element ein oder mehrere Module enthalten. Module können so zusagen wiederum als Unterprogramme in anderen Modulen ver wendet werden, dadurch wird die Übersichtlichkeit und die Struktur des Programmablaufs im Flow Chart erhöht.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation dem Anwender in den Funktionsblöcken für die Variablenzuweisung jeweils mehrere Zuweisungen möglich sind. Dadurch, dass der Anwender in einem Funktionsblock, d. h. in einem Icon, mehrere Variablenzuwei sungen nacheinander eingeben kann und nicht für jede Vari ablenzuweisung einen neuen Funktionsblock benötigt, wird zum einen die Übersichtlichkeit erhöht, zum anderen wird aber auch das Programmierprinzip der hohen Kohäsion unterstützt, da der Anwender seine Variablenzuweisungen, die sinnvoller weise zu diesem Funktionsblock gehören, auch in diesem einen Funktionsblock gebündelt vornehmen kann.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass in der Flow Chart-Notation die Funktionsblöcke, die Funktionen repräsentieren, die eine Zeitdauer beanspruchen, Weiterschaltbedingungen enthalten. Funktionen, die eine Zeitdauer beanspruchen, sind z. B. Referenzpunktfahren, Be schleunigen oder Achspositionieren. Solche Funktionen bzw. ihr Zusammenwirken können Anwender mit Hilfe der Weiter schaltbedingungen synchronisieren. Einem Anwender steht somit mit Hilfe der Weiterschaltbedingungen ein Synchronisationsme chanismus zur Verfügung, der es ihm erlaubt, komplexe Bewe gungen und Zusammenhänge mehrerer Achsen zu synchronisieren.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die grafischen Elemente des Flow Charts automa tisch positioniert werden. Wenn ein Anwender ein neues Icon im Flow Chart-Editor darstellen will, wird es automatisch an der Stelle positioniert, die als nächstes dem logischen Pro grammablauf entspricht. Dadurch, dass ein Anwender die gene rierten Icons nicht selbst positionieren muss, wird seine Ar beitseffizienz gesteigert.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Icons des Flow Charts automatisch miteinander verbunden werden. Auch hierin liegt eine Steigerung der Ar beitseffizienz des Anwenders, da er die Icons nicht nachträg lich per Hand miteinander verbinden muss.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass das Flow Chart in der Anzeige verkleinert oder vergrößert dargestellt wird. Durch diese Zoom-Funktionalität wird für den Anwender die Übersichtlichkeit der Diagramme er höht und außerdem kann er bestimmte Programmabläufe, die ihn momentan interessieren, durch Vergrößerung graphisch hervor heben.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass durch Markierungen in der textuellen Sprache eine Rückübersetzung in Flow Chart-Notation möglich ist. Durch die Verwendung von syntaktischen und geometrischen Informationen, die in Form von Markierungen erfolgen, ist es möglich, aus der textuellen Sprache in die Flow Chart-Notation eine Rück übersetzung vorzunehmen. Diese Rückübersetzungsmöglichkeit hat für den Anwender den Vorteil, dass Änderungen, die auf der Ebene der textuellen Sprache eingegeben werden, unmittel bar im Flow Chart-Editor in der Flow Chart-Notation nachgezo gen werden können und somit für den Anwender in den Flow Chart-Diagrammen sichtbar sind. Solche rückübersetzten Pro gramme kann der Anwender dann auf der Graphikebene mit Hilfe des Flow Chart-Editors weiterbearbeiten und daraus im weite ren Vorgehen Steuerungscode erzeugen.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Schritte a) bis c) in einem Sammelschritt ausgelöst werden. Damit muss der eigentliche Debug-Vorgang nach der Vorbereitung und der Zuordnung der Suspend-Befehle zu den grafischen Elementen nicht explizit vom Anwender in einem separaten Arbeitsschritt gestartet werden.

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass während der Abarbeitung des Flow Chart Programms das jeweils aktuelle grafische Element optisch auf der Anzei geeinrichtung gekennzeichnet wird. Ein Anwender kann somit im Flow Chart den Programmablauf verfolgen und dabei ein positi ves, aber auch ein negatives Verhalten des Programmes visua lisiert erkennen.

Die wesentlichen mit der Erfindung erzielten Vorteile beste hen also insbesondere darin, dass ein Anwender bei der Feh lersuche und beim Programmtest auf der Abstraktionsebene von Flow Charts in drei Aspekten adäquat unterstützt wird: Pro grammbeobachtung, Einzelschrittabarbeitung (Single Step) und Einsatz von parametrierbaren Breakpoints.

Weitere Vorteile der Erfindung bestehen insbesondere darin, dass aus Unterprogrammen, die in der textuellen Sprache vor liegen, für den Flow Chart-Editor Icons generiert werden, die die Funktionsschnittstelle der entsprechenden Unterprogramme automatisch enthalten. Wenn ein OEM-Kunde bereits Unterpro gramme in der textuellen Sprache erstellt hat, so können die se Unterprogramme automatisch durch entsprechende Icons den Sprachvorrat des Flow Chart-Editors erweitern.

Ein weiterer sehr großer Vorteil liegt darin, dass ein Anwen der in einer einheitlichen Programmierumgebung sowohl Bewe gungssteuerungsaufgaben (Motion Control) und Prozesssteue rungsaufgaben (SPS-Aufgaben) in einer jeweils angemessenen Form programmieren kann. Weiterhin ist von Vorteil, dass die Programmierumgebung sich projektsensitiv verhält, d. h. dass dem Anwender in Abhängigkeit von der zugrunde liegenden Hard ware bzw. Maschinenprojektierung zusätzliche dedizierte Sprachelemente zur Verfügung gestellt werden.

Ein weiterer Vorteil liegt darin, dass der Anwender sowohl für die sequentielle als auch für die zyklische Programmie rung der Steuerungsabläufe unterstützt wird. Dadurch, dass eine geschachtelte Modulbildung von Funktionsblöcken zur Ver fügung steht, hat der Anwender den Vorteil, die Übersicht lichkeit und die Struktur seiner Programme zu erhöhen, da er die Designkriterien, Lokalität und hohe Kohäsion sehr leicht umsetzen kann.

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

Dabei zeigen:

Fig. 1 in einer Schemadarstellung ein Engineering-System, das zugehörige Run-Time-System und den zu steuern den technischen Prozess,

Fig. 2 zeigt in einem Übersichtsbild Elemente des Enginee ring-Systems und der Steuerung sowie ihre Beziehun gen untereinander,

Fig. 3 zeigt ebenfalls in Form eines Übersichtsbildes den programmtechnischen Zusammenhang zwischen Elementen des Engineering-Systems und des Run-Time-Systems,

Fig. 4 zeigt ein einfaches Diagramm in Flow Chart- Notation,

Fig. 5 zeigt ein komplexes Diagramm in Flow Chart-Notation mit den Kontrollstrukturen while und if,

Fig. 6 zeigt ebenfalls ein komplexes Diagramm in Flow Chart-Notation mit dem Sprachkonstrukt Parallelver zweigung (sync),

Fig. 7 zeigt eine Parametriermaske für den Befehl "positi oniere Achse",

Fig. 8 zeigt in einem Übersichtsbild, wie der Sprachvorrat des Flow Chart Editors erweitert wird,

Fig. 9 zeigt eine Auswahl von Sprachelementen (so genann ten Icons) des Flow Chart-Editors.

In der Darstellung gemäß Fig. 1 wird in Form eines Struktur bildes gezeigt, dass die Steuerung eines technischen Prozes ses TP über das Run-Time-System RTS einer industriellen Steu erung erfolgt. Die Verbindung zwischen dem Run-Time-System RTS der Steuerung und dem technischen Prozess TP geschieht bidirektional über den Ein-/Ausgang EA. Die Programmierung der Steuerung und damit das Festlegen des Verhaltens des Run- Time-Systems RTS geschieht im Engineering-System ES. Das En gineering-System ES enthält Werkzeuge für die Konfigurierung, Projektierung und Programmierung für Maschinen bzw. für die Steuerung technischer Prozesse. Die im Engineering-System er stellten Programme werden über den Informationspfad I1 in das Run-Time-System RTS der Steuerung übertragen. Bezüglich sei ner Hardware-Ausstattung besteht ein Engineeringsystem ES üblicherweise aus einem Computersystem mit Grafikbildschirm (z. B. Display), Eingabehilfsmitteln (z. B. Tastatur und Maus), Prozessor, Arbeits- und Sekundärspeicher, einer Ein richtung für die Aufnahme computerlesbarer Medien (z. B. Dis ketten, CDs) sowie Anschlusseinheiten für einen Datenaus tausch mit anderen Systemen (z. B. weiteren Computersystemen, Steuerungen für technische Prozesse) oder Medien (z. B. Inter net). Eine Steuerung besteht üblicherweise aus Eingabe- und Ausgebeeinheiten, sowie aus Prozessor und Programmspeicher.

Das Run-Time-System RTS enthält einen Tasksteuermechanismus, der beim Debugging der Flow Charts verwendet wird. Der Tasksteuermechanismus kann z. B. vom Engineering System ES mit Informationen versorgt werden. Insbesondere ist es Aufgabe des Tasksteuermechanismus die Resume-Befehle zu bedienen, um eine Fortsetzung des Programmablaufs zu bewirken.

In der Darstellung gemäß Fig. 2 werden in Form eines Über sichtsbildes Elemente des Engineering-Systems und der Steue rung sowie ihr Zusammenspiel dargestellt. Dabei werden die einzelnen Elemente in Form von Rechtecken dargestellt, die im Engineering-System enthaltene Datenablage wird in Form des üblicherweise verwendeten Datenspeichersymbols dargestellt. Durch Pfeile (unidirektional oder bidirektional) wird der da tenlogische bzw. der ablauflogische Zusammenhang zwischen den Elementen dargestellt. Die obere Hälfte von Fig. 2 zeigt die Elemente des Engineering-Systems, nämlich den MCC-Editor, den ST-Compiler mit Programmiergebung, den Konfigurations-Server KS und die Maschinenprojektierung sowie eine Datenablage. Die Zugehörigkeit dieser Elemente zum Engineering-System wird durch Umrandung dargestellt. Die Steuerung beinhaltet den Co deumsetzer und die Programmverarbeitung. Auch die Elemente der Steuerung, die sich im unteren Abschnitt von Fig. 2 befin den, sind umrandet. Sowohl das Engineering-System als auch die Steuerung können noch weitere Elemente beinhalten, sie sind aber aus Gründen der Übersichtlichkeit nicht darge stellt.

Im MCC-Editor (MCC steht für Motion Control Chart) werden die graphischen Programmabläufe erzeugt. Die Sprachelemente des Editors, d. h. die Icons, können z. B. über eine Befehlsleiste im Bildschirm, die mit Hilfe einer Maus bedient wird oder denkbare andere Eingabehilfsmittel mit dem Editor erzeugt und dargestellt werden. Ein Anwender kann mit Hilfe des MCC- Editors Funktionsblöcke (Icons) und Kontrollstrukturen zu ei nem Flow Chart verknüpfen, d. h. er kann den MCC-Editor als graphisches Programmier-Tool für die Erstellung von Program men für Bewegungssteuerungen und/oder Prozesssteuerungen ver wenden. Aus dem Flow Chart wird ein textuelles Programm bzw. eine textuelle Sprache (üblicherweise Structured Text nach IEC 6-1131) erzeugt. Dieser Structured Text-Code (ST-Code) wird vom Structured Text-Compiler (ST-Compiler, der Teil der Programmierumgebung ist) in einen prozessorunabhängigen Zwi schencode kompiliert. Dieser Zwischencode wird auf die Steue rung geladen und dort vom Codeumsetzer in ablauffähigen Pro zessorcode umgesetzt. Dieser wird von der Programmverarbei tung innerhalb der Steuerung zum Ablauf gebracht. Durch die unidirektionalen Pfeile im linken Abschnitt von Fig. 2 werden die Schritte der Code- bzw. Programmumsetzung dargestellt. Parallel zu den drei von oben nach unten verlaufenden unidi rektionalen Pfeilen, die diese Umsetzung darstellen, verlau fen jeweils zwischen den Elementen MCC-Editor, ST-Compiler, Codeumsetzer und Programmverarbeitung drei bidirektionale Pfeile, die Debug-Schnittstellen bzw. die Möglichkeit einer Programmbeobachtung darstellen. Zwischen Programmverarbeitung und Codeumsetzer existiert eine Debug-Schnittstelle auf Pro zessorcode-, d. h. auf Objektcodeebene, eine weitere Debug- Schnittstelle existiert zwischen dem Codeumsetzer und dem ST- Compiler, diese Debug-Schnittstelle befindet sich auf Zwi schencodeebene. Zwischen dem ST-Compiler und dem MCC-Editor befindet sich eine weitere Debug- bzw. Programmbeobachtungs schnittstelle auf Ebene von Structured Text (ST-Code).

Dadurch ist für einen Anwender das Debuggen von Programmen in der jeweiligen Codeebene in der dazugehörigen Abstraktionsstufe möglich. Ein Anwender ist somit in der Lage je nach Ausbildungsstand oder Erfahrung sich eine geeignete Abstrak tionsebene zum Debuggen zu wählen. Außerdem ist es bekannt, dass auf jeder Codeebene bestimmte Typen von Fehlern mehr o der weniger häufig auftauchen. Durch die Möglichkeit des De buggens auf unterschiedlichen Codeebenen kann ein Anwender gezielt nach Fehlern suchen, die für die jeweilige Codeebene typisch sind. Die Fehlersuche bzw. Fehlerlokalisierung wird dadurch effizienter.

In Fig. 2 sind als weitere Elemente des Engineering-Systems die Maschinenprojektierung und ein Konfigurations-Server KS dargestellt. In der Maschinenprojektierung wird mit Hilfe ge eigneter Werkzeuge die Auslegung der Hardware bzw. der zugrunde gelegten Maschine vollzogen. Das heißt, in der Ma schinenprojektierung wird z. B. festgelegt, welche Achstypen in welcher Anzahl physikalisch vorhanden sind. Diese Maschi neninformationen werden über den Konfigurations-Server KS in den MCC-Editor eingespeist. Die Übertragung dieser Informati onen wird durch die unidirektionalen Pfeile 12 und 13 darge stellt. Weiterhin beinhaltet der Konfigurations-Server KS weitere relevante Konfigurationsinformationen für das System, die z. B. auch für die Lizenzierung von zugehörigen Software komponenten verwendet werden können.

Eine Datenablage DA, dargestellt durch das gängige Datenspei chersymbol, beinhaltet drei Aspekte: Zum einen das vom MCC- Editor für ein Flow Chart erzeugtes Objektmodell, als zweites den dazugehörigen Structured Text und der dritte Inhalt der Datenablage DA ist der aus dem Structured Text generierte Zwischencode. Die Datenablage DA steht in bidirektionaler Verbindung zum MCC-Editor und ST-Compiler, dargestellt durch die bidirektionalen Informationspfeile I4 und I5.

Die Darstellung gemäß Fig. 3 zeigt als Übersichtsbild die vor handenen Abstraktionsebenen aus Sicht des Programmcodes. Die unterschiedlichen Programmcode-Ebenen sind als Rechtecke dargestellt. Die oberste Ebene ist die MCC-Ebene, in der die Flow Chart-Programme erzeugt werden. Die nächstuntergeordnete Codeebene ist die Structured Text-Ebene ST. In die ST-Ebene gelangt man aus der MCC-Ebene durch eine entsprechende Code generierung, dargestellt durch einen Pfeil vom MCC-Block zum ST-Block. Unterhalb der Structured Text-Ebene ST liegt die Zwischencode-Ebene. Durch einen Compiler wird aus dem Struc tured Text-Programm ein prozessorunabhängiger Zwischencode kompiliert, dargestellt durch den Pfeil vom ST-Block zum Block mit dem Namen Zwischencode. Unterhalb der Zwischencode- Ebene liegt die unterste Codeebene, nämlich die Objektcode- Ebene, die den ablauffähigen Prozessorcode beinhaltet. Aus dem Zwischencode wird über einen Umsetzer der Objektcode er zeugt, ebenfalls dargestellt durch einen Pfeil vom Zwischen codeblock zum Objektcodeblock. Von der Objektcode-Ebene gehen rechtwinklig abgewinkelte Pfeile zurück zur Structured Text- Codeebene ST und zur Flow Chart-Ebene MCC. Dadurch ist ange deutet, dass auf diesen Ebenen Test- und Programmverfolgungs aktivitäten stattfinden können, auf der Basis des Objekt codes. Durch den fetten Doppelpfeil zwischen der MCC- und der ST-Ebene wird angedeutet, dass zwischen diesen beiden Ebenen Aufrufe, Task-Steuerbefehle und Variablenaustauschfunktionen möglich sind. Die gestrichelte Linie in Fig. 3 zeigt die Gren ze zwischen dem Engineering System ES und dem Run-Time-System RTS der Steuerung (S; Fig. 2) an. Die Grenze verläuft durch die Zwischencode-Ebene, alles, was oberhalb der gestrichelten Linie ist, gehört zum Engineering System ES, alles, was un terhalb der gestrichelten Linie stattfindet, gehört zum Run- Time-System RTS.

Weiterhin wird in Fig. 3 gezeigt, wie ein Programmierer oder Anwender (am linken Bildrand dargestellt durch ein stilisier tes Strichmännchen) im Engineering System ES Eingaben ein bringen kann. Er kann zum einen auf der MCC-Ebene mit Hilfe der graphischen Programmierung Flow Charts erzeugen, zum an deren kann er auf der Structured Text-Ebene ST durch eine textuelle Programmierung Programme erstellen. Beide Eingabemöglichkeiten sind durch Pfeile vom Strichmännchen zum MCC- Block bzw. zum ST-Block dargestellt.

Darstellung gemäß Fig. 4 zeigt einen einfachen Programmablauf für die Programmierung von Achsbewegungen. Jedes Flow Chart beginnt mit einem Startknoten und endet mit einem Endeknoten. Diese Programmbegrenzungssymbole tragen die Bezeichnung "Start" bzw. "Ende". Start- und Endesymbole werden jeweils durch ein Rechteck dargestellt, dessen Stirnseiten durch zwei Halbkreise ausgebildet sind. Die Programmbefehle werden durch Rechtecke dargestellt, die einen Bezeichner und ein graphi sches Symbol beinhalten, welches den hinterlagerten Befehl repräsentiert.

Die Flow Chart-Symbole werden üblicherweise über eine Einga beleiste mit Hilfe einer Maus im Flow Chart-Editor erzeugt, wobei auch andere Eingabehilfsmittel wie z. B. ein Touch Pad denkbar sind. Alternativ wäre auch eine Bedienung über Tasta tur mit oder ohne Maus möglich.

Die Flow Chart-Symbole werden vom Flow Chart-Editor default mäßig untereinander ausgerichtet und durch eine Linie mitein ander verbunden.

Im Flow Chart nach Fig. 4 wird nach dem Start eine Gleichlauf achse freigeschaltet, danach wird auf ein Synchronisierungs signal gewartet und als nächster und letzter Befehl des Flow Charts wird für eine Gleichlaufachse eine Kurvenscheibe ein geschaltet. Die Befehlsequenz von Fig. 4 wird beendet durch das Endesymbol.

Wenn ein Anwender das vorliegende Flow Chart Debuggen (Feh lersuche, Fehlerlokalisierung, Kontrolle des Programmverhal tens etc.) will, wird er einen Debug-Modus starten, der be wirkt, dass den einzelnen grafischen Elementen des Flow Charts Suspend-Befehle zugeordnet werden. Er kann dann im Single-Step-Modus oder im Breakpoint-Modus das Debugging durchführen. Im Single-Step-Modus erfolgt der Programmablauf nach dem Starten des Debuggers (ein Debugger ist als Dienst programm der Programmierumgebung, d. h. somit auch des Engi neeringsystems (ES; FIG1, FIG2, FIG3) anzusehen) automatisch von Suspend-Befehl zum nächsten Suspend-Befehl. Bei jedem er reichten Suspend-Befehl wird der Programmablauf gestoppt. Das Erreichen eines Suspend-Befehls und des zugehörigen grafi schen Elements wird dem Anwender visuell (z. B. durch speziel len Cursor oder farbiger Kennzeichnung) angezeigt. Das "Lö sen" der Suspend-Befehle geschieht durch entsprechende Resu me-Befehle. Der Anwender kann dadurch die Fortsetzung des Programmablaufs bewirken. Ein Fortsetzen des Programmablaufs kann auch durch einen Tasksteuermechanismus des Run-Time- Systems erfolgen.

Einem Suspend-Befehl können aber auch Bedingungen, Variablen werte oder Speicheradressen zugeordnet werden. Der Programm ablauf wird dann durch den Wert dieser Zuordnungen bestimmt. Dadurch kann mit Hilfe der Suspend-Befehle ein Debugging auch im Breakpoint-Modus erfolgen.

Die Darstellung gemäß Fig. 5 zeigt ein komplexes Flow Chart mit Kontrollstrukturen für eine While-Schleife und für das If-Konstrukt. Das While- und das If-Konstrukt werden jeweils durch sechseckige, wabenförmige Symbole dargestellt. Ansons ten werden im Programmablauf, wie er in Fig. 5 dargestellt ist, die gleichen Typen von Symbolen verwendet, wie sie schon aus Fig. 4 bekannt sind. Auch das Flow Chart nach Fig. 5 be ginnt mit dem Start- und endet mit dem Endesymbol. Unmittel bar nach dem Startknoten folgt ein Befehl, der die Task "mo tion_3" startet. Dieser Befehl ist vom Typ "Starte Task". Das Rechteck für diesen Befehl enthält deshalb auch das zugehöri ge entsprechende Symbol, welches das Starten einer Task dar stellt. Als nächstes im Programmablauf, wie er in Fig. 5 dar gestellt ist, folgt das sechseckige wabenförmige While- Konstrukt. Solange die im While-Konstrukt angegebene Bedin gung true ist, werden die auf das While-Konstrukt folgenden Befehle zyklisch nacheinander ausgeführt. Das Ende der Be fehlsfolge einer While-Schleife wird dargestellt durch einen abgewinkelten Pfeil, der vom letzten Symbol des While- Konstrukts (in Fig. 5 ist dies der Befehl vom Typ "Getriebe gleichlauf aus", bezogen auf eine Gleichlaufachse) von unten abgeht und auf der linken Seite von Fig. 5 zurück in das Whi le-Konstrukt mündet. Ist die Bedingung im While-Konstrukt nicht mehr erfüllt, dann wird die Befehlsfolge, die zum Whi le-Konstrukt gehört, nicht mehr ausgeführt. In Fig. 5 wird dies dargestellt durch eine rechtwinklige Verbindungslinie, die das While-Symbol auf der rechten Seite verlässt und rech ter Hand die zum While-Symbol gehörende Symbolbefehlsfolge umgeht und in auf das dieser Befehlsfolge unmittelbar folgen de Symbol einmündet, in Fig. 5 ist dies das Ende-Symbol.

Wenn aber die While-Bedingung erfüllt ist, wird folgende Be fehlsfolge abgearbeitet: Unmittelbar nach dem While-Konstrukt folgt ein Befehl, der das Warten auf eine Bedingung repräsen tiert. Auch dieser Befehl enthält ein entsprechendes mnemo technisches grafisches Symbol, dass den Wartevorgang graphisch darstellt. Als nächstes folgt ein Befehl, der die Task "motion_2" startet. Auch dieser Befehl ist vom Typ "Starte Task" und enthält das entsprechende graphische Symbol. Nach diesem Befehl folgt das If-Konstrukt, das genauso wie das While-Konstrukt durch ein sechseckiges, wabenförmiges Symbol dargestellt wird. Ist die If-Bedingung (in Fig. 5 dargestellt durch "error << 0"), erfüllt dann wird im True-Zweig die Be fehlsfolge weiter abgearbeitet, ansonsten, wenn die Bedingung nicht erfüllt ist, wird die Befehlsfolge im False-Zweig wei ter abgearbeitet. Im True-Zweig der If-Bedingung folgt als nächster Befehl ein Befehl, der die Task "motion_2" stoppt. Dieser Befehl ist vom Typ "Stoppe Task" Darauf folgt ein Be fehl, der die Task "motion_3" stoppt. Auch dieser Befehl ist vom Typ "Stoppe Task". Diese Befehle werden außerdem durch dazugehörende entsprechende Symbole repräsentiert. Als nächs tes in der Befehlsfolge kommen zwei "Stoppe Achs"-Befehle. Im ersten solchen Befehl wird eine Drehzahlachse gestoppt, im darauffolgenden eine Positionierachse, auch diese "stoppe Achs"-Befehle werden durch dazugehörende entsprechende gra phische Symbole repräsentiert. Der nächste und zugleich der letzte Befehl in Fig. 5 bezieht sich auf eine Achse mit dem Namen "Gleichlaufachse", nämlich auf das Ausschalten des Ge triebegleichlaufes ("Getriebegleichlauf aus"), auch dieser Befehl wird durch ein entsprechendes graphisches Symbol rep räsentiert. Die Symbole des Flow Charts sind durch Linien miteinander verbunden, womit der Programmablauf dargestellt wird. Von diesem Befehl, der den letzten Befehl im While- Konstrukt darstellt, geht ein rechtwinklig abgewinkelter Pfeil zurück zu diesem While-Konstrukt. Dadurch wird das zyk lische Abarbeiten der Befehlsfolge dargestellt. Im While- Konstrukt wird geprüft, ob die Bedingung erfüllt ist. Ist sie erfüllt oder weiterhin erfüllt, wird die Befehlsfolge noch einmal durchlaufen. Ist sie nicht erfüllt, wird das While- Konstrukt verlassen und, wie beispielhaft in Fig. 5 darge stellt, mit dem Ende-Symbolfortgefahren, d. h. der durch das Flow Chart dargestellte Programmablauf wird beendet.

Auch dem Flow Chart gemäß Fig. 5 können zum Zweck des Debug gens Suspend-Befehle zugeordnet werden.

Die Darstellung gemäß Fig. 6 zeigt ebenfalls ein komplexes Diagramm in Flow Chart-Notation mit dem Sprachkonstrukt Pa rallelverzweigung (sync). In Fig. 6 folgt auf das Start-Symbol ein Befehl, der sich auf eine Drehzahlachse bezieht, nämlich "Achsfreigabe schalten". Auch für diesen Befehl wird im Be fehlsrechteck ein graphisches Symbol angegeben, das diesen Befehl repräsentiert. Danach folgt wiederum ein Befehl vom Typ "Achsfreigabe schalten", diesmal aber bezogen auf eine Positionierachse, auch hier ist das dazugehörige entsprechen de Symbol angegeben. Der nächstfolgende Befehl ist ein Syn chronisationsbefehl "warte auf Signal", in Fig. 6 mit "Auto" bezeichnet und mit dem entsprechenden Symbol versehen.

Als nächstes Symbol in Fig. 6 folgt das Symbol für die Paral lelverzweigung (sync). Dieses Symbol wird ebenfalls wie das While- oder das If-Konstrukt durch ein sechseckiges, waben förmiges graphisches Element dargestellt. Alle Befehle, die in dem Sektor unmittelbar unter dem Symbol für die Parallel verzweigung angeordnet sind, werden im selben Interpolator takt gestartet. In Fig. 6 sind dies die Befehle "Positioniere Achse", bezogen auf eine Positionierachse (dieser Befehlstyp beinhaltet auch das zugehörige entsprechende graphische Sym bol) und ein Befehl vom Typ "Setze Ausgang". Der Befehlstyp "Setze Ausgang" ist ebenfalls durch ein Rechteck dargestellt, dieses Rechteck enthält die Adresse des Ausgangs (%QB40) und das entsprechende Symbol für diesen Setz-Befehl (S steht für Set). Die Befehle, die zu einem Parallelverzweigungssymbol gehören, d. h. die innerhalb desselben Interpolatortakts ge startet werden, sind mit dem Parallelverzweigungssymbol nach oben mit einer Linie verbunden und nach unten sind sie mit einer Doppellinie verbunden. Diese waagrechte Doppellinie zeigt an, dass die parallele Abarbeitung wieder aufgehoben ist und dass mit der Bearbeitung des nachfolgenden Befehls so lange gewartet wird, bis alle Aktionen in der Parallelver zweigung beendet sind. Sie ist somit auch das Ende-Symbol des Parallelverzweigungskonstrukts. Als nächstes folgt ein Befehl vom Typ "Drehzahlvorgabe", der sich auf eine Drehzahlachse bezieht. Darauf folgen zwei Befehle vom Typ "Positioniere Achse", die sich jeweils auf Positionierachsen beziehen. Dar auf folgt wieder ein Befehl vom Typ "Stoppe Achse", der sich auf eine Drehzahlachse bezieht. Die Rechtecke, die diese ge nannten Befehle darstellen, beinhalten natürlich auch wieder entsprechende dazugehörige graphische Symbole. Nach dem Be fehl vom Typ "Stoppe Achse", der sich auf die schon genannte Drehzahlachse bezieht, folgt das Ende-Symbol.

Die hier dargestellte Art der Flow Chart-Programmierung un terstützt unterschiedliche Arten der Programmierung. Zum ei nen wird durch das Parallelverzweigungssymbol mit dem Starten der dazugehörigen Befehle in einem Interpolatortakt eine mehr oder weniger echte Parallelität erreicht, d. h. die Program mierung paralleler Threads wird unterstützt, und ihre dazuge hörige Abarbeitung wird ermöglicht. Zum anderen wird die zyk lische Programmierung, d. h. auch die zyklische Programmabar beitung, unterstützt, es kann nämlich dargestellt werden, dass aufeinander folgende Befehle nur angestoßen werden, wo bei aber jeweils nicht auf die Abarbeitung des vorhergehenden Befehls gewartet werden muss. Aber auch die Programmierung und die Darstellung solcher sequentiellen Abläufe wäre mög lich, dass nämlich bei Anstoß eines Befehls auf die Abarbei tung dieses Befehls gewartet wird, bis der nächste Befehl an gestoßen und abgearbeitet wird. Die hier vorgestellte Flow Chart-Programmierung ist somit für einen Anwender sehr flexi bel anwendbar und für unterschiedliche Applikationen einsetz bar.

Auch dem Flow Chart gemäß Fig. 6 können zum Zweck des Debug gens Suspend-Befehle zugeordnet werden.

Die Darstellung gemäß Fig. 7 zeigt eine Parametriermaske für den Flow Chart-Befehl "Positioniere Achse". Oben links im oberen Balken der Parametriermaske steht die Bezeichnung des entsprechenden Befehls, in diesem Fall "Positioniere Achse". Der obere Balken beinhaltet auf seiner rechten Seite zwei Schalter, ein Schalter mit einem Fragezeichen versehen bein haltet eine Online-Hilfe, der zweite Schalter, mit x verse hen, wird für das Schließen der Maske verwendet. Die Paramet riermaske beinhaltet unterschiedliche Eingabesektoren. Im obersten Eingabesektor kann die entsprechende Achse ausge wählt werden mit Hilfe eines Eingabemenüs (dargestellt durch einen Eingabeknopf mit einem kleinen auf dem Kopf stehenden Dreieck) können im Eingabefenster die entsprechenden Achsen ausgewählt werden. In diesem obersten Sektor ist links oben auch das zu diesem Befehl dazugehörige graphische Symbol an gegeben, nämlich ein auf dem Kopf stehendes Dreieck mit der Spitze nach unten, das waagrecht mittig mit einer dunklen Li nie versehen ist, wobei an den Enden dieser Linie jeweils nach unten abgeschrägte weitere kleine Linien angebracht sind. Der nächste und größte Sektor der Parametriermaske stellt die Möglichkeiten dar, Parameter einzugeben. Die Para meter sind, je nach Befehl, unterschiedlich. Sie werden über benamte Reiter, die auf einer Reiterleiste angeordnet sind, wie in gängigen Programmoberflächen üblich, logisch sortiert. Die erste Seite (in Fig. 7 ist diese Seite durch den Reiter "Parameter" aufblendbar) trägt üblicherweise die Parameter, die unbedingt zur Parametrierung des Befehls angegeben werden müssen. Für den Befehl "Positioniere Achse" ist ein unbeding ter Parameter z. B. die Zielposition einer Achsbewegung.

Die Anzahl und Bedeutung der Reiter ist befehlsabhängig un terschiedlich. In Fig. 7 ist dargestellt, dass für den Befehl "Positioniere Achse" neben dem Reiter "Parameter" noch ein Reiter "Dynamic" vorhanden ist. Mit diesem Reiter können für die Beschreibung des dynamischen Verhaltens Eingaben zu Ruck und Beschleunigung sowie zum Geschwindigkeitsprofil gemacht werden. Diese Eingaben können über Eingabefelder und dazuge hörigen Menüs gemacht werden. In Abbildung von Fig. 7 wurde als Geschwindigkeitsprofil die Trapezform gewählt. Diese Form wurde auch graphisch in der Mitte dieses Eingabesektors sti lisiert dargestellt. Im unten darauffolgenden Eingabesektor der Parametriermaske können weitere Eingaben, z. B. für das Übergangsverhalten, gemacht werden. Im Beispiel von Fig. 7 wurde für das Übergangsverhalten "Ablösen" eingegeben. Zu sätzlich können Wartebedingungen eingegeben werden, indem das Kästchen "Warten" mit einem Häkchen versehen wird. Zu diesem Synchronisieren können in einem dazugehörenden Eingabefenster weitere Eingaben gemacht werden. Im Beispiel nach Fig. 7 wurde "Positionsfenster erreicht" dafür eingegeben. Auch diese Ein gaben werden durch stilisiert dargestellte Achsprofile unter stützt. Das untere Ende einer Parametrierachse besteht aus vier Eingabeknöpfen, nämlich einem "OK"-Knopf, einem "Abbre chen"-Knopf, einem "Übernehmen"-Knopf und einem "Hilfe"- Knopf. Mit Hilfe dieser Eingabeknöpfe können Anwender entwe der die Eingaben übernehmen, bestätigen, verwerfen oder die Eingabehilfe aufrufen. Mit Hilfe der Wartebedingungen können durch einen Anwender sogenannte Weiterschaltbedingungen spe zifiziert werden, die Funktionen (z. B. Referenzpunktfahren oder Achspositionieren) bzw. ihr Zusammenspiel synchronisie ren.

Solche Parametriermasken existieren dediziert für alle Befeh le, die mit Hilfe des Flow Chart-Editors eingegeben und bear beitet werden können. Der Anwender wird also kontextsensitiv mit Hilfe dieser Parametriermasken bei der Programmierung seiner Bewegungs- und Steuerungsabläufe unterstützt.

Die Darstellung gemäß Fig. 8 zeigt in einem Übersichtsbild, wie der Sprachvorrat FEV des Flow Chart Editors FE erweitert wird. In der Ausgangssituation stehen einem Anwender A1 (dar gestellt durch ein Strichmännchen) die grafischen Elemente E1 bis Em des Flow Chart Editors FE zur Verfügung. Der Flow Chart Editor FE ist in der Darstellung gemäß Fig. 8 links oben als Rechteck dargestellt, das angedeutet grafische Elemente beinhaltet. Der Flow Chart Editor FE ist Teil eines Enginee ring Systems ES1, dargestellt durch eine gestrichelte Linie. Das Engineeringsystem ES1 enthält noch weitere Elemente, die aber aus Gründen der Übersichtlichkeit nicht dargestellt sind. Der Sprachvorrat FEV des Flow Chart Editors FE, der in der Ausgangssituation die grafischen Elemente E1 bis Em ent hält, ist rechts oben in Fig. 8 als Rechteck dargestellt.

Die untere Hälfte von Fig. 8 zeigt einen Anwender A2 (eben falls dargestellt durch ein Strichmännchen) der auf der Structured Text Ebene (ST; Fig. 3) mit einem Engineering Sys tem ES2 arbeitet. Auf der Structured Text Ebene (ST; Fig. 3) stehen dem Anwender A2 innerhalb des Structured Text Editors STED die Structured Text Sprachelemente STE1 bis STEn zur Verfügung, die den Sprachvorrat STEDV des Structured Text E ditors darstellen. Auch der Sprachvorrat STEDV des Structured Text Editors STED ist als Rechteck dargestellt. Mit Hilfe der Sprachelemente STE1 bis STEn kann der Anwender A2 im Structured Text Editor STED Unterprogramme STUP erstellen. Diese Un terprogramme STUP werden über einen Umsetzer (z. B. durch ei nen Compiler C) in grafische Sprachelemente des Flow Chart Editors FE umgesetzt.

In Fig. 8 ist links unten skizzenhaft dargestellt, wie diese Generierung grafischer Elemente erfolgt. Beispielhaft erfolgt die Umsetzung innerhalb des Engineering Systems ES2. Das Structured Text Unterprogramm STUP (schematisch dargestellt durch eine Abfolge von Structured Text Elementen aus dem Sprachvorrat STEDV des Structured Text Editors wird durch den Compiler C (dargestellt durch ein Rechteck mit einer Diago nallinie) umgesetzt in das grafische Element En, das auch die Funktionsschnittstelle des ursprünglichen Structured Text Un terprogramms enthält. Der Umsetzvorgang (Structured Text Edi tor → Compiler → grafisches Element) ist dabei schematisch angedeutet durch zwei waagrecht verlaufende Pfeile. Durch den Zuordnungspfeil ZP ist angedeutet, dass das neu generierte grafische Element En den Sprachvorrat FEV des Flow Chart Edi tors FE erweitert und dem Anwender A1 für dessen Flow Chart Programmierung zur Verfügung steht.

Auch das Engineeringsystem ES2 enthält noch weitere Elemente, die aber aus Gründen der Übersichtlichkeit nicht dargestellt sind. Für den beschriebenen Mechanismus ist es außerdem vor stellbar, dass sich die Funktionalitäten der Engineering Sys teme ES1 und ES2 in einem einzigen Engineering System befin den können. Auch können die beiden Anwender A1 und A2 durch eine einzige Person repräsentiert werden.

Die Darstellung gemäß Fig. 9 zeigt eine Auswahl von Sprachele menten (so genannten Icons) des Flow Chart-Editors. Diese Sprachelemente repräsentieren Befehle, die der Anwender bei der graphischen Programmierung im Flow Chart-Editor benutzen kann. Der MCC-Flow Chart-Editor unterstützt folgende Klassen von Befehlen und stellt für die einzelnen Befehle dieser Klassen jeweils entsprechende Symbole zur Verfügung:
Start-Befehle, Stop-Befehle, Positionierbefehle, Gleichlauf- und Kurvenscheiben-Befehle, Messtaster und SW-Nocken-Befehle, Warte-Befehle, Tasksteuer-Befehle, Befehle für die Manipulie rung von Variablen sowie weitere allgemeine Befehle. Außerdem stellt der MCC-Flow Chart-Editor weitere grafischen Kontroll strukturen für den grafischen Programmablauf zur Verfügung.

Claims

1. Verfahren für das Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, wobei ein An wender mit einem Editor grafische Elemente, insbesondere Kon trollstrukturen und Funktionsblöcke, zu einem auf einer An zeigeeinrichtung visualisierbaren Flow Chart (MCC) verknüpft, gekennzeichnet durch die folgenden Verfah rensschritte:

a) vom Anwender wird ausgehend vom Flow Chart ein Debug- Vorgang vorbereitet,
b) dadurch wird jedem grafischen Element (E1-En) ein Suspend-Befehl zugeordnet,
c) der Debug-Vorgang wird gestartet,
d) der Programmablauf folgt bis zum unmittelbar folgenden Suspend-Befehl,
e) dem Anwender (A1, A2) wird visualisiert, wo im Flow Chart die aktuelle Flow Chart befindlich ist,
f) der Anwender startet das Fortschalten zum nächst mögli chen Suspend-Befehl,
g) die Schritte d) bis f) werden solange fortgeführt, bis das Flow Chart-Ende erreicht ist.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass ein durch einen Suspend-Befehl angehaltenes grafisches Element, bzw. die zu diesem Element gehörige Task mit einem Tasksteuermechanismus des Run-Time-Systems (RTS) fortgesetzt wird.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass der Anwender im Engineering System (ES, ES1, ES2) über den Tasksteuermechanismus des Run-Time-Systems (RTS) einen Resume-Befehl bedient, der den aktuellen Suspend-Befehl fort schaltet.

4. Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass der Tasksteuermechanismus des Run-Time-Systems (RTS) über vom Anwender im Engineering System (ES, ES1, ES2) vorbe legbare Variablen in Form eines Breakpoint-Debuggings verwen det wird.

5. Verfahren nach Anspruch 1, 2, 3 oder 4, dadurch gekennzeichnet, dass die Variablenvorbelegungen im Tasksteuermechanismus durch andere Programme des Run-Time-Systems (RTS) erfolgen.

6. Verfahren nach einem der vorstehenden Ansprüche, gekennzeichnet durch die aufeinander fol genden Schritte:

a) aus dem Flow Chart wird eine textuelle Sprache (ST) er zeugt,
b) die textuelle Sprache (ST) wird in einen prozessorunab hängigen Zwischencode kompiliert,
c) der prozessorunabhängige Zwischencode wird auf die Steu erung geladen,
d) der prozessorunabhängige Zwischencode wird in ablauffä higen Prozessorcode umgesetzt.

7. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass dem Anwender auf Ebene der textuellen Sprache (ST) und/oder auf Ebene des Zwischencodes und/oder auf Ebene des Prozessorcodes jeweils eine Debug-Schnittstelle zur Verfügung steht.

8. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass dem Anwender im Flow Chart-Editor, in Abhängigkeit von der zugrundeliegenden Maschinenprojektierung und/oder Hard warekonfiguration adäquate Sprachmechanismen zur Verfügung gestellt werden.

9. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass aus anwenderdefinierten Unterprogrammen (STUP) der tex tuellen Sprache (ST) automatisch über einen Umsetzer (C) nach Art eines Compilers weitere grafische Elemente (E1-En) in Flow Chart-Notation (MCC) generiert werden, welche die Funk tionsschnittstelle der entsprechenden Unterprogramme (STUP) enthalten und die dem Anwender (A1, A2) ebenfalls zur Verfü gung gestellt werden.

10. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die automatisch generierten grafischen Elemente (E1-En) vom Anwender (A1, A2) als Sprachelemente des Flow Charts (MCC) verwendet werden.

11. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass als textuelle Sprache (ST) Structured Text nach IEC 6- 1131 verwendet wird.

12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass ein Anwender zum Formulieren von Bedingungen beliebig zwischen den Darstellungsformen textuelle Sprache (ST), Kon taktplan (KOP) und/oder Funktionsplan (FUP) wechseln kann.

13. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) als Sprachelemente min destens eine Schleife und/oder mindestens eine Parallelver zweigung vorhanden sind.

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass innerhalb der jeweiligen Parallelverzweigung die einzel nen Befehle im selben Interpolatortakt gestartet werden.

15. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) die Funktionsblöcke durch Maskeneingabe parametriert werden.

16. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) Funktionsblöcke zu Mo dulen zusammengefasst werden, die wiederum als Funktionsblö cke erscheinen.

17. Verfahren nach Anspruch 16, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) Module ineinander ge schachtelt werden.

18. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) dem Anwender in den Funktionsblöcken für die Variablenzuweisung jeweils mehrere Zuweisungen möglich sind.

19. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass in der Flow Chart-Notation (MCC) die Funktionsblöcke, die Funktionen repräsentieren, die eine Zeitdauer beanspru chen, Weiterschaltbedingungen enthalten.

20. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die grafischen Elemente (E1-En) des Flow Charts automa tisch positioniert werden.

21. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die grafischen Elemente (E1-En) des Flow Charts automa tisch miteinander verbunden werden.

22. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass das Flow Chart in der Anzeige verkleinert oder vergrö ßert dargestellt wird.

23. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass durch Markierungen in der textuellen Sprache eine Rück übersetzung in Flow Chart-Notation (MCC) möglich ist.

24. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Schritte a) bis c) in einem Sammelschritt ausgelöst werden.

25. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass während der Abarbeitung des Flow Chart Programms das je weils aktuelle grafische Element (E1-En) optisch auf der An zeigeeinrichtung gekennzeichnet wird.