Inhaltsverzeichnis
Werbung
4.4. Telegrammpufferung
4.4.1. Nutzung Telegrammspeicher
Bereits ab V1.0 werden 4 Datenbausteine als Telegrammspeicher (genauer Ereignispuffer zwischen Pro-
zessbausteinen und Fernwirkprotokoll) angelegt und wie folgt verwendet:
-
TX_Buf_1 (Telegrammspeicher 1): Default Länge 1000h=4096 Byte
für organisatorische Einträge (Anlaufmeldung, Bestätigungstelegramme, ...)
-
TX_Buf_2 (Telegrammspeicher 2): Default Länge 1000h=4096 Byte
Einträge von Prozessbausteinen (Sli,...) mit Prio High
-
TX_Buf_3 (Telegrammspeicher 3): Default Länge 1000h=4096 Byte
Einträge von Prozessbausteinen (Sli,...) mit Prio Low
-
TX_Buf_4 (Telegrammspeicher 4): Default Länge 200h=512 Byte
reserviert für niederpriore Anwendungen, derzeit nicht verwendet
Die Puffer-DBs werden im Anlauf erzeugt, wobei die Längen im Instanz-DB von S7_IEC_Config einzeln
vorgegeben und damit als eine Art ‚Hintergrundparameter' verfügbar sind.
Grundsätzlich ist auch in V1.1 die Größe eine Puffers auf EINEN DB beschränkt (keine DB-übergreifende
Pufferung). In größeren System (S7-400, CP317PN) beträgt die max. DB-Größe 64kB, bei S7-300-
Systemen normalerweise 16kB (siehe S7-Handbuch).
Als Richtwert für Speicherverbrauch pro Info können ca. 40 Bytes angenommen werden. Damit können
pro Puffer eingetragen werden:
Bei 4096 Byte: ca. 100 Infos
Bei 16 kByte: ca. 400 Infos
Bei 64 kByte: ca. 1600 Infos
Ein Eintrag in einen der Puffer entsteht unabhängig von der Übertragungsursache, also auch bei Gene-
ralabfragen und zyklischen Sendevorgängen. Allerdings werden von den Sli-Bausteinen (bereits in V1.0)
zyklische Einträge nur dann gemacht wenn der Puffer zu weniger als 50%, abgefragt wenn er zu weniger
als 70% gefüllt ist. Der restliche Platz verbleibt in jedem Fall für spontane Änderungen.
In V1.0 wurden die Telegrammspeicher in allen Master-Paketen kontinuierlich gelöscht (um zu vermei-
den, dass Befehle gespeichert werden), in Slave-Paketen blieben die während Verbindungsstörungen
aufgelaufenen Infos stehen (älteste Infos – siehe oben).
Während in Master-Systemen weiterhin vorrangig NICHT gepuffert werden sollte gliedern sich die Anfor-
derungen im Slave kundenspezifisch wie folgt:
a) Nach gehenden Verbindungsstörungen sind keine alten Infos erwünscht
b) Über Verbindungsstörungen hinweg darf / soll kein Infoverlust auftreten.
Ab Version 1.1 ist das gewünschte Verhalten hinsichtlich Telegrammpufferung in allen Paketen paramet-
rierbar über ‚Buffer_Handling' (Parametereingang von S7_IEC_Config).
Details siehe Kapitel 4.4.3.
Ab Version V1.3 können nun statt zweier fester Puffer bis zu maximal 16 Prio-Puffer parametriert werden,
einstellbar über den Parameter „No_of_Send_Buffers" am FB100. Mit dem Parameter „Send_Buffer_Dim"
können Sie die Größe der einzelnen Puffer einstellen. Dabei gelten die oben genannten Grenzen in Be-
zug auf DB-Größe.
Jeder Puffer wird mit einer bestimmten Priorität behandelt. Der erste Puffer (Puffer 0) wird höchstprior
entsorgt, während der 16. (Puffer 15) mit niedrigster Priorität bearbeitet wird.
Eingestellt wird die Priorität, mit der eine Information übertragen werden soll, an den jeweiligen Erfasser-
bausteinen (SLi_xyz) über den Eingangsparameter „Tx_Prio", Wertebereich 0..15.
Wird am Erfasserbaustein eine Priorität eingestellt, die nicht vorhanden ist – beispielsweise sind 5 Prio-
Puffer angelegt worden, die eingestellte Prio am Erfasser beträgt jedoch 8 – so wird automatisch die
nächste, niederwertigste Prio verwendet, in diesem Beispiel 4.
SIPLUS RIC IEC on S7 V1.5
Funktionsbeschreibung
Seite 68 von 235
I IA CE
©SIEMENS AG 2013
Quicklinks ausblenden:
Werbung
Inhaltsverzeichnis
