|
FRAGE:
Mit
welchen verschiedenen Mechanismen lassen sich in der S7-400 Daten
konsistent übertragen?
ANTWORT:
Konsistente Daten
Daten, die inhaltlich zusammengehören und
einen Prozesszustand zu einem bestimmten Zeitpunkt beschreiben,
bezeichnet man als konsistente Daten. Damit Daten konsistent sind,
dürfen sie während der Verarbeitung oder Übermittlung nicht
verändert oder aktualisiert werden.
Beispiel 1:
Damit der CPU für die Dauer der
zyklischen Programmbearbeitung ein konsistentes Abbild der
Prozess-Signale zur Verfügung steht, werden die Prozess-Signale vor
der Programmbearbeitung in das Prozessabbild der Eingänge gelesen
bzw. nach der
Programmbearbeitungin das Prozessabbild der Ausgänge
geschrieben. Anschließend greift das
Anwenderprogrammwährend der
Programmbearbeitung beim Ansprechen der Operandenbereiche
Eingänge (E) und Ausgänge (A) nicht direkt auf die Signalbaugruppen
zu, sondern auf den internen Speicherbereich der CPU, in dem sich
das Prozessabbild befindet.
Beispiel 2:
Eine Inkonsistenz kann entstehen, wenn
ein Kommunikations-Baustein (z.B. SFB 14 "GET", SFB 15 "PUT") durch
einen Prozessalarm-OB mit höherer Priorität unterbrochen wird.
Verändert das Anwenderprogramm in diesem Prozessalarm-OB jetzt die
Daten, die teilweise bereits vom Kommunikations-Baustein
verarbeitet wurden, so stammen die übertragenen Daten zum einen
Teil aus der Zeit vor der Prozessalarm-Bearbeitung und zum anderen
Teil aus der Zeit nach der Prozessalarm-Bearbeitung.
Das bedeutet, dass diese Daten
inkonsistent (nicht zusammengehörig) sind.
Die SFC 81
"UBLKMOV"
Mit der SFC 81 "UBLKMOV"
kopieren Sie den Inhalt eines Speicherbereichs (= Quellbereich)
konsistent in einen anderen Speicherbereich (= Zielbereich). Der
Kopiervorgang kann nicht durch andere Tätigkeiten des
Betriebssystems unterbrochen werden.
Mit der SFC 81 "UBLKMOV"
können Sie die folgenden Speicherbereiche kopieren:
Die maximale Datenmenge,
die Sie kopieren können, beträgt 512 Byte. Beachten Sie bitte die
CPU-spezifischen Einschränkungen, die Sie beispielsweise der
Operationsliste entnehmen können.
Da der Kopiervorgang
nicht unterbrochen werden kann, kann sich die Alarmreaktionszeit
Ihrer CPU bei Einsatz der SFC 81 "UBLKMOV" erhöhen.
Quell- und Zielbereich
dürfen sich nicht überlappen. Ist der angegebene Zielbereich größer
als der Quellbereich, dann werden auch nur so viele Daten in den
Zielbereich kopiert, wie im Quellbereich stehen. Ist der angegebene
Zielbereich kleiner als der Quellbereich, dann werden nur so viele
Daten kopiert, wie der Zielbereich aufnehmen kann.
Konsistenz bei den Kommunikationsbausteinen
und Funktionen
Bei der S7-400 werden
Kommunikationsaufträge nicht im Zykluskontrollpunkt, sondern in
festen Zeitscheiben während des Programmzyklusses bearbeitet.
Systemseitig können immer die Datenformate Byte, Wort und
Doppelwort in sich konsistent bearbeitet werden, d.h. die
Übertragung bzw. Verarbeitung von 1 Byte, 1 Wort (= 2 Byte) oder 1
Doppelwort (= 4 Byte) kann nicht unterbrochen werden.
Werden im
Anwenderprogramm Kommunikationsbausteine (z.B. SFB 12 "BSEND")
aufgerufen, die nur paarweise eingesetzt werden (z.B. SFB 12
"BSEND" und SFB 13 "BRCV") und welche auf gemeinsame Daten
zugreifen, so kann der Zugriff auf diesen Datenbereich z.B. über
den Parameter „DONE“ selbst koordiniert werden. Die Konsistenz der
Daten, welche lokal mit diesen Kommunikationsbausteinen übertragen
werden, kann deshalb im Anwenderprogramm sichergestellt
werden.
Anders verhält es sich
bei S7-Kommunikationsfunktionen, bei denen im Zielgerät kein
Baustein im Anwenderprogramm erforderlich ist (z.B. SFB 14 "GET",
SFB 15 "PUT"). Hier müssen Sie bereits bei der Programmierung die
Größe der konsistenten Daten berücksichtigen.
Zugriff auf den Arbeitsspeicher der
CPU
Die Kommunikationsfunktionen des Betriebssystems greifen in
Blöcken fester Größe auf den Arbeitsspeicher der CPU zu. Die
Blockgröße ist CPU-spezifisch; sie beträgt für die S7-400 CPUs 32
Byte.
Dadurch wird gewährleistet, dass sich die
Alarmreaktionszeit beim Einsatz von Kommunikationsfunktionen nicht
verlängert. Da dieser Zugriff asynchron zum Anwenderprogramm
erfolgt, können Sie bei der Datenübertragung nicht beliebig viele
Bytes konsistent übertragen.
Welche Regeln Sie einhalten müssen, um Datenkonsistenz zu
garantieren, wird im folgenden erläutert.
Konsistenzregeln für
SFB 14 "GET" bzw. Variable lesen
Bei der SFB 14 "GET“ werden
die Daten konsistent übertragen, wenn Sie alle im folgenden
genannten Konsistenzregeln beachten:
-
Aktive CPU
(Datenempfänger):Lesen Sie den Empfangsbereich in dem OB aus, in
dem Sie die SFB 14 aufrufen oder -falls dies nicht möglich ist-
lesen Sie den Empfangsbereich erst dann aus, wenn die Bearbeitung
der SFB 14 abgeschlossen ist.
-
Passive CPU
(Datensender):Schreiben Sie höchstens so viele Daten in den
Sendebereich, wie die Blockgröße der passiven CPU (Datensender)
angibt.
-
Passive CPU
(Datensender):Schreiben Sie die zu sendenden Daten unter
Interruptsperre in den Sendebereich.
Im folgenden Bild wird ein
Beispiel für eine Datenübertragung angegeben, für die keine
Datenkonsistenz gewährleistet werden kann, weil die zweite
Konsistenzregel verletzt wurde: Es werden 32 Byte übertragen,
obwohl die Blockgröße der passiven CPU (Datensender) nur 8 Byte
beträgt.
Bild 1: Beispiel für die
Datenübertragung
Konsistenzregeln für die SFB 15 "PUT" bzw. Variable
schreiben
Bei der SFB 15 "PUT“ werden
die Daten konsistent übertragen, wenn Sie alle im folgenden
genannten Konsistenzregeln beachten:
-
Aktive CPU
(Datensender):Beschreiben Sie den Sendebereich von dem OB aus, in
dem Sie die SFB 15 aufrufen.oder -falls dies nicht möglich ist-
beschreiben Sie den Sendebereich erst dann, wenn der erste Aufruf
der SFB 15 abgeschlossen ist.
-
Aktive CPU
(Datensender):Schreiben Sie höchstens so viele Daten in den
Sendebereich, wie die Blockgröße der passiven CPU (Datenempfänger)
angibt.
-
Passive CPU (Datenempfänger):Lesen Sie die empfangenen
Daten unter Interruptsperre aus dem Empfangsbereich aus.
Im folgenden Bild wird ein
Beispiel für eine Datenübertragung angegeben, für die keine
Datenkonsistenz gewährleistet werden kann, weil die zweite
Konsistenzregel verletzt wurde: Es werden 64 Byte übertragen,
obwohl die Blockgröße der passiven CPU (Datenempfänger) nur 32 Byte
beträgt.
Bild 2: Datenübertragung ohne gesicherte
Datenkonsistenz
Die konsistente Übertragung größerer
Datenblöcke über mehrere Variablen hinweg können Sie im
Anwenderprogramm der S7-400 mit der SFC 81 "UBLKMOV"
(uninterruptable block move) sicherstellen.
Auf diese Daten kann dann, z.B. mit den
SFB 14 "GET", SFB 15 "PUT bzw. über Lesen/Schreiben von Variablen
konsistent zugegriffen werden.
Daten konsistent von einem DP-Normslave lesen
und konsistent auf einen DP-Normslave schreiben
Daten
konsistent von einem DP-Normslave lesen mit der SFC 14
"DPRD_DAT"
Mit der SFC 14 "DPRD_DAT"
(read consistent data of a DP-normslave) lesen Sie die Daten eines
DP-Normslaves konsistent aus. Falls bei der Datenübertragung kein
Fehler auftrat, werden die gelesenen Daten in den durch RECORD
aufgespannten Zielbereich eingetragen.
Der Zielbereich muss
dieselbe Länge aufweisen, die Sie für die selektierte Baugruppe mit
STEP 7 projektiert haben.Sie können mit einem Aufruf der SFC 14
jeweils nur auf die Daten einer Baugruppe/ DP-Kennung unter der
projektierten Anfangsadresse zugreifen.
Daten konsistent auf
einen DP-Normslave schreiben mit der SFC 15 "DPWR_DAT"
Mit der SFC 15 "DPWR_DAT"
(write consistent data to a DP-normslave) übertragen Sie die Daten
in RECORD konsistent zum adressierten DP-Normslave.
Der Quellbereich muss
dieselbe Länge aufweisen, die Sie für die selektierte Baugruppe mit
STEP 7 projektiert haben.
Hinweise:
Die Profibus DP-Norm legtObergrenzen für
die Übertragung konsistenter Nutzdaten fest (siehe nächsten
Abschnitt). Gängige DP-Normslaves halten diese Obergrenzen ein. Bei
älteren CPUs (<1999) bestanden CPU-spezifische Einschränkungen
für die Übertragung konsistenter Nutzdaten.
Bei diesen CPUs finden Sie die Maximallänge der Daten,
die die CPU konsistent von einem DP-Normslave auslesen kann bzw.
konsistent auf einen DP-Normslave schreiben kann, bei ihren
technischen Daten unter dem Stichwort "DP-Master – Nutzdaten pro
DP-Slave" angegeben. Neuere CPUs übertreffen mit diesem Wert die
die Länge der Daten, die ein DP-Normslave bereitstellt bzw.
aufnimmt.
Maximale Obergrenzen für
die Übertragung konsistenter Nutzdaten auf einen
DP-Slave
Für die Übertragung konsistenter Nutzdaten
auf einen DP-Slave werden durch die Profibus DP-Norm Obergrenzen
festgelegt. Deshalb können in einen DP Normslave maximal 64 Worte =
128 Byte Nutzdaten konsistent in einem Block übertragen
werden.
Bei der Projektierung
legen Sie fest, wie groß der konsistente Bereich ist. Dazu ist im
speziellen Kennungsformat (SKF) eine maximale Länge der
konsistenten Daten von 64 Worten = 128 Byte einstellbar (128 Byte
für Ein- und 128 Byte für Ausgänge) eine größere Länge ist nicht
möglich.
Diese Obergrenze gilt nur für reine Nutzdaten.
Diagnose- und
Parameterdaten werden zusammengefasst zu ganzen Datensätzen und
somit grundsätzlich konsistent übertragen.
Im allgemeinen
Kennungsformat (AKF) ist eine maximale Länge der konsistenten Daten
von 16 Worten = 32 Byte einstellbar (32 Byte für Ein- und 32 Byte
für Ausgänge) eine größere Länge ist nicht möglich.
Beachten Sie in diesem
Zusammenhang bitte auch, dass eine CPU 41x als DP-Slave im
allgemeinen Kontext an einem Fremd-Master (Anbindung über GSD) über
das allgemeine Kennungsformat konfigurierbar sein muss. Aus diesem
Grund ist der Übergabespeicher einer CPU 41x als DP-Slave zum
PROFIBUS DP maximal 16 Worte = 32 Byte groß.
Konsistenter Datenzugriff ohne
Einsatz der SFC 14 oder SFC 15
Ein konsistenter Datenzugriff > 4 Bytes ist bei den
nachfolgend aufgelisteten CPUs auch ohne die SFC 14 bzw. SFC 15
möglich. Der Datenbereich eines DP-Slaves, der konsistent
übertragen werden soll, wird auf ein Teilprozessabbild übertragen.
Die Informationen in diesem Bereich sind dann immer konsistent. Sie
können danach über Lade-/Transferbefehle (z.B. L EW 1) auf das
Prozessabbild zugreifen.
Dies bietet eine
besonders komfortable und performante (geringe Laufzeitbelastung)
Zugriffsmöglichkeit auf konsistente Daten. Somit ist eine
effiziente Einbindung und Parametrierung von z.B. Drives oder
anderen DP-Slaves möglich.
Dies gilt für folgende CPUs ab
der Firmware-Version 3.0:
|
S7-400 CPU
|
MLFB |
| CPU 412-1 |
6ES7 412-1XF03-0AB0 |
| CPU 412-2 |
6ES7 412-2XG00-0AB0 |
| CPU 414-2 |
6ES7 414-2XG03-0AB0 |
| CPU 414-3 |
6ES7 414-3XJ00-0AB0 |
| CPU 416-2 |
6ES7 416-2XK02-0AB0 |
| CPU 416-3 |
6ES7 416-3XL00-0AB0 |
| CPU 417-4 |
6ES7 417-4XL00-0AB0 |
| CPU 414-4H |
6ES7 414-4HJ00-0AB0 |
| CPU 417-4H |
6ES7 417-4HL01-0AB0 |
Tabelle 1: CPUs, die konsistenten Datenzugriff ohne SFC14/SFC15
ermöglichen
Bei einem direkten Zugriff
(z.B. L PEW oder T PAW) erfolgt kein
Peripheriezugriffsfehler.
Wichtig für die Umstellung
von der SFC14/15-Lösung auf die
Prozessabbild-Lösung:
-
Bei der Umstellung von der
SFC14/15-Lösung auf die Prozessabbild-Lösung ist die gleichzeitige
Nutzung über Systemfunktionen und über das Prozessabbild nicht
empfehlenswert. Grundsätzlich wird zwar das Prozessabbild beim
Schreiben mit der Systemfunktion SFC15 nachgeführt, aber beim Lesen
jedoch nicht. Das heißt, dass die Konsistenz zwischen
Prozessabbildwerten und den Werten der Systemfunktion SFC14 nicht
gewährleistet ist.
-
Die SFC 50 "RD_LGADR" gibt bei
der SFC 14/15-Lösung andere Adressbereiche aus als bei der
Prozessabbild-Lösung.
-
Wenn Sie eine CP 443-5 ext
einsetzen führt die gleichzeitige Nutzung über Systemfunktionen und
über das Prozessabbild zu folgenden Fehlern: Es ist kein
Lesen/Schreiben ins Prozessabbild möglich und/oder es ist kein
Lesen/Schreiben durch die SFC 14/15 mehr möglich.
Beispiel:
Das folgende Beispiel (für das Teilprozessabbild 3 "TPA
3") zeigt eine mögliche Projektierung in der HW-Konfig:
-
TPA 3 bei Ausgang: Diese 50 Bytes liegen konsistent im
Teilprozessabbild 3 (Klappliste "Konsistent über -> gesamte
Länge") und können somit über normale "Lade-Eingang xy"- Befehle
gelesen werden.
-
Die Auswahl in der Klappliste "Teilprozessabbild ->
---" unter Eingang bedeutet: keine Ablage in einem Prozessabbild.
Es ist nur das Handling mit den Systemfunktionen SFC14/15
möglich.
Bild
3: Projektierung der DP-Slave Eigenschaften in der HW-Konfig
|