DE19853967A1 - Verfahren zur Steuerung von Projektierwerkzeugen für Automatisierungssysteme - Google Patents

Abstract

Verfahren zur Steuerung von Projektierwerkzeugen für Automatisierungssysteme über eine Batch-Schnittstelle, durch die ausgewählte Objekte und Funktionen der Anwendungsschnittstelle (API) durchgereicht werden.

Description

Problem

Mit heutigen Programmier- und Projektierwerkzeugen für speicherprogrammierbare Steuerungen lassen sich die Funktionen nur über eine (graphische) Bedienoberfläche anstossen.

Funktionen, die heute nur über die Oberfläche der Projektierungswerkzeuge durchführbar sind, sollen auch durch Batchfiles steuerbar sein.

Lösung

Die Lösung ist in der Spezifikation in der Anlage niedergelegt. Steuerung des Projektierwerkzeugs über eine Batch-Schnittstelle:
Über das in dieser Erfindungsmeldung aufgeführten Verfahren

• - können neue Konfigurationen erstellt werden,
• - können in einer bestehenden Station neue Baugruppen, DP-Slaves und Baugruppenträger eingefügt und gelöscht werden,
• - können Baugruppeneigenachaften geändert werden,
• - sind Baugruppenparameter (z. B. Meßbereich) ermittelbar und änderbar,
• - kann die Konfiguration in das Zielsystem geladen werden.

STEP 7 V5.0 Systemmanual für Kommando-Schnittstelle Plattform Zusammenfassung

Dieses Dokument wendet sich an Tester und Anwender der Kommando-Schnittstelle für STEP 7. Es beschreibt die Kommando-Schnittstelle, d. h. das Objektmodell sowie die Properties und Methoden der Kommando-Schnittstellen-Objekte, und enthält einige weitere Hinweise, die beim Erstellen von STEP 7-Kommando-Skripten beachtet werden sollten.

- Confidential -

Disclosing this document to third parties, copying it, using or disclosing its cortents is prohibited, unless it has expressively been permitted. Any infringement will lead to damage Gaims. All rights reserved for the case of patent granting and/or utility model registration.

Historie

• 1. Allgemeines
• 2. Objektmodell
• 3. Das Einstiegsobjekt
  • 1. 3.1. Interface ISimatic
• 4. Collections
  • 1. 4.1. Projects Collection - Interface IS7Projects
  • 2. 4.2. Programs Collection - Interface ISTPrograms
  • 3. 4.3. "Next" Collection - Interface ISTSWItems
  • 4. 4.4. OnlineBlocks Collection - Interface IS7OnlineBlocks
  • 5. 4.5. Stations Collection - Interface IS7Stations
• 5. API-Objekte
  • 1. 5.1. Projekt - Interface ISTProject
  • 2. 5.2. Programm - Interface IS7Program
  • 3. 5.3. Symboltabelle - Interface ISTSymbolTable
  • 4. 5.4. NextObject - Interface ISTSWItem
    • 1. 5.4.1. Quelle - Interface IS7Source
    • 2. 5.4.2. Baustein - Interface IS7Block
    • 3. 5.4.3. Plan - Interface IS7Plan
    • 4. 5.4.4. Software-Container - Interface IS7Container
• 6. Weitere Hinweise

1. Allgemeines

Funktionen, die heute über die Oberfläche der Projektierungswerkzeuge durchführbar sind, sollen auch durch ein Batchfile (Visual Basic Skript) steuerbar sein.

Die Kommando-Schnittstelle ist eine OLE-Automation-Schnittstelle, durch die ausgewählte Objekte und Funktionen des AUT-APIs angesprochen werden können. Sie kann über eine OLE-Automation-fähige Skriptsprache wie z. B. Visual Basic genutzt werden. Außerdem können kundenspezifische (zusätzliche) Oberflächen für das Projektiersystem in jeder OLE- Automation-fähigen Programmiersprache (VB, VC++, J++, . . .) entwickelt werden.

Es ist jedoch nicht das Ziel, mit der Kommando-Schnittstelle die volle Breite des AUT-APIs in anderer Form durchzureichen. Es besteht nicht der Anspruch, beliebige STEP 7- Projektierwerkzeuge mit der Kommando-Schnittstelle realisieren zu können. Es wird also nicht das gesamte Objektmodell und nicht die gesamte Funktionaliät des AUT-APIs als OLE- Automation-Schnittstelle angeboten, sondern nur ein Ausschnitt. Eine Reihe von Funktionen des AUT-APIs wird über die Kommando-Schnittstelle nicht zu erreichen sein. Object-Sets, ODs, Object-Handles und Links tauchen am Interface nicht explizit auf, sondern werden von der Kommando-Schnittstelle implizit hantiert. Unterstützt werden generell das Erzeugen und Löschen von Objekten, das Navigieren durch das Objektmodell und Zugriffe auf ausgewählte Attribute.

Um die STEP 7-Kommando-Schnittstelle von Visual Basic aus anzusprechen, muß das Visual Basic Skript eine Referenz auf die "Simatic 1.0 Type Library" erhalten. Außerdem muß das S7Bin-Verzeichnis (z. B. C:\Siemens\Step7\S7Bin) in den Suchpfad (z. B. Path-Variable im autoexec.bat bei Win95) aufgenommen werden.

2. Objektmodell

Die folgende Abbildung zeigt das Objektmodell der Kommando-Schnittstelle:
Wie man sieht, sind beispielsweise Netze, Dokumentation, Meldungen und Prozeßvariablen im Objektmodell nicht enthalten. Diese Objekte können über die Kommando-Schnittstelle nicht angesprochen werden.

3. Das Einstiegsobjekt

. . . ist das Objekt "Simatic". Es ist das einzige Objekt der Kommando-Schnittstelle, das ole- creatable ist (also von Visual Basic aus mit New instanziiert werden kann). Alle anderen Objekte der Kommando-Schnittstelle können nur über Properties und Methoden anderer Kommando-Schnittstellen-Objekte erreicht werden. Daher muß jeder Anwender der Kommando-Schnittstelle zuerst ein Simatic-Objekt erzeugen:
Dim S As Object
Set S = New Simatic

Es besitzt als einzige Property eine Collection - die Projektliste.

3.1. Interface ISimatic Properties

IS7Projects* Projects [read only]

Methoden 4. Collections

OLE Automation Collections sind Mengen von Objekten. Sie ermöglichen es, auf die in ihnen enthaltenen Objekte - im Fall der Kommando-Schnittstelle API-Objekte - gezielt (z. B. über einen Namen) zuzugreifen oder über alle in ihnen enthaltenen Objekte zu iterieren.

In dem Microsoft-Papier "Implementing OLE Automation Collections" von Charlie Kindel werden Collections wie folgt definiert:
The Microsoft® Excel version 5.0 Visual Basic Programmer's Guide defines an OLE Automation collections as follows:
"A group of objects. An object's position in the collection can change whenever a change occurs in the collection. Therefore, the position of any specific object in the collection is unpredictable. This unpredictability distinguishes a collection from an array."
. . . The defining characteristic of a collection is the ability to iterate over the items contained in the collection. An item is any thing that can be accessed via an OLE Automation interface.
. . . It is still useful to be able to access individual windows in the list by name or index, and even iterate over all of the windows. Collections provide a mechanism for doing just this . . .
Typically (but not always), an arbitrary item or object in an application can be identified through both a human- readable name and some sort of indexing. For example, a user could find a window in a collection using its name (typically a string representing its caption) or by using a number (representing its position in the z-order).

Die Collections der Kommando-Schnittstelle realisieren - soweit bei den einzelnen Collections nichts anderes beschrieben wird - generell ein einheitliches Interface.

Properties

long Count [read only]
Iltem* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

IItem* Add (BSTR Name, . . . weitere Parameter . . .)
void Remove (VARIANT Index)

Zur Notation: IItem steht dabei für das Interface der API-Objekte, die in der Collection enthalten sind.

Count liefert die Anzahl der Objekte, die in der Collection enthalten sind.

Mit Item () kann man (mehr oder weniger) gezielt auf ein einzelnes Objekt der Collection zugreifen. Der Variant-Parameter identifiziert dabei das Objekt und kann entweder numerisch oder ein String sein.

Numerische Indizes laufen dabei in Visual Basic von 1 bis Count (und nicht, wie in C, von 0 bis Count-1). Zu beachten ist weiterhin, daß die Indizierungs-Reihenfolge völlig undefiniert ist und sich auch während des Programm-Ablaufs jederzeit ändern kann. Hinzu kommt, daß das Iterieren über numerische Indizes an der Kommando-Schnittstelle langsamer ist als das Iterieren mit_NewEnum. Daher sollte numerisches Indizieren generell vermieden werden.

Wird mit Strings indiziert, so handelt es sich dabei generell um den Namen des Objekts. Die Indizierung über Namen setzt dabei voraus, daß innerhalb der jeweiligen Collection die Objekt-Namen eindeutig sind. Dies wird nicht in jedem Fall vom System sichergestellt, sondern muß ggf. vom Anwender z. B. durch geeigneten Aufbau des Projekts sichergestellt werden.

Das Item-Property hat die Default-Dispatch-ID (0). Daher muß der Property-Name Item nicht explizit notiert werden. Um auf das Projekt S7_ZEBRA zuzugreifen, kann man daher statt
Dim S As Object
Dim Proj As Object
Set S = New Simatic
Set Proj = S.Projects.Item ("S7_ZEBRA")
auch einfacher
Dim S As Object
Dim Proj As Object
Set S = New Simatic
Set Proj = S.Projects ("S7_ZEBRA")
notieren.

_NewEnum erzeugt ein Objekt, das das Interface IEnumVARIANT unterstützt. Mit diesem Objekt kann über sämtliche Objekte in der Collection iteriert werden._NewEnum wird dabei vom Anwender nicht direkt aufgerufen, sondern von Visual Basic implizit im Rahmen des Statements For-Each-In-Next hantiert.

Beispiel: Das folgende VB-Programm gibt für alle vorhandenen Projekte Name, Projektverzeichnis und Anzahl der im Projekt enthaltenen Programme (S7- oder M7- Programme) in einer Messagebox aus:

Zu beachten ist beim Iterieren mit_NewEnum, daß die Objekte, die in die Iteration einbezogen werden, nur einmal beim Aufruf des_NewEnum ermittelt werden. Wenn also in einer For-Each-Schleife zusätzliche Objekte in der Collection erzeugt werden, so ist nicht sichergestellt, daß sie im Rahmen dieses Schleifen-Durchlaufs auch noch erreicht werden. Weiterhin dürfen in einer For-Each-Schleife keine Objekte gelöscht werden, die zu dieser Collection gehören (mit Ausnahme des gerade durchlaufenen Objekts).

Die Methode Add () erzeugt ein neues Step 7-Objekt. Die benötigten Parameter des Aufrufs hängen dabei vom jeweiligen Objekttyp ab.

Die Methode Remove () löscht ein Objekt. Es handelt sich dabei nicht nur um ein Freigeben einer OLE-Referenz, sondern das Objekt wird aus dem Projektbaum entfernt. Der Variant- Parameter Index entspricht dabei dem Parameter der Methode Item ().

Die folgenden Ausführungen zu den einzelnen Collections beschreiben lediglich die Besonderheiten und Abweichungen gegenüber den obigen allgemeinen Ausführungen.

4.1. Projects Collection - Interface IS7Projects

Diese Collection enthält Projekte und Bibliotheken - jedoch nur diejenigen, die auch im Simatic Manager in der Projektliste (Dialog nach Datei→Öffnen) angezeigt werden. Verborgene Projekte (die z. B. mit Datei→Verwalten→Verbergen aus der Projektliste ausgeblendet wurden), die zwar im Dateisystem noch vorhanden, aber nicht in der Projektliste enthalten sind und nur über Datei→Öffnen→Durchsuchen erreicht werden können, können über die Kommando-Schnittstelle nicht hantiert werden.
typedef enum { S7Project, S7Library } S7ProjectType;

Properties

long Count [read only]
IS7Project* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

IS7Project* Add (BSTR Name, BSTR ProjectRootDir [optional, defaultvalue ("")], S7ProjectType Type [optional,
defaultvalue (S7Project)])
void Remove (VARIANT Index)

Item () /Remove (): STEP 7 kann die Eindeutigkeit von Projektnamen nicht gewährleisten. Der Anwender wird in STEP 7 nicht daran gehindert, mehrere Projekte mit gleichem Namen (unter verschiedenen Ablage-Verzeichnissen) anzulegen. In diesem Fall ist bei Zugriff auf ein Projekt über den Projektnamen undefiniert, welches der verschiedenen Projekte mit gleichem Namen verwendet wird. Falls der Anwender die Eindeutigkeit der Projektnamen nicht gewährleisten kann, sollte er daher bei der Auswahl des Projekts mit For- Each über alle Projekte iterieren und anhand zusätzlicher Kriterien (wie etwa dem Projektpfad) prüfen, ob das gefundene Projekt auch wirklich das gewünschte ist.

Add (): Der Parameter Name enthält den zukünftigen Namen des Projekts, aus dem auch der Name des Projektverzeichnisses abgeleitet wird. Die übrigen Parameter sind optional, werden also ggf. durch geeignete Defaultwerte ersetzt. ProjectRootDir ist der absolute Pfadname des Verzeichnisses, unter dem das Projektverzeichnis abgelegt wird. Normalerweise wird man hier den Leerstring angeben - in diesem Fall wird das neue Projekt unter dem Verzeichnis angelegt, das im Simatic Manager als "Ablageort für Projekte" eingestellt worden ist (Extras→Einstellungen, Registerseite "Allgemein") - normalerweise also unter S7proj im Step 7-Installationsverzeichnis. Mit dem Parameter Type legt man fest, ob ein Projekt oder eine Bibliothek erzeugt werden soll. Das Datenablage-Format entspricht dabei immer dem V3.x-V5.x-Format. Über die Kommando-Schnittstelle können grundsätzlich keine V2.x- Projekte erzeugt werden. Aufruf-Beispiel:
Set Proj = S.Projects.Add ("TestProj", "", S7Project)
oder gleichbedeutend
Set Proj = S.Projects.Add ("TestProj")

4.2. Programs Collection - Interface IS7Programs

Beim Bearbeiten von Projekten mit dem Simatic Manager können Programme entweder

• - direkt unter das Projekt, d. h. unabhängig von irgendwelcher Hardware, oder aber
• - unter einer CPU

abgelegt werden. Beim Erzeugen einer CPU wird automatisch ein zugeordnetes S7- Programm erzeugt.

Die Programs-Collection der Kommando-Schnittstelle enthält alle Programme eines Projekts - S7- wie M7-Programme -, und zwar völlig unabhängig davon, ob sie im Simatic Manager direkt unter dem Projekt oder unter einer CPU angezeigt werden. Für die Kommando- Schnittstelle hängen alle Programme immer unter dem Projekt, der Umweg über die CPU ist beim Navigieren zum Programm nicht erforderlich.
typedef enum { S7, M7 } S7ProgramType.

Properties

long Count [read only]
IS7Program* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

IS7Program* Add (BSTR Name, S7ProgramType Type [optional, defaultvalue (S7)])
void Remove (VARIANT Index)

Item () /Remove (): STEP 7 kann die Eindeutigkeit von Programmnamen nicht gewährleisten. Der Anwender kann im Simatic Manager erzwingen, daß unter verschiedenen CPUs mehrere S7-Programme mit demselben Namen hängen. In der Kommando-Schnittstelle erscheinen diese S7-Programme dann alle in derselben Collection - mit demselben Namen.

Neben den bei anderen Collections üblichen Weisen der Indizierung (konventioneller numerischer Index oder Objektname) kann man hier als Index auch ein Hardware-Objekt (z. B. Modul oder Station) übergeben. In diesem Fall wird auf das Programm zugegriffen, das unter diesem Hardware-Objekt hängt. Zum gezielten Zugriff auf ein Programm über eine Station könnte also z. B.
Proj.Programs (Proj.Stations ("Simatic 300 (1)"))
notiert werden. Wenn eine Station mehrere CPUs enthält, muß man hier selbstverständlich statt der Station die CPU übergeben, um ein Programm eindeutig zu bestimmen. Mit der Indizierung über Hardware-Objekte können Programme auch dann noch eindeutig referenziert werden, wenn die Programmnamen nicht projektweit eindeutig vergeben worden sind.

Add (): Die an der Collection erzeugten Programme hängen immer direkt unter dem Projekt. Es ist nicht möglich, mit Mitteln der Kommando-Schnittstelle eine Zuordnung von einem bestehenden Programm zu einer CPU zu treffen oder aufzuheben. Wenn ein Programm unter einer CPU benötigt wird, so braucht es nicht mit Add an der Programs-Collection erzeugt zu werden, sondern es wird beim Erzeugen einer CPU automatisch mit angelegt. Beim Add ist anzugeben, ob es sich um ein S7- oder um ein M7-Programm handeln soll - generische Ressourcen können mit der Kommando-Schnittstelle nicht hantiert werden.

4.3. "Next" Collection - Interface IS7SWItems

Die zu einem Programm gehörenden Elemente Offline-Bausteine, Quellen und CFC-Pläne werden als Software-Items bezeichnet. Zur hierarchischen Strukturierung gibt es weiterhin noch Container, die ebenfalls selbst als Software-Item gelten. Das Kommando-Schnittstellen- Objektmodell sieht dabei vor, daß sowohl das Programm selbst als auch die Container eine Collection-Property "Next" enthalten, die beliebige Software-Items enumeriert. Auf diese Weise können unter einem Programm beliebige, mehrstufige Baumstrukturen mit Containern als Verzweigungspunkten modelliert werden.

Das STEP 7-Objektmodell V5 enthält demgegenüber jedoch Einschränkungen: Bausteine können nur in Baustein-Containern liegen, Sourcen nur in Source-Containern, und Pläne nur in Plan-Containern, und diese Container können auch selbst keine Container enthalten. Programme enthalten nur maximal einen Container von jedem Typ. Auf diese Weise ergibt sich eine feste dreistufige Hierarchie Programm - Container - Blatt-Objekt (Source, Plan, Baustein). Dieses Objektmodell ist ein Spezialfall des Kommando-Schnittstellen- Objektmodells, und es ist zu V5 auch mit dem Kommando-Schnittstellen-Objektmodell nicht möglich, andere Strukturen als die in STEP 7 V5 zugelassenen zu modellieren.

Das Programm enthält also eine Next-Collection IS7SWItems, die üblicherweise je einen Source- und Baustein-Container enthält (falls nicht mit CFC gearbeitet wird). Beide Container enthalten wiederum eine Next-Collection, die dann die eigentlichen Quellen bzw. Bausteine enthält.

Als Beispiel das Instanzmodell des S7-Programms aus dem Projekt "S7_MIX":

Der Zugriff auf einen Baustein bzw. die Source erfolgt hier beispielsweise mit
Set Blk = Prg.Next ("Blocks").Next ("OB1")
Set Src = Prg.Next ("Source Files").Next (1)

Die Member "Next" repräsentieren dabei jeweils die Collection IS7SWItems. Es kann wie üblich numerisch oder über den Objektnamen indiziert werden.
typedef enum { S7Block, S7Container, S7Source, S7Plan } S7SWObjType.

Properties

long Count [read only]
IS7Program* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

IS7SWItem* Add (BSTR Name, S7SWObjType Type, BSTR Filename) void Remove (VARIANT Index)

Add (): Mit dem Parameter "Type" wird angegeben, was für eine Art von Objekt - Baustein, Container, Quelle oder Plan - angelegt werden soll. Derzeit ist das Erzeugen von Items via Add nur für Sourcen zulässig. Add fegt dabei kein leeres Objekt an, sondern importiert gleichzeitig den Inhalt des Objekts aus einer zuvor irgendwie angelegten Export-Datei. Im Parameter "Filename" ist der vollständige Pfadname dieser Export-Datei anzugeben. Im folgenden Beispiel wird eine Quelle aus dem Beispiel-Projekt "S7_Mix" in ein neues Projekt importiert:

Item ()/Remove (): Wie üblich wird die Eindeutigkeit der Namen vom System nicht erzwungen, sondern liegt in der Verantwortung des Anwenders. Beispielsweise könnte der Anwender beim Anlegen des Projekts Source- und Baustein-Container denselben Namen geben.

4.4. OnlineBlocks Collection - Interface IS7OnlineBlocks

Die Collection IS7OnlineBlocks enumeriert über alle tatsächlich auf der realen, dem Programm zugeordneten CPU online vorhandenen Bausteine. Die Verwendung dieser Collection setzt voraus, daß eine passende CPU angeschlossen und erreichbar ist. Es gibt keine Add-Methode. Die einzige Möglichkeit, einen Baustein auf die CPU zu bringen, ist daher der Download eines Offline-Bausteins.
typedef enum { S7OverwriteAsk, S7OverwriteAll,
S7OverwriteNone } S7OverwriteFlags.

Properties

long Count [read only]
IS7Block* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

void Remove (VARIANT Index)
void Upload (S7OverwriteFlags Overwrite [optional, defaultvalue (S7OverwriteAsk)])

Im Gegensatz zu den übrigen Collections besitzt die OnlineBlocks-Collection zusätzlich noch die Methode "Upload". Damit können mit einem einzigen Aufruf alle Online-Bausteine hochgeladen und in den Offline-Bausteincontainer kopiert werden. Der Anwender könnte natürlich auch mit der Collection über alle Online-Bausteine enumerieren und bei den einzelnen Bausteinen dann einzelne Upload-Vorgänge anstoßen.

Über den optionalen Parameter Overwrite kann der Anwender festlegen, wie verfahren werden soll, wenn der zu ladende Baustein im Ziel (also offline) bereits existiert. Defaultmäßig wird ein Dialog präsentiert, in dem der Anwender das weitere Verhalten interaktiv festlegen kann. Er kann jedoch auch via Parameter Overwrite spezifizieren, daß im Ziel bereits existierende Bausteine im Rahmen des Ladevorgangs immer bzw. niemals überschrieben werden sollen.

Die Download-Methode befindet sich übrigens nicht an der OnlineBlocks-Collection, sondern am (offline) Software-Container, da es in diesem Fall vorhandenen Offline-Bausteine sind, die in die Online-Welt kopiert werden.

Im folgenden ein Beispiel, mit dem festgestellt wird, welche Bausteine auf der CPU vorhanden sind:

4.5. Stations Collection - Interface IS7Stations

Diese Collection enumeriert über alle unter dem Projekt hängenden Hardware-Stationen.
typedef enum { S7300Station, S7400Station, S7HStation, S7PCStation } S7StationType.

Properties

long Count [read only]
IDispatch* Item (VARIANT Index) [read only]
IUnknown*_NewEnum [read only]

Methoden

IDispatch* Add (BSTR Name, S7StationType Type)
IDispatch* Import (BSTR PathName)
void Remove (VARIANT Index)

Add ()/Import ()/Item (): Das Stations-Objekt hat das Interface IS7Station. Die Collection IS7Stations verwendet jedoch statt dieses (spezifischen) Interfaces lediglich das generische Dispatch-Interface.

Import (): Mit dieser Methode kann eine neue Station (incl. Racks, Baugruppen etc.) in das Projekt eingefügt werden anhand einer Import-Datei, die zuvor via IS7Station::Export () erzeugt worden ist.

Die Stations-Objekte IS7Station selbst werden in einem separaten Dokument beschrieben.

5. API-Objekte

Bei den übrigen, bisher noch nicht beschriebenen Objekten des Kommando-Schnittstelle handelt es sich um Proxy-Objekte für die Objekte des AUT-APIs (HOBJECTs). Die "eigentlichen" AUT-API-Objekte "leben" nach wie vor in dem zuständigen Object Manager (OM), die OLE-Proxy-Objekte setzen auf das AUT-API auf.

Die folgenden Properties und Methoden werden - soweit bei den einzelnen Objekten nicht anders beschrieben - von den API-Objekten generell einheitlich realisiert.

Properties

BSTR Name
BSTR LogPath [read only]
IParent* Parent [read only]

Methoden

void Remove ()
IItem* Copy (IDispatch* pParent)

Name: Der Name eines API-Objekts kann grundsätzlich nicht nur abgefragt, sondern auch verändert werden.

LogPath: Der "Logische Pfad" enthält in irgendeiner Form eine Darstellung der Position, an der sich das Objekt innerhalb der Projekt-Hierarchie befindet. Struktur und Repräsentation des logischen Pfads sind versionsabhängig - hier wird keine Kompatibilität zwischen verschiedenen Versionen der Kommando-Schnittstelle garantiert.

Parent liefert eine OLE-Referenz auf das nächste übergeordnete API-Objekt im Kommando-Schnittstellen-Objektmodell. Auch diese Property ist read-only, d. h. die Position eines Objekts innerhalb des Projektbaums kann mit Mitteln der Kommando-Schnittstelle nicht geändert werden.

Remove () löscht das entsprechende Objekt - einschließlich der zugehörigen im Projektbaum unterlagerten Objekte.

Copy () legt eine Kopie des Objekts in einer neuen Umgebung an. Als Parameter wird das Vater-Objekt übergeben, unter dem die neue Kopie angelegt werden soll. Es dürfen dabei nur Objekte als Parent verwendet werden, die nach dem Kommando-Schnittstellen- Objektmodell noch ein Objekt dieses Typs als zusätzliches Kind "vertragen". Das folgende Beispiel kopiert eine Symboltabelle aus einem der Beispielprojekte in ein neu angelegtes Projekt (und ruft danach den Symbol-Editor für die Kopie auf):

Darüberhinaus enthalten die API-Objekte Referenzen auf die gem. Kommando- Schnittstellen-Objektmodell unterlagerten Collections in Form von read-only-Properties zwecks Navigation durch den Projektbaum.

5.1. Projekt - Interface IS7Project

typedef enum { S7Project, S7Library } S7ProjectType.

Properties

BSTR Name
BSTR LogPath [read only]
S7ProjectType Type [read only]
ISimatic* Parent [read only]
IS7Programs* Programs [read only]

Methoden

void Remove ()

Das Projekt enthält keine Copy-Methode!

LogPath enthält - im Gegensatz zur Realisierung dieses Properties bei den übrigen Objekten - nicht die Position des Projekts innerhalb des Projektbaums - es ist ja klar, daß es sich hierbei um die Wurzel handelt -, sondern den absoluten Pfadnamen des Projektverzeichnisses.

Type enthält die Angabe, ob es sich um ein Projekt oder um eine Bibliothek handelt.

Parent verweist auf das Applikations-Objekt ISimatic, da das Projekt ja unter keinem anderen API-Objekt hängt.

Programs ist eine Referenz auf eine Collection - auf die Liste aller Programme innerhalb des Projekts.

5.2. Programm - Interface IS7Program

typedef enum (S7, M7} S7ProgramType;
typedef enum { S7Run, S7Stop, S7Halt, S7Defect, S7Startup } S7ModState.

Properties

BSTR Name
BSTR LogPath [read only]
S7ProgramType Type [read only]
S7ModState ModuleState [read only]
IS7Project* Parent [read only]
IDispatch* Module [read only]
IS7SymbolTable* SymbolTable [read only]
IS7OnlineBlocks* OnlineBlocks [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7Program* Copy (IDispatch* pParent)
void NewStart ()
void Restart ()
void Stop ()
void Reset ()

LogPath enthält bei Programmen, die unter einer CPU hängen, auch Angaben zu übergeordneten Hardware-Komponenten (Station, CPU).

Type enthält die Angabe, ob es sich z. B. um ein S7- oder um ein M7-Programm handelt.

ModuleState enthält den Betriebszustand der zugeordneten Baugruppe (CPU). Dieses Property kann nur abgefragt werden für Programme, bei denen eine Online-Verbindung zur CPU hergestellt werden kann - also insbesondere grundsätzlich nicht für Programme, die direkt unter dem Projekt hängen.

Parent ist immer das Projekt - auch wenn das Programm unter einer CPU hängt.

Module verweist auf die CPU, der das Programm zugeordnet ist. Diese Property ist, read- only, d. h. die Zuordnung zwischen Programm und CPU kann mit Mitteln der Kommando- Schnittstelle nicht geändert werden. Die Module-Property liefert entweder Nothing (wenn das Programm nicht unter einer CPU, sondern direkt unter einem Projekt hängt) - dies gilt nicht als Fehler! - oder einen Verweis auf ein IS7Module-Interface. Die Kommando- Schnittstelle verwendet jedoch statt dieses (spezifischen) Interfaces lediglich das generische Dispatch-Interface. Die Modul-Objekte IS7Module selbst werden außerhalb der allgemeinen Kommando-Schnittstelle durch eine separate DLL s7hcom_x.dll aus dem Teilprojekt HW-Konfig realisiert und daher in diesem Dokument nicht beschrieben.

SymbolTable verweist auf die dem Programm zugeordnete Symboltabelle - falls eine existiert. Da es zu jedem Programm nur eine einzige Symboltabelle geben kann, wird hier keine Collection-Class zwischengeschaltet. Die Zuordnung zwischen Programm und Symboltabelle kann mit Mitteln der Kommando-Schnittstelle nicht verändert werden (kein Löschen oder Erzeugen einer Symboltabelle).

OnlineBlocks verweist auf die Collection mit den Online-Bausteinen auf der CPU.

Next verweist auf eine Collection, die typischerweise die Container für die Offline-Objekte (Bausteinbehälter, Source-Container, Plan-Container) enthält.

Auch mit Copy () kann man die Kopie eines Programms nur direkt unter einem Projekt ablegen und nicht einer CPU zuordnen. Als Parent-Parameter sind nur Projekte zulässig.

NewStart (), Restart (), Stop () und Reset () ändern den Betriebszustand der zugeordneten Baugruppe (CPU). Sie bewirken die Funktionen Neustart, Wiederanlauf, Stop und Urlöschen. Diese Aufrufe sind nur zulässig für Programme, bei denen eine Online- Verbindung zur CPU hergestellt werden kann. Die Kommando-Schnittstelle prüft dabei nicht, ob sich die CPU zum Aufruf-Zeitpunkt im für die Funktion zulässigen Zustand befindet.

5.3. Symboltabelle - Interface IS7SymbolTable

Symboltabellen hängen ohne Zwischenschaltung einer Collection direkt unter einem Programm. Sie können mit Mitteln der Kommando-Schnittstelle einzeln nicht erzeugt werden. Beim Anlegen eines Programms wird eine zugehörige Symboltabelle automatisch erzeugt.

Properties

BSTR Name
BSTR LogPath [read only]
IS7Program* Parent [read only]

Methoden

void Remove ()
IS7SymbolTable* Copy (IDispatch* pParent)
void Edit ()

Copy () verlangt als Parent-Parameter ein Programm.

Edit () ruft den Symbol-Editor auf. Kommando-Skript und Symbol-Editor werden dabei jedoch nicht miteinander synchronisiert, d. h. das Kommando-Skript läuft weiter (wartet nicht im Call Edit (), bis der Symbol-Editor geschlossen wird).

5.4. NextObject - Interface IS7SWItem

Unter dem Begriff "Software-Item" werden diverse Offline-Objekte, die unterhalb von Programmen liegen, subsumiert - speziell Bausteine, Quellen, Pläne und Behälter. Diese Objekte enthalten ein gemeinsames Interface IS7SWItem sowie spezielle, typ-abhängige Properties und Methoden.
typedef enum { S7Block, S7Container, S7Source, S7Plan } S7SWObjType.

Properties

BSTR Name
BSTR LogPath [read only]
S7SWObjType Type [read only]
IDispatch* Parent [read only]
IS7Program* Program [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7SWItem* Copy (IDispatch* pParent)

Type beinhaltet die Angabe, um was für eine Art von Objekt es sich genauer handelt. In Abhängigkeit von Type realisiert das Objekt spezielle Interfaces.

Parent verweist auf das Vater-Objekt innerhalb der Objekthierarchie. Es handelt sich dabei entweder um einen Container (bei Quellen, Plänen und Bausteinen) oder um ein Programm (bei Containern).

Program dagegen verweist - auch bei Quellen, Plänen und Bausteinen - in jedem Fall auf das übergeordnete Programm.

Next verweist auf die Collection mit den Software-Items der nächsten Hierarchiestufe. Diese Collection ist bei allen Objekten mit Ausnahme der Container immer leer.

Als Parent-Parameter bei Copy () sind hier grundsätzlich Objekte vom Typ SWItem oder Programme zulässig. Hierbei sind jedoch noch die weitergehenden Einschränkungen des STEP 7-Objektmodells zu beachten. Beispielsweise dürfen Quellen nicht unter einen Baustein-Container kopiert werden, Container dürfen nur direkt unter einem Programm hängen etc.

Insoweit die folgenden Interfaces eine Methode Edit () anbieten, ruft sie den zugeordnete Compiler (z. B. SKA für AWL-Quellen) auf. Kommando-Skript und Compiler werden dabei jedoch nicht miteinander synchronisiert, d. h. das Kommando-Skript läuft weiter (wartet nicht im Call Edit (), bis der SKA geschlossen wird).

5.4.1. Quelle - Interface IS7Source

typedef enum { S7Block, S7Container, S7Source, S7Plan } S7SWObjType;
typedef enum { S7AWL, S7SCL, S7GR7, S7SCLMake, S7GG, S7ZG, S7NET } S7SourceType.

Properties

BSTR Name
BSTR LogPath [read only]
S7SWObjType Type [read only]
S7SourceType ConcreteType [read only]
IDispatch* Parent [read only]
IS7Program* Program [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7SWItem* Copy (IDispatch* pParent)
void Edit ()
void Export (BSTR Filename)
IS7SWItems* Compile ()

ConcreteType liefert eine Verfeinerung der Angabe zu Type. Während Type nur zu entnehmen ist, daß es sich überhaupt um irgendeine Art von Quelle handelt, kann man anhand von ConcreteType eine weitere Unterscheidung nach der Sprache (z. B. AWL oder SCL) treffen.

Export () legt die Quelle in einer separaten Datei ab, aus der heraus es dann ggf. mit der Add-Methode vor. IS7SWItems wieder importiert werden kann.

Compile () stößt den Übersetzungsvorgang an. Er liefert eine Collection zurück, die die Referenzen der fehlerfrei übersetzten Bausteine beinhaltet. Diese Collection selbst ist statisch, d. h. sie darf nicht mit ihren Methoden Add oder Remove verändert werden. Derzeit wird diese Collection jedoch nur beim Übersetzen von AWL-Quellen gefüllt. Bei allen anderen Compilern ist sie immer leer. Auf die neu übersetzten Bausteine kann jedoch selbstverständlich noch in der üblichen Weise (Prg. Next ("Blocks"). Next ("OB1")) zugegriffen werden.

5.4.2. Baustein - Interface IS7Block

Das besondere an den Bausteinen ist, daß sie über zwei verschiedene Collections erreicht werden können: Im Offline-Fall über die Collections IS7SWItems, die Online-Bausteine (auf einer angeschlossenen, erreichbaren CPU) dagegen über IS7OnlineBlocks.
typedef enum (S7Block, S7Container, S7Source, S7Plan } S7SWObjType;
typedef enum { S7FB, S7FC, S7DB, S7OB, S7SDB, S7SDBs, S7UDT, S7SFC, S7SFB, S7VAT } S7BlockType;
typedef enum { S7OverwriteAsk, S7OverwriteAll, S7OverwriteNone } S7OverwriteFlags.

Properties

BSTR Name
BSTR LogPath [read only]
S7SWObjType Type [read only]
S7BlockType ConcreteType [read only]
IDispatch* Parent [read only]
IS7Program* Program [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7SWItem* Copy (IDispatch* pParent)
void Edit ()
void Download (S7OverwriteFlags Overwrite [optional, defaultvalue (S7OverwriteAsk)])
void Upload (S7OverwriteFlags Overwrite [optional, defaultvalue (S7OverwriteAsk)])

ConcreteType liefert eine Verfeinerung der Angabe zu Type. Während Type nur zu entnehmen ist, daß es sich überhaupt um irgendeine Art von Baustein handelt, kann man anhand von ConcreteType eine weitere Unterscheidung (z. B. Datenbaustein oder Organisationsbaustein) treffen. Die Kennung "S7SDBs" steht dabei nicht für den Typ eines einzelnen Bausteins, sondern für den "SDB-Container, d. h. für das Handle zur Sammlung aller Systemdatenbausteine.

Download () ist nur für Offline-Bausteine zulässig. Hierbei wird versucht, über eine Online- Verbindung die Bausteine auf die CPU zu kopieren.

Upload () dagegen ist nur für Online-Bausteine zulässig. Hierbei werden die Bausteine von der CPU in den Baustein-Container kopiert.

Über den optionalen Parameter Overwrite kann der Anwender bei beiden Methoden festlegen, wie verfahren werden soll, wenn der zu ladende Baustein im Ziel bereits existiert. Defaultmäßig wird ein Dialog präsentiert, in dem der Anwender das weitere Verhalten interaktiv festlegen kann. Er kann jedoch auch via Parameter Overwrite spezifizieren, daß im Ziel bereits existierende Bausteine im Rahmen des Ladevorgangs immer bzw. niemals überschrieben werden sollen.

5.4.3. Plan - Interface IS7Plan

typedef enum { S7Block, S7Container, S7Source, S7Plan) S7SWObjType;
typedef enum { S7CFCPlan } S7PlanType.

Properties

BSTR Name
BSTR LogPath [read only]
S7SWObjType Type [read only]
S7PlanType ConcreteType [read only]
IDispatch* Parent [read only]
IS7Program* Program [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7SWItem* Copy (IDispatch* pParent)
void Edit ()
IS7SWItems* Compile ()

ConcreteType könnte eine Verfeinerung der Angabe zu Type liefern. Während Type nur zu entnehmen ist, daß es sich überhaupt um irgendeine Art von Plan handelt, könnte man anhand von ConcreteType eine weitere Unterscheidung (z. B. CFC- oder SFC-Plan) treffen. Derzeit unterstützt die Kommando-Schnittstelle allerdings nur CFC-Pläne.

Compile () soll - analog zu den Sourcen - den Übersetzungsvorgang anstoßen. Die Compile-Anbindung wird jedoch seitens des Optionspakets CFC V4.x noch nicht realisiert.

5.4.4. Software-Container - Interface IS7Container

In STEP 7 V5.0 können Software-Container nur direkt unter einem Programm existieren und können nur entweder Sourcen oder Pläne oder Bausteine enthalten.
typedef enum { S7Block, S7Container, S7Source, S7Plan } S7SWObjType;
typedef enum { S7BlockContainer, S7SourceContainer, S7PlanContainer } S7ContainerType;
typedef enum { S7OverwriteAsk, S7OverwriteAll, S7OverwriteNone } S7OverwriteFlags.

Properties

BSTR Name
BSTR LogPath [read only]
S7SWObjType Type [read only]
S7ContainerType ConcreteType [read only]
IDispatch* Parent [read only]
IS7Program* Program [read only]
IS7SWItems* Next [read only]

Methoden

void Remove ()
IS7SWItem* Copy (IDispatch* pParent)
void Download (S7OverwriteFlags Overwrite [optional, defaultvalue (S7OverwriteAsk)])

ConcreteType liefert eine Verfeinerung der Angabe zu Type. Während Type nur zu entnehmen ist, daß es sich überhaupt um irgendeine Art von Container handelt, kann man anhand von ConcreteType eine weitere Unterscheidung treffen und damit feststellen, was für Software-Items sich überhaupt in diesem Container befinden können.

Der Download () kopiert alle in dem Container enthaltenen Objekte über eine Online- Verbindung auf die CPU. Über den optionalen Parameter Overwrite kann der Anwender festlegen, wie verfahren werden soll, wenn der zu ladende Baustein im Ziel (also online) bereits existiert. Defaultmäßig wird ein Dialog präsentiert, in dem der Anwender das weitere Verhalten interaktiv festlegen kann. Er kann jedoch auch via Parameter Overwrite spezifizieren, daß im Ziel bereits existierende Bausteine im Rahmen des Ladevorgangs immer bzw. niemals überschrieben werden sollen. Für Source- und Plan-Container ist der Download unzulässig.

6. Weitere Hinweise

An einigen der Objekte (SymbolTable, Source, Block, Plan, Station) werden Methoden (Edit) realisiert, über die die zugehörige Editor-Applikation gestartet werden kann. Kommando-Skript und gestartete Applikation werden dabei jedoch nicht miteinander synchronisiert, d. h. das Kommando-Skript läuft weiter (wartet nicht in dem Schnittstellen-Call, bis die gestartete Applikation geschlossen wird).

Die Objekte können über die Kommando-Schnittstelle nicht verschoben werden.

Datenobjekte wie Quellen, Bausteine und Pläne können nur durch Angabe einer Datei, in der die "Quellinformation" letztendlich steht, erzeugt werden. Es ist nicht möglich, zunächst eine Hülle zu erzeugen und diese dann zu füllen.

Fehlermeldungen der AUT-API-Error-Services werden beim Arbeiten mit der Kommando- Schnittstelle nur dann ausgegeben, wenn es sich bei den Meldungen um Anwender- Entscheidungen handelt oder die Ausgabe explizit durch einen unterlagerten OM erzwungen wird. Im Normalfall wird die Ausgabe der Fehlermeldungen unterdrückt. Falls ein Aufruf an der Kommando-Schnittstelle fehlschlägt, wird jedoch die letzte Fehlermeldung der Error- Services über den COM-Fehlermechanismus (::SetErrorInfo). Das Kommando-Skript bzw. der Scripting-Host kann dann über die Description des letzten Fehlereintrags den Meldungstext der Error-Services abfragen bzw. ausgeben.

Claims (1)

1. Verfahren zur Steuerung von Projektierwerkzeugen für Auto­ matisierungssysteme über eine Batch-Schnittstelle durch die ausgewählten Objekte und Funktionen der Anwendungsschnittstel­ le (API) durchgereicht werden.