TSPP

Dieses Kapitel dient als Leitfaden für die Registerkarte „TSPP“. Diese Registerkarte bietet Konfigurationsoptionen für die Verwendung von TSPP mit dem S7Plus-Treiber.

TSPP steht für das Time Stamp Push Protocol und wurde ursprünglich für den klassischen S7-Treiber implementiert. Eine Beschreibung der Funktionsweise und grundlegende Protokollinformationen finden Sie unter S7 - TSPP.

Abbildung 1. Abbildung: TSPP Konfigurations-Registerkarte

Allgemeine Informationen

Folgende Allgemeine Hinweise müssen bei der Verwendung von TSPP beachtet werden:

  • TSPP kann nur zum Lesen von Werten der SPS verwendet werden.
  • Für die Verwendung von TSPP werden keine komplexen Datentypen (Arrays) unterstützt.
  • Konfigurierte TSPP Adressen verwenden den Prefix "@TSPP."
  • Der Wert des Timestamp Elements (siehe Beschreibung unterhalb) wird auf den Zeitstempel der original config des konfigurierten DPEs geschrieben.

TSPP Daten Struktur

Die grundlegende Struktur der TSPP Buffer Daten muss ein Array aus TSPP Elementen beinhalten, welcher ein EOT (End-of-Transaction) Byte folgt, siehe Beispiel unterhalb.

Example

EventLog[0..n]
  + EventLog[0]
  - EventLog[1]
    ID
    Timestamp
    Value
  + EventLog[2]
  ...
  + EventLog[n]
  - EOT
  • Jeder Eintrag der TSPP Buffer Elemente muss der definierten TSPP Item Struktur entsprechen, welche unterhalb beschrieben wird.
  • Das Ende des Buffer-Arrays bzw. ein ID Wert von 0 (siehe TSPP Element Struktur unterhalb) wird als letztes Element betrachtet und beendet die Übertragung der Buffer-Elemente.
  • Der Wert der auf das EOT Element geschrieben wird beinhaltet die aktive Session ID auf Bit 0 und 1 und einen Indikator für das redundante System auf Bit 2.

TSPP Element Struktur

Die TSPP Elemente innerhalb der Buffer-Adresse müssen folgender Struktur folgen:

Element-Name Datentyp innerhalb des TIA Portals
ID UDInt
Value DWord
Timestamp LDT/Date_and_Time

Beispiel

EventLog
  EventLog[0]
    ID
    Value
    Timestamp
  EventLog[1]
    ID
    Value
    Timestamp
  ...
  EventLog[9]
    ID
    Value
    Timestamp
Abbildung 2. TSPP Architektur

Redundanz

Folgende Hinweise müssen beachtet werden, wenn TSPP in einem redundanten Projekt verwendet wird:

  • Bei Aktivierung des Config-Eintrages "[s7plus] onlyActivePolls" in einem redundanten System wird nur der aktive Treiber den TSPP-Puffer abfragen. Dies verhindert Probleme die durch limitierte SPS-Ressourcen entstehen könnten.

Konfigurations-Interface

TSPP Konfiguration

Set TSPP Mode active

Erlaubt es den TSPP Modus zu aktivieren/deaktivieren.

Lese-Intervall

Definiert den Intervall (in Millisekunden) für das Lesen des spezifizierten TSPP Buffer der SPS.

Buffer-Adress Konfiguration

Buffer-Adresse

Durch Betätigen der "Auswahl"-Schaltfläche kann die Buffer-Adresse gewählt werden.

Abbildung: S7+ Symbolische Adress-Auswahl

Time Stamp Push Protocol (TSPP) Version 2

Für das Time Stamp Push Protocol Version 2 wurde die innerhalb der SPS benötigte Datenstruktur überarbeitet und gestrafft, was zu Leistungsverbesserungen und einer weniger komplexen Datenstruktur für TSPP führt.

TSPP Version 2 kann durch Setzen des Konfigurationseintrags ../../cfg_doku/all_config_entries.html#s7plus__TsppVersion aktiviert werden:

[s7plus]
TsppVersion = 2

Standardmäßig ist nur die Version 1 aktiv, um die Abwärtskompatibilität mit bestehenden SPS-Konfigurationen zu gewährleisten. Ein Wechsel zu Version 2 erfordert eine Überarbeitung der SPS-Daten auf die unten beschriebene Struktur.

TSPP-Datenstruktur

Die gesamte TSPP-Pufferdatenstruktur muss ein Array von vorzeichenlosen 64-Bit-Ganzzahlen enthalten, gefolgt von einem EOT-Byte (End-of-Transaction), siehe nachstehendes Beispiel.

Je nachdem, ob implizite Einträge enthalten sind oder nicht, sieht die Datenstruktur anders aus. Es ist möglich, nur implizite, nur explizite oder implizite und explizite Einträge in einer Übertragung zu senden.

Implizite Einträge werden durch einen einzigen Zeitstempel definiert, der für alle Einträge gilt.

Explizite Einträge haben alle explizit zugewiesene Zeitstempel.

Keine Impliziten Einträge

EventLog[0..n]
 EventLog[0] // Amount of implicit entries = 0
 EventLog[1] // ID_1 and Value_1
 EventLog[2] // TimeStamp_1
 EventLog[3] // ID_2 and Value_2
 EventLog[4] // TimeStamp_2
…
 EventLog[n-1] // ID_n and Value_n
 EventLog[n] // TimeStamp_n
EOT

  • Das EventLog-Array muss vom Typ unsigned 64Bit Integer sein.
  • Der erste Eintrag des Arrays bestimmt, wie viele implizite Einträge folgen. In diesem speziellen Beispiel bedeutet EventLog[0] = 0, dass es keine impliziten Einträge gibt.
  • Wenn EventLog[0] gleich 0 ist, kommen die folgenden Einträge immer paarweise, um ein Element zu definieren. Der erste Eintrag eines Paares besteht aus der ID und dem Wert des Eintrags. Der zweite Eintrag ist der Zeitstempel des Eintrags.
  • Das Ende des Puffer-Arrays oder ein ID-Wert von 0 (siehe TSPP Item-Struktur unten) wird als Ende der Übertragung betrachtet und stoppt das Lesen der Puffer-Elemente.
  • Der in EOT geschriebene Wert enthält die aktive Session ID in den Bits 0 und 1 und einen Indikator für das redundante System in Bit 2.
  • Die IDs müssen nicht in der richtigen Reihenfolge sein.

Mit Impliziten Einträgen

EventLog[0..n]
 EventLog[0] // Amount of Implicit Entries = m
 EventLog[1] // Single timestamp for all implicit entries (TimeStamp_(1-m))
 EventLog[2] // ID_1 and Value_1
 EventLog[3] // ID_2 and Value_2
…
 EventLog[m+1] // ID_m and Value_m
 EventLog[m+2] // ID_m+1 and Value_m+1
 EventLog[m+3] // TimeStamp_m+1
 EventLog[m+4] // ID_m+2 and Value_m+2
 EventLog[m+5] // TimeStamp_m+2
…
 EventLog[n-1] // ID_n and Value_n
 EventLog[n] // TimeStamp_n
EOT

  • Das EventLog-Array muss vom Typ unsigned 64Bit Integer sein.
  • Der erste Eintrag des Arrays bestimmt, wie viele implizite Einträge folgen. In diesem speziellen Beispiel bedeutet EventLog[0] = m, dass es m implizite Einträge gibt.
  • Wenn EventLog[0] != 0 ist, enthält der folgende Eintrag EventLog[1] einen einzigen Zeitstempel, der auf alle nachfolgenden impliziten Einträge angewendet wird.
  • Beginnend mit EventLog[2] bis EventLog[m+1] enthalten alle Einträge eine ID und einen Wert eines impliziten Eintrags. Der einzige implizite Zeitstempel wird auf alle diese Einträge angewendet.
  • Beginnend mit EventLog[m+2] bis EventLog[n] sind alle folgenden Einträge paarweise, um ein explizites Element zu definieren. Der erste Eintrag eines Paares besteht aus der ID und dem Wert des Elements. Der zweite Eintrag ist der Zeitstempel des Eintrags.
  • Das Ende des Puffer-Arrays oder ein ID-Wert von 0 (siehe TSPP Item-Struktur unten) wird als Ende der Übertragung betrachtet und stoppt das Lesen der Puffer-Elemente.
  • Der in EOT geschriebene Wert enthält die aktive Session ID in den Bits 0 und 1 und einen Indikator für das redundante System in Bit 2.
  • Die IDs müssen nicht in der richtigen Reihenfolge sein.

TSPP Array Struktur

Wenn ein Array-Eintrag aus einer ID und einem Wert besteht, definieren die ersten 4 Bytes der vorzeichenlosen 64-Bit-Ganzzahl die ID und die letzten 4 Bytes den Wert.

Zum Beispiel:

EventLog[2] = 4997966434

4997966434 in binärer Form als vorzeichenlose 64-Bit-Ganzzahl sieht wie folgt aus:

00000000 00000000 00000000 00000001 00101001 11100110 11101010 01100010

Um die ID zu erhalten, sollten nur die ersten 4 Bytes betrachtet werden:

00000000 00000000 00000000 00000001 --> ID = 1

Um den Wert zu erhalten, sollten nur die letzten 4 Bytes betrachtet werden:

00101001 11100110 11101010 01100010 --> Value = 702999138

EventLog[2] enthält also ID = 1 mit dem entsprechenden Wert = 702999138.

Daher werden die ID und der Wert in vorzeichenlosen 32-Bit-Ganzzahlen gespeichert.

Beispiel für eine Datenstruktur mit 0 impliziten und 5 expliziten Einträgen.

Beispiel für eine Datenstruktur mit 10 impliziten und 10 expliziten Einträgen

Interner Datenpunkt für Buffer-Adressen