Beitragsliste anzeigen
S7-400 CPU 41x -- Kommunikation projektieren und programmieren -- Kommunikationsbausteine verwenden
Worin unterscheiden sich die Initialisierungs- und Laufzeitparameter an den Bausteinen für Modus TCP?
Warum wird am Baustein für Modbus TCP der Statuswert A090 (hex) ausgegeben, obwohl Sie die richtige Lizenz eingetragen haben?
Welche Unterschiede gibt es zwischen der lizenzierten Version und der downloadbaren Demoversion der Bausteine für Modbus TCP?
Warum wird der Wert A083 (hex) permanent am Ausgangsparameter STATUS des Bausteins für Modbus TCP ausgegeben, wenn der Eingangsparameter ENQ_ENR=true gesetzt wurde?
Welche Bausteine für Modbus TCP können Sie umbenennen oder umverdrahten, wenn die Bausteinnummern der Modus-Bausteine im Anwenderprogramm bereits verwendet werden?
Wie können Sie die Diagnosedaten aus einem modularen Sicherheitssystem SIRIUS 3RK3 mittels einer S7-300/400 CPU auslesen?
Welche Kommunikationsmöglichkeiten stehen für Sie bei SIMATIC S7 zur Verfügung?
Wie erfolgt der Datenaustausch mittels S7-Basiskommunikation zwischen S7-300/S7- 400 und S7-200 über MPI
Konsistente Daten in der S7-400, Zusammenfassung der Mechanismen
Welche Ports sind für die Modbus/TCP-Kommunikation freigegeben und wie viele Modbus-Clients können mit einer SIMATIC S7-CPU als Modbus-Server kommunizieren?
Wie kann zeitfolgerichtiges Melden mit S7-400 CPUs und WinCC realisiert werden?
Wie projektieren Sie eine spezifizierte und unspezifizierten S7-Verbindung für den Datenaustausch zwischen S7-300 und/oder S7-400 über Industrial Ethernet CPs?
Wie kann ich von einer SIMATIC S7 eine OPEN MODBUS / TCP Kommunikation aufbauen und wo erhalte ich weitere Informationen?
Wie kann mit WinCC flexible ein Projekt über S7-Routing in ein Bediengerät übertragen werden?
Welche Begrenzung für die aktiven Aufträge gibt es bei der Kommunikation mit SFC 58 / SFC 59 bzw. SFB 52 / SFB 53 über PROFIBUS DP bzw. PROFINET IO?
Wie werden die Kommunikationsbausteine FB63 "TSEND", FB64 "TRCV", FB65 "TCON" und FB66 "TDISCON" programmiert, um das ISO-on-TCP Protokoll für den Datenaustausch über die integrierte PROFINET-Schnittstelle einer CPU oder über den CP443-1 Advanced zu nutzen?
Wie werden die Kommunikationsbausteine FB63 "TSEND", FB64 "TRCV", FB65 "TCON" und FB66 "TDISCON" programmiert, um das TCP Protokoll für den Datenaustausch über die integrierte PROFINET-Schnittstelle einer S7-300 bzw. S7-400 CPU zu nutzen?
Wie werden die Kommunikationsbausteine FB67 "TUSEND", FB68 "TURCV", FB65 "TCON" und FB66 "TDISCON" programmiert, um das UDP Protokoll für den Datenaustausch über die integrierte PROFINET-Schnittstelleeiner CPU zu nutzen?
Wie können Sie auf konsistente Daten ohne SFC14/15 als Teil des Prozessabbildes zugreifen?
Wie groß ist die Datenkonsistenz bei den S7-Kommunikationsfunktionen PUT und GET für die einzelnen S7-400 CPUs?
Konsistente Daten in der S7-400, Zusammenfassung der Mechanismen
Bestellnummer:

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:

  • Merker

  • DB-Inhalte

  • Prozessabbild der Eingänge

  • Prozessabbild der Ausgänge

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

 

 Beitrags-ID:11646774   Datum:2002-05-17 
Dieser Artikel...hat mir geholfenhat mir nicht geholfen                                 
mySupport
My Documentation Manager 
Newsletter 
CAx-Download-Manager 
Support Request
Zu diesem Beitrag
Drucken
PDF erstellen 
Beitrag versenden
QuickLinks
Kompatibilitäts-Tool 
Hilfe
Online Hilfe
Guided Tour