-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren zum Programmieren
und zur Diagnose einer speicherprogrammierbaren Steuerung (SPS). Derartige
Steuerungen werden in der Automatisierung verwendet, um in Maschinen
und Anlagen Verfahrensabläufe zu steuern bzw. um einzelne
Antriebe dieser Anlagen anzusteuern. Genauer kann die vorliegende
Erfindung im Rahmen des Engineerings von Automationsgeräten
bzw. -verbünden, die eine speicherprogrammierbare Steuerung
beinhalten, verwendet werden. Beim Programmieren derartiger Steuerungen
ist es bekannt, einen bestimmten Fehlersuchmodus (Debugmodus) zur
Verfügung zu stellen, bei dem Ein- und Ausgänge
mittels einer so genannten Online-Statusanzeige als Zahlenwerte
jedoch ohne Bezug zur logischen Funktion der Funktionsbausteine
dargestellt werden. Damit ist hier nur eine Darstellung von Zahlenwerten
möglich, jedoch keine aufbereitete Darstellung der Funktionalität
bzw. auch keine übersichtliche Darstellung.
-
Zum
Programmieren derartiger SPS-Steuerungen werden im Stand der Technik
SPS Programmiersysteme verwendet. Die Programmierung von speicherprogrammierbaren
Steuerungen wird oftmals mittels Programmiersprachen nach IEC 61131-3 durchgeführt
(beispielsweise durch ST: Strukturierter Text; FUP: Funktionsplan;
KOP: Kontaktplan usw.). Dabei ist auch im Stand der Technik die
SPS-Programmierung sehr flexibel und damit können auch
im Wesentlichen beliebige Abläufe gesteuert werden.
-
Aus
dem Stand der Technik bekannte SPS-Programmiersysteme weisen üblicherweise eine
Benutzeroberfläche auf, mit deren Hilfe SPS-Programme und
SPS-Funktionsbausteine (FB) in verschiedenen Sprachen bzw. Sprachdialekten
erstellt werden können. Dabei ist es üblich, diese
Funktionsbausteine zu instanziieren, was bedeutet, dass jeder FB
bei seiner Verwendung wie eine Variable einzeln und eigens deklariert
und definiert werden muss.
-
Wie
oben erwähnt, steht zur Diagnose der erstellten Programme
bzw. Funktionsbausteine der Debugmodus zur Verfügung, mit
dessen Hilfe im Kontext der Programmieroberfläche der Zustand
von SPS-Variablen visualisiert werden kann. Dies erfolgt dabei mit
Hilfe einer Statusanzeige, die im Aussehen je nach verwendeter Programmiersprache
unterschiedlich ist.
-
Auch
ist es dabei üblich, dass sich die SPS-Programme und FBs
in einem Deklarationsteil und einem Implementationsteil untergliedern,
wobei in dem Deklarationsteil die SPS-Variablen und FB-Instanzen
instanziiert werden (Daten) und im Implementationsteil die Funktionalität
ausprogrammiert wird (Logik). Unter dem Begriff Instanziieren wird
dabei ein Definieren oder Herstellen der jeweiligen Variablen und
der Instanzen verstanden.
-
Im
Rahmen des erwähnten Debugmodus innerhalb des Programmiersystems
können Werte von SPS-Variablen gelesen, geändert
und geforct (erzwungen) werden. Unter einem Forcen versteht man dabei
das dauerhafte Setzen einer Variablen auf einen vorgebbaren Wert.
Weiterhin ermöglicht die erwähnte Statusanzeige
im Kontext eines FBs es auch, FB-interne Werte darzustellen, die
außerhalb des FBs nicht abrufbar sind. So können
beispielsweise interne Zustände eines FBs dargestellt werden.
-
Aus
der noch nicht veröffentlichten
DE 10 2007 062 453.2 ist ein
Verfahren zum Programmieren und/oder zur Diagnose einer speicherprogrammierbaren
Steuerung bekannt. Dabei werden Ergebnisse während eines
Programmiermodus über eine Anzeigeeinrichtung ausgegeben
und die zum Programmieren verwendeten Informationsaustauschabläufe
stehen als vordefinierte Informationsaustauschabläufe eines
speicherprogrammierbaren Funktionsbausteins zur Verfügung.
Damit beschreibt die
DE
10 2007 062 453.2 eine Darstellbarkeit von einer dialogbasierten
Unterstützung bei der SPS-Programmierung sowie eine Optimierung
von Programmparametern. Der Gegenstand der
DE 10 2007 062 453.2 , eingereicht
am 22.12.2007 beim DPMA durch die vorliegende Anmelderin, wird hiermit
durch Bezugnahme vollständig zum Gegenstand auch der vorliegenden
Patentanmeldung gemacht.
-
Im
Falle 10 2007 062 453.2 tritt jedoch teilweise das Problem auf,
dass dort beispielsweise eine Programmierung im Offline-Betrieb
nicht möglich ist und die SPS-Variablen nicht änderbar
sind. Der vorliegenden Erfindung liegt daher die Aufgabe zugrunde,
die Programmierbarkeit für speicherprogrammierbare Steuerungen
zu verbessern. Dies wird erfindungsgemäß durch
ein Verfahren nach Anspruch 1 und einer Vorrichtung nach Anspruch
9 erreicht. Vorteilhafte Ausführungsformen und Weiterbildungen sind
Gegenstand der Unteransprüche.
-
Bei
einem erfindungsgemäßen Verfahren zum Programmieren
und/oder zur Diagnose einer speicherprogrammierbaren Steuerung mit
wenigstens einem speicherprogrammierbaren Funktionsbaustein wird
zum Programmieren ein vorgegebenes Programmiersystem verwendet und
im Rahmen dieses Programmiersystems werden Variablen vorgegeben
und zum Programmieren weitere Informationsaustauschabläufe
verwendet. Erfindungsgemäß werden Ergebnisse der
Programmierung während wenigstens eines Programmiermodus über
eine Ausgabeeinrichtung ausgegeben und eingegebene Informationen
wenigstens teilweise dauerhaft abgespeichert.
-
Im
Falle der
DE 10 2007 062
453.2 war keine persistente Speicherung von Daten vorgesehen.
Es wird damit vorgeschlagen, bestimmte Änderungen persistent,
d. h. dauerhaft zu gestalten und dies insbesondere, wenn eine graphische
oder textuelle Unterstützung bei der Programmierung von
SPS-Programmen bzw. Optimierung von Programmparametern d. h. insbesondere
von Ein- und/oder Ausgängen von SPS-Funktionsbausteinen
eingesetzt wird. Die vorliegende Erfindung dient dabei insbesondere
für das Engineering von Automationsgeräten bzw.
Verbünden, die eine speicherprogrammierbare Steuerung beinhalten.
Bevorzugte Anwendungsgebiete sind dabei Gebiete der Werkzeugtechnik,
der Verpackungstechnik, der Produktionstechnik und dergleichen.
-
Durch
die erfindungsgemäße Vorgehensweise wird damit
eine Persistenz von durchgeführten Änderungen
auch nach einem Reset oder nach einem neuen Booten erreicht. Im
Gegensatz zum Stand der Technik sind damit durch Funktionsbausteindialoge eingefügte Änderungen
nicht nach dem nachfolgenden Ausschalten verloren und müssen
auch nicht von einem SPS-Programmierer manuell in das SPS-Programm
eingepflegt werden.
-
Unter
dem Begriff Persistenz wird eine dauerhafte Speicherung eines Zustands
einer SPS-Instanz, insbesondere inklusive der durchgeführten Änderungen,
verstanden.
-
Bei
einem vorteilhaften Verfahren sind die besagten Informationsaustauschabläufe
dem Funktionsbaustein zugeordnet und stehen als vordefinierte Informationsaustauschabläufe
dieses speicherprogrammierbaren Funktionsbausteins zur Verfügung.
-
Bei
einem weiteren vorteilhaften Verfahren sind die Ergebnisse der Programmierung
durchgeführte Änderungen von Ein- oder Ausgängen
des Funktionsbausteins und insbesondere durchgeführte Änderungen
von Eingängen des Funktionsbausteins.
-
Bei
einem weiteren vorteilhaften Verfahren wird mittels eines Informationsaustauschablaufs
wenigstens eine Variable auf einen vorbestimmten Wert festgelegt
oder auch der Wert der besagten Variable geändert.
-
Vorteilhaft
wird das dauerhafte Abspeichern der eingegebenen Information durch
eine Modifikation der Deklaration von Instanzen des Funktionsbausteins
bewirkt. Bei diesem Verfahren werden die zu ändernden Parameter
bzw. Variablen direkt beim Initialisieren eingelesen. Diese Vorgehensweise
ist einerseits vergleichsweise einfach durchzuführen, andererseits
ist jedoch eine derartige Änderung nur beim Aufruf oder
am Anfang eines Prozesses möglich.
-
SPS-Programme
bestehen in der Regel aus einem Deklarationsteil und einem Implementationsteil.
Neben der Modifikation der Deklaration von FB-Instanzen kann auch
der Implementationsteil modifiziert werden. Hierbei kann der zu
modifizierende Abschnitt zum Beispiel eine eigene POU (Program Organization
Unit (= Funktionsbaustein, Programm, Funktion)) zur Initialisierung
der FB-Instanz sein. Neben einer eigenen Initialisierungs-POU kann
auch ein durch geeignete Kommentare kenntlich gemachter Codeabschnitt
zur Initialisierung der FB-Instanz verwendet werden, der dann entsprechend
modifiziert wird.
-
Bei
einem weiteren vorteilhaften Verfahren werden die Ergebnisse der
Optimierung der Programmparameter in ein dauerhaftes Speichermedium
gespeichert, von wo sie beim Programmstart oder während
der Initialisierung des Programms wieder ausgelesen werden. Bei
dieser Vorgehensweise wäre es beispielsweise möglich,
dass eine Datenbank angelegt wird oder auch ein anderer persistenter
Speicher vorgesehen ist. Diese Vorgehensweise erlaubt insbesondere
auch Änderungen im Offline-Modus.
-
Bei
einer weiteren vorteilhaften Ausführungsform werden wenigstens
einige der Informationsaustauschabläufe ausgegeben. Dies
bedeutet, dass diese Austauschabläufe dem Benutzer visualisiert
werden können, damit dieser bequemer Änderungen
durchführen kann. Vorteilhaft sind auch Ergebnisse der
Programmierungen im Offline-Betrieb änderbar (was insbesondere
durch Einsatz eines dauerhaften Speichermediums möglich
ist.).
-
Die
vorliegende Erfindung ist weiterhin auf eine Vorrichtung zum Programmieren
und zur Diagnose einer speicherprogrammierbaren Steuerung mit wenigstens
einem speicherprogrammierbaren Funktionsbaustein gerichtet, wobei
zum Programmieren ein vorgegebenes Programmiersystem verwendbar ist
und im Rahmen dieses Programmiersystems Variablen vorgegeben werden
und zum Programmieren Informationsaustauschabläufe verwendet
werden, wobei die Vorrichtung wenigstens eine Informationsausgabeeinheit
aufweist, welche die Informationsaustauschabläufe wenigstens
teilweise ausgibt. Erfindungsgemäß sind eingegebene
Informationen wenigstens teilweise dauerhaft abgespeichert. Unter
einem dauerhaften Abspeichern wird dabei insbesondere verstanden,
dass die besagten Informationen nicht bei einem Reset des Systems
oder bei einem erneuten Booten verloren gehen (z. B. nach einem Aus-
und Wiedereinschalten), sondern wieder zur Verfügung stehen.
-
Bei
einer vorteilhaften Ausführungsform weist die Vorrichtung
wenigstens ein Speichermittel zum dauerhaften Abspeichern von Informationen
auf. Dabei kann es sich beispielsweise um eine Datenbank handeln,
aber auch um eine separate Speichereinheit. Es wäre jedoch
auch möglich, dass die Informationen beim Initialisieren
in der Deklaration oder im Implementationsteil vorgegeben werden
(durch Übernahme in den SPS-Quellcode). Auch insoweit liegt
eine persistente Speicherung dieser Informationen vor.
-
Weitere
Vorteile und Ausführungsformen der vorliegenden Erfindung
ergeben sich aus den beigefügten Zeichnungen:
-
Darin
zeigen:
-
1 Eine
schematische Darstellung eines erfindungsgemäßen
Verfahrens nach dem Stand der Technik;
-
2 eine
weitere Darstellung des aus dem Stand der Technik bekannten Verfahrens;
-
3 eine
weitere Darstellung des aus dem Stand der Technik bekannten Verfahrens;
-
4 eine
Darstellung zur Veranschaulichung eines erfindungsgemäßen
Verfahrens; und
-
5 eine
weitere Darstellung zur Veranschaulichung des erfindungsgemäßen
Verfahrens
-
1 zeigt
eine Darstellung eines Funktionsbausteins 2 dieser Funktionsbaustein
weist dabei Eingänge 4 und Ausgänge 14 auf.
Daneben ist ein Code 12 vorgesehen sowie ein Speicherbereich 6 für die
Eingänge bzw. deren Variablen (VAR_INPUT, VAR_OUTPUT, VAR_IN_OUT)
sowie auch ein weiteres Speichermittel 8 für lokale
Variablen des Funktionsbausteins FB. Das Bezugszeichen 12 bezieht sich
auf einen Code des Funktionsbausteins.
-
Wie
in 2 dargestellt, werden beim Aufruf eines Funktionsbausteins 2 zuerst
die im Aufruf enthaltenen Eingangsvariablen – hier beispielsweise VAR_INPUT
sowie VAR_IN_OUT (hierzu zählen auch Referenzvariablen
d. h. Zeigervariablen) – in den internen Speicherbereich 6 des
Funktionsbausteins 2 kopiert (Pfeil P1, Schritt I). In
einem weiteren Schritt (Schritt II) wird der Funktionsbaustein Code 12 ausgeführt.
In einem letzten Schritt (Pfeil P6, Schritt III) werden die Ausgänge
mit den Daten der internen Variablen aufgefrischt (VAR_OUTPUT und VAR_IN_OUT).
-
Zu
bemerken ist, dass im ersten Schritt auch nur ein Teil aller FB-Eingänge
(genauer: VAR_INPUTs) im FB-Aufruf enthalten sein können,
d. h. es wird auch nur ein Teil der vorhandenen internen FB-Variablen
verändert.
-
Des
Weiteren ist von Wichtigkeit, dass die internen FB-Variablen im
FB-internen Speicher nur flüchtige Daten sind, diese werden
beim nächsten Reset bzw. beim Einschalten der SPS neu mit
ihren Datentyp abhängigen Defaultwerten bzw. mit den in der
Deklaration hinterlegten Initialisierungswerten vorbesetzt, oder
mit im SPS-Programm hinterlegten Initialwerten beschrieben. Genauer
kann der ganze FB kann in einer sog. VAR_RETAIN Variablendeklaration
instanziiert werden. Dadurch werden alle Variablen (Ein-/Ausgänge,
sowie interne Variablen) in einem Retain-Datenspeicher abgelegt.
-
Ein
Anwender kann jedoch – nachdem er Änderungen mittels
FB-Dialogen durchgeführt hat – diese Änderungen
manuell im SPS-Programm einpflegen. Hierzu kann er einerseits die
Deklaration der FB-Instanzen verwenden, andererseits kann er bspw.
einen speziellen Codeabschnitt zur Initialisierung von Variablen
(und damit auch FB-interne Ein-/Ausgänge) verwenden und/oder
die Variablen im normalen Programmablauf verändern.
-
Bei
dem in der
DE 10 2007 062
453.2 beschriebenen Verfahren werden zusätzlich
die in
3 dargestellten Informationsaustauschabläufe bzw.
Funktionsbausteinsdialoge
20 verwendet. Mit Hilfe dieser
Informationsaustauschabläufe
20 ist eine Änderung
der Variablen, dargestellt durch die Pfeile P7 und P8, möglich,
und ein Lesen dieser Variablen aus dem Speicher
6, wie
durch die Pfeile P9 und P10 angedeutet. Die Pfeile P2 und P3 zeigen
die Wechselwirkung bei dem Einlesevorgang zwischen dem Speicherbereich
6 und
dem FB-Code und die Pfeile P4 und P5 den Austausch zwischen dem
FB-Code und dem Speicherbereich
8.
-
Die
in der
DE 10 2007 062 453.2 beschriebenen
Dialoge zur Darstellung und Veränderung von FB-Ein-/Ausgangsvariablen
verändern dabei dauerhaft nur die FB-Eingänge
(VAR_INPUTs), die beim FB-Aufruf nicht mit angegeben sind, da diese
ansonsten beim nächsten FB-Aufruf wieder überschrieben
werden würden, d. h. die Dialoge können sinnvoll nur
für die FB-Eingänge verwendet werden, die beim Aufruf
nicht mit einem Wert oder einer Variablen beschaltet werden, da
nur in diesem Fall die über die Dialoge eingestellten Werte
nicht überschrieben werden.
-
In
dem beschriebenen Stand der Technik sind daher alle mittels FB-Dialogen
vorgenommenen Änderungen nicht persistent bzw. werden in
der Regel nur im flüchtigen Speicher der SPS durchgeführt. Falls
eine derartige Persistenz der Änderung notwendig ist, muss
diese manuell von einem SPS-Programmierer eingepflegt werden. Weiterhin
ist es bei der in 3 dargestellten Vorgehensweise
nur möglich, die FB-Dialoge im Online-Fall zu verwenden
(da sie auf Speicher der SPS-Runtime zugreifen).
-
Im
Rahmen der Erfindung wird daher vorgeschlagen, dass ein Zustand
dieser veränderten FB-Instanzen persistent speicherbar
ist. Besonders vorteilhaft sind die besagten FB-Dialoge 20 auch
in einem Offline-Fall verwendbar. So ist es insbesondere möglich,
dass geänderte Werte in einer SPS-Variablendeklaration
automatisch eingefügt bzw. verändert werden oder
aber ein Initialisierungsprogramm generiert wird oder mittels einer
Datenbank (zum Beispiel als Datei) die zu ändernden Werte
gespeichert und bei einem Neustart eingelesen werden. Jede dieser
Maßnahmen erlaubt damit eine dauerhafte Abspeicherung der Änderungen
und damit insgesamt, die Programmierung zu vereinfachen.
-
4 zeigt
eine erste Maßnahme, um diese beschriebene Persistenz zu
erreichen. In diesem Falle wird eine Modifikation der Deklaration
von FB-Instanzen durchgeführt.
-
Jede
SPS-Variable, und damit auch eine FB-Instanz, besitzt eine Stelle
im SPS-Programmier-Tool, an der sie deklariert wird. Diese Stelle
ist eindeutig, d. h. jede SPS-Variable kann an genau einer einzigen
Stelle Initialisierungsdaten erhalten.
-
Diese
Initialisierungsdaten werden von der Logik der FB-Dialoge bspw.
beim Beenden der Dialoge oder durch eine Schaltfläche im
Dialog in die Deklaration übernommen. Nach dem Ausloggen
aus dem SPS-Laufzeitsystem wird die Deklaration der entsprechenden
FB-Instanzen automatisch von der Logik der FB-Dialoge geändert.
Anschließend ist das SPS-Programm vor dem nächsten
Einloggen in das SPS-Laufzeitsystem neu zu compilieren.
-
In
dem in 4 dargestellten rechten Fenster 22 wird
damit eine Initialisierung der einzelnen Daten ermöglicht.
Diese Initialisierung wird bei dem Start der SPS in den internen
Speicher des Funktionsbausteins abgerufen. Damit wird bei dieser
Ausgestaltung eine Speicherung der Daten über eine entsprechende
Initialisierung der Funktionsbausteine aufgerufen. Damit ist hier
eine Automatisierung der besagten Änderungen möglich.
-
5 zeigt
eine derartige automatisierte Änderung. Der linke Teil 24 zeigt
dabei eine Deklaration vor der Veränderung. Der rechte
Teil 26 zeigt die Deklaration nach der Veränderung
der automatischen Codegenerierung. Im Einzelnen wurde hier eine
Veränderung des Initialisierungswertes von „Setpoint” von
0.0 auf 15.0 durchgeführt. Im Stand der Technik wird diese
Initialisierung von einem SPS-Programmierer selbstständig
eingefügt. Wie in 5 dargestellt,
wurde jedoch hier eine Deklaration nach einer Änderung
durch die Logik der FB-Dialoge verändert.
-
Neben
dem hier beschriebenen Verfahren ist es jedoch auch möglich,
FB-Instanzen zu serialisieren d. h. einen Zustand von Objekten in
ein persistentes Speichermedium zu speichern, wie zum Beispiel eine
Datei oder einen nvRAM. Der umgekehrte Vorgang, d. h. die Wiederherstellung
des Zustandes eines Objekts wird als Deserialisierung bezeichnet.
-
Serialiserung
und Deserialiserung sind heute, insbesondere im Rahmen der Erstellung
von PC Anwendungsprogrammen, gängige Verfahren zur Bereitstellung
persistenter Objekte. Hierzu muss bei neuen Datentypen die Funktionalität
zur Serialiserung bzw. Deserialiserung vom Programmierer selbst bereitgestellt
werden. Alternativ kann auch auf Bibliotheken zurückgegriffen
werden, die diese Funktionalität bereitstellen.
-
Bei
SPS-Systemen wird bislang lediglich der Vorgang der Deserialisierung
innerhalb des Initialisierungsteils des SPS-Programms verwendet,
indem z. B. Maschinenparameter geladen werden.
-
Im
Rahmen der vorliegenden Erfindung wird vorgeschlagen, dass die Logik
zur Serialisierung und auch zur Deserialisierung automatisch bereitgestellt wird.
Weiterhin ist es möglich, dass der SPS-Programmierer diese
Funktionalität in seinem SPS-Programm nutzen kann. Weiterhin
wird diese Serialisierung nicht nur von dem Objekt selbst, sondern
auch von extern für das Objekt durch die FB-Dialoge ausgeführt.
Daneben wäre es auch möglich, so genannte Retain-Variablen
zu verwenden d. h. solche Variablen, die über (mehrere)
Schritte des Programms hinweg aufrechterhalten werden.
-
Wird
z. B. im Initialisierungs- und/oder zyklischen Teil des SPS-Programms
an einen Eingang eines FBs eine Retain-Variable angeschlossen bzw. wird
der FB immer mit derselben Retain-Variablen am entsprechenden Eingang
aufgerufen, so kann anstatt der internen FB-Daten auch die angeschlossene Retain-Variable
zur persistenten Speicherung verwendet werden.
-
Retain-Variablen
sind per Definition persistente Variablen des SPS-Programmiersystems.
-
Die
Schwierigkeit bei der Verwendung von Retain-Variablen liegt darin,
dass der gesamte SPS-Programmcode nach Aufrufen des FBs durchsucht
werden muss und dass jede angeschlossene Retain-Variable durch die
FB-Dialoge verändert werden muss. Wird dieselbe Retain-Variable
an verschiedenen FBs angeschlossen, erhält man ein schwer
zu durchschauendes Verhalten.
-
Bei
einem weiteren Verfahren ist es möglich, die persistenten
Daten zusätzlich auf der Steuerung abzulegen. Dabei wäre
es möglich, auf der Steuerung eine Datei zur Verfügung
zu stellen, die zur Abspeicherung dieser Daten dient. Weiterhin
wäre auch die Speicherung in einer global vorhandenen und
per Definition persistenten SPS-Variable, insbesondere mit definiertem
Namen und definierter Struktur, denkbar. Schließlich könnte
auch eine Speicherung an einem festen Speicherbereich in der SPS
mit einer definierten Struktur vorgenommen werden.
-
Die
Datenbank beinhaltet dabei mindestens neben den zu initialisierenden
Werten auch eine Referenz auf die FB-Instanz bzw. die zu ändernden FB-Eingänge,
dies kann z. B. ein Adresszeiger oder der Variablenname selbst sein.
In letzterem Falle muss eine Instanz existieren, die aus dem Variablennamen
die entsprechende Speicherzelle ableiten kann (Adressauflösung
anhand einer sog. Symboldatei). Die Adresse der Instanz wird vermutlich
nicht ausreichen man benötigt Symbolinformationen für jede
zu sichernde Variable.
-
Die
Daten in der Datenbank/Datei werden dabei von den FB-Dialogen geschrieben
und beim SPS-Start durch eine Routine ausgewertet, die dann die
entsprechende Funktionalität der Vorbesetzung beinhaltet.
-
Weiterhin
wäre es auch möglich, eine vordefinierte Initialisierungs-POU
(zugeordnete Programmeinheiten) zu verwenden, welche die Initialisierungen
von Variablen vornimmt. Diese POU kann beispielsweise einen definierten
Namen besitzen und wird von den FB-Dialogen geparst bzw. entsprechende
Zeilen werden geändert. Diese Variante erfordert jedoch,
wie auch die Änderung der Deklaration, eine Neuübersetzung
des SPS-Programms und ein Herunterladen in die SPS.
-
Weiterhin
ist es auch möglich, dass die Funktionen zur Serialisierung
und Deserialisierung automatisch bereitgestellt werden.
-
Unter
Verwendung der FB-Dialoge kann eine Funktion (oder Aktion) derjenigen
POU automatisch hinzugefügt werden, innerhalb derer die
zu deserialisierende FB-Instanz deklariert ist. D. h., der SPS-Code
wird durch die FB-Dialoge modifiziert. Innerhalb der automatisch
hinzugefügten Funktion (oder Aktion) ist ein Code zum Wiederherstellen
(deserialisieren) des Zustandes der FB-Instanz hinterlegt. Diese Funktion
fügt der Anwender dem Initialisierungsteil seines SPS-Programms
hinzu. Bei einem (Neu-)Start der SPS werden im Initialisierungsteil
die wiederherzustellenden Daten aus einer Datei, dem nvRAM, einer
Datenbank, oder einem Objekt, das Bestandteil der SPS-Laufzeitsystems
ist, ausgelesen und der vorherige Zustand der FB-Instanz wieder
hergestellt. Die FB-Dialoge wiederum können die vom Benutzer in
den FB-Dialogen geänderten Werte in die Datei, das nvRAM,
die Datenbankoder in das SPS-Objekt schreiben, so dass beim nächsten
(Neu-)Start der SPS die geänderten Werte in der FB-Instanz
vorliegen.
-
Grundsätzlich
liegen die oben erwähnten Daten im Kontext des Speichers
des FBs selbst vor. Dies bedeutet, dass sie prinzipiell nur im Online-Fall ausgelesen,
angezeigt und verändert werden, d. h. dann, wenn die Oberfläche
mit den FB-Dialogen mit der SPS verbunden ist. Mit Hilfe der beschriebenen Verfahren
soll es ermöglicht werden, die Daten auch im Offline-Fall
in den FB-Dialogen anzuzeigen und zu verändern.
-
Insoweit
sind folgende Fälle zu unterscheiden, nämlich
einerseits die oben erwähnte Deklaration bzw. Initialisierungs-POU
(oder Initialisierungsabschnitt), und andererseits eine Datenbank
auf der Steuerung bzw. die Verwendung von Retain-Variablen. Im Falle
einer Änderung der Deklaration bzw. einer Initialisierungs-POU
wird der entsprechende Codeteil des SPS-Programms geparst und die
entsprechenden Variablenwerte werden in den FB-Dialogen dargestellt.
Nachdem eine Änderung durchgeführt wurde, wird
der entsprechende Codeteil modifiziert und muss jedoch, wie oben
erwähnt, später noch neu übersetzt und
in die SPS geladen werden.
-
Bei
Verwendung einer Datenbank auf der Steuerung bzw. der Verwendung
von Retain-Variablen kann eine Datenbank verwendet werden, die zunächst
auf dem Rechner mit der Programmieroberfläche liegt. Die
Werte dieser Datenbank können dann auch im Offline-Fall
angezeigt und verändert werden. Beim nächsten
Online-Gehen wird diese Datenbank mit den entsprechenden Datenbanken
in der SPS synchronisiert.
-
Im
Falle einer Datenbank in der SPS sind die Daten zu synchronisieren,
indem beispielsweise diese auf einer auf der SPS vorhandene Datei überschrieben
bzw. diese bei Nichtvorhandensein erzeugt wird. Falls keine Datenbank
auf der SPS verwendet wird, werden die Daten in die entsprechenden
Retain-Variablen geschrieben.
-
Sämtliche
in den Anmeldungsunterlagen offenbarten Merkmale werden als erfindungswesentlich
beansprucht, sofern sie einzeln oder in Kombination gegenüber
dem Stand der Technik neu sind.
-
Bezugszeichenliste
-
- 2
- Funktionsbaustein
- 4
- Eingänge
- 6
- Speicherbereich
- 12
- Code
- 14
- Ausgänge
- 20
- FB-Dialoge
- 22
- Fenster
- 24
- linker
Teil
- 26
- rechter
Teil
- P1–P10
- Pfeile
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- - DE 102007062453 [0007, 0007, 0007, 0010, 0034, 0035]
-
Zitierte Nicht-Patentliteratur
-
