S7 Datenkonsistenz bei HMI Kommunikation

Beiträge
9.189
Reaktionspunkte
2.934
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich habe mal ein paar Versuche bezüglich Datenkonsistenz bei der HMI Kommunikation gemacht. Die S7-1200 und die S7-1500 verhalten sich bei dem Einbinden der Daten wie eine S7-400 oder eine S7-300 mit aktivierter priorisierter BuB-Kommunikation. Das heißt, Kommunikationsdaten können auch mitten im Zyklus in den SPS Datenspeicher (Datenbausteine) eingebunden werden.

Versuche habe ich mit einer S7-1214 mit Firmware V2.2 gemacht.

1. Test
=======
Ein Testprogramm mit libnodave schreibt einen 200 Byte großen Block in die SPS (Transportgröße BYTE).
Es wird abwechselnd das Bitmuster 0xa5a5... und 0x5a5a... geschrieben.
Im SPS-Programm ist ein nicht optimierter DB mit einem Datenarray von Typ Word angelegt.

Das Programm prüft dann auf Konsistenz mit:
Code:
FOR #i := 0 TO 98 BY 2 DO
  IF ("Datenbaustein_1".data[#i] XOR "Datenbaustein_1".data[#i +1]) <> w#16#ffff THEN
    #Inkonsistent := true;
  END_IF;
END_FOR;
Ergebnis:
Ein Block der in eine PDU passt und mittels Transportgröße BYTE in die SPS geschrieben wird, landet NICHT konsistent im Speicher.


2. Test
=======
Es wird öfters angemerkt, dass zur konsistenten Datenübertragung Rezepturen in WinCC flexible verwendet werden sollen.
In WinCCflexible 2008 habe ich mir dazu ein Rezept mit 10 DWord Variablen angelegt, die fortlaufend im Speicher adressiert werden. 10 DWord Variablen können über das S7-Protokoll auf jeden Fall noch in einer PDU von 240 Bytes als einzelner Schreibbefehl verschickt werden.
Dann habe ich zwei Datensätze angelegt. Einen mit abwechselnd 94741925 (0x05A5A5A5) und 173693530 (0x0A5A5A5A), einen Zweiten mit der anderen Reihenfolge. Das linke Nibble konnte nicht

verwendet werden, weil WinCCflex diese Werte nicht als Eingabe erlaubt.

Das Programm prüft dann auf Konsistenz mit:
Code:
FOR #i := 0 TO 8 BY 2 DO
  IF ("DB10DWord".data[#i] XOR "DB10DWord".data[#i + 1]) <> dw#16#fffffff THEN
    #Inkonsistent := true;
  END_IF;
END_FOR;
Ergebnis:
WinCC flexible schreibt einen Datensatz im S7 Protokoll mit Daten von der Transportgröße Dword. Es wird also nicht ein großer Speicherblock geschrieben, sondern 10 einzelne Variablen.
Wie nicht anders zu erwarten landet eine Rezeptur NICHT im Ganzen konsistent im Speicher.
Noch ein Phänomen ist, dass WinCCflex nicht immer die 10 Dword in einer PDU schreibt, sondern in seltsam zufälligen Werten geteilt (d.h. mal 6/4, 8/2 usw.). Durch dieses Verhalten landen die Rezepturdaten sogar bei den alten 300er Steuerungen NICHT konsistent im Speicher.


Bei meiner 1200er treten diese Effekte schon nach einigen wenigen Schreibbefehlen auf. Je kürzer das Gesamtprogramm, desto häufiger. Wenn nebenher noch der Online-Status beobachtet wird, quasi bei jedem Schreibbefehl.

Erkenntnisse wie sich die 1500 oder eine entsprechende 300/400er verhalten habe ich noch nicht. Interessant wäre auch noch, ob zumindest die angegebene Transportgröße im S7-Protokoll konsistent im Speicher landet, oder ein Byte-Array zumindest an Word oder Doppelwortgrenzen.
GGf. haben dann nämlich auch "optimierende" Kommunikationstreiber damit ein Problem, z.B. wenn eine Real-Zahl als Byte-Array geschrieben wird, und dieses nicht konsistent im Speicher landet.
 
Mit der Rezeptur, hätte ich auch nicht erwartet das es SPS-Zyklus Konsitent ist.
Ich habe das immer so betrachtet das die Daten Konsitent sind, wenn die Rezeptur
über den Status meldet das die Daten da sind und dann erst Konsitent.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich hätte schon erwartet, dass zumindest die Daten einer PDU am Stück eingebunden werden. Das gilt ja nicht nur für HMI Kommunikation, sondern auch für Put/Get Kommunikation zwischen Steuerungen. Mal angenommen ich schicke einer anderen Steuerung einen Startbefehl und einen zugehörigen Sollwert, kann es sein dass diese mit einem falschen Wert startet. Zumindest für 1-2 Zyklen.

Man angenommen es wird beim Einbinden ein Wert der über 4 Bytes geht zerstückelt, kann das zu komplett falschen Werten führen.
 
Mit libnodave war das aber auch schon bei 300-er SPS so, nicht konsistent.
Was denn für eine 300er, mit aktivierter priorisierter BuB Kommunikation?

Mit einer IM151-CPU (was intern eine 300er ist) sind die Daten einer PDU immer konsistent. Zumindest habe ich heute 100.000 Schreibbefehle bei einem minimal kurzen Programm durchlaufen lassen, und es ist keine Inkonsistenz aufgetreten
 
So was sollte nie gemacht werden.
Dafür gibt es guten alten Handshake..

bei einen Sollwert kann ich mir ja noch gut vorstellen, das es Funktioniert.
Wenn ich aber 100 - 200 Sollwerte schickt zb. bei einer Produktumstellung.
Wie will man den Handshake erledigen, wenn der Handshake früher da ist
als die Sollwerte.

Dann fahren 89 Achsen auf 100 und 11 Achsen nach 200.
 
Was denn für eine 300er, mit aktivierter priorisierter BuB Kommunikation?

Mit einer IM151-CPU (was intern eine 300er ist) sind die Daten einer PDU immer konsistent. Zumindest habe ich heute 100.000 Schreibbefehle bei einem minimal kurzen Programm durchlaufen lassen, und es ist keine Inkonsistenz aufgetreten
Kenn ich nur bei der 318er, die ist aber eine verkappte 400er. Die 300er kommuniziert am Systempunkt (konsistent), die 400er "dauernd" (inkonsistent).
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Das heißt eine 300er Kommuniziert Konsitent, aber über welche Breite der Daten?

Es ist doch sicherlich ein unterschied ob die HMI 2 oder 500 Werte schickt?
Meiner Meinung nach ist bei den 300ern eine PDU konsistent. Wenn eine 300er eine PDU Größe von 240 Bytes hat, sind maximal 212 Bytes konsistent. Dazu müssen diese aber als ein Block geschickt werden. Wenn man als einzeln addressierte DWord Werte verschickt (so wie es WinCC flexible macht), wären maximal 40 Bytes konsistent möglich, weil mehr nicht in eine PDU passen.
 
Tja, ich weiß auch noch nicht ob ich das Problem einfach ignorieren sollte. An einer realen Anlage mit einem großen Programm ist die Wahrscheinlichkeit gering, dass daraus Probleme entstehen. Aber da ist das Problem definitiv.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Also wenn man sicher gehen will, kann es doch nur bei einer Rezeptur gehen, deren Status ausgewertet wird.

Kannst du das nicht mal mit deinen Testaufbau nachstellen, nicht das der Status auch nicht funktioniert.
 
Meiner Meinung nach ist bei den 300ern eine PDU konsistent. Wenn eine 300er eine PDU Größe von 240 Bytes hat, sind maximal 212 Bytes konsistent. Dazu müssen diese aber als ein Block geschickt werden. Wenn man als einzeln addressierte DWord Werte verschickt (so wie es WinCC flexible macht), wären maximal 40 Bytes konsistent möglich, weil mehr nicht in eine PDU passen.
Wie rechnest Du das? Wie kommst Du auf 40 Bytes?
Im übrigen kann man bei den neuen 317er (EK14) anscheinend eine "optimierte Kommunikation" aktivieren. Dann ist auch nichts mehr mit "nur am Systempunkt". Hatte so ein Teilchen leider noch nicht auf dem Tisch um es genauer zu untersuchen.
 
Wie rechnest Du das? Wie kommst Du auf 40 Bytes?
Nochmal nachgerechnet wären es 44 Bytes ;-)

Wird eine Dword Variable geschrieben sind das:
- 12 Bytes Adresse
- 4 Bytes Data Header
- 4 Bytes Daten

= 20 Byte Gesamt pro Variable

240 Byte PDU - 10 Bytes Header - 2 Bytes Parameterkopf = 228

228 / 20 = 11 Dword Variablen mit 11*4 = 44 Bytes Nutzdaten
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Im übrigen kann man bei den neuen 317er (EK14) anscheinend eine "optimierte Kommunikation" aktivieren. Dann ist auch nichts mehr mit "nur am Systempunkt". Hatte so ein Teilchen leider noch nicht auf dem Tisch um es genauer zu untersuchen.

"priorisierte BuB-Kommunikation" nennt Siemens das.
 
Also wenn man sicher gehen will, kann es doch nur bei einer Rezeptur gehen, deren Status ausgewertet wird.

Kannst du das nicht mal mit deinen Testaufbau nachstellen, nicht das der Status auch nicht funktioniert.
Die Statusmeldung bestätigt dir nur, dass alle Daten eines Rezeptdatensatzes geschrieben werden konnten, das funktioniert schon. Was man mit dieser Information am Panel anfangen will weiß ich auch nicht, eigentlich wäre es eher für die SPS relevant. Oder du musst am Panel ein Skript an das Ereignis hängen, was dann ein Statusbit in die SPS hinterherschiebt um dieser zu signalisieren dass der Rezeptdatensatz komplett ist, und sie mit was auch immer loslegen kann.
 
Die Statusmeldung bestätigt dir nur, dass alle Daten eines Rezeptdatensatzes geschrieben werden konnten, das funktioniert schon. Was man mit dieser Information am Panel anfangen will weiß ich auch nicht, eigentlich wäre es eher für die SPS relevant. Oder du musst am Panel ein Skript an das Ereignis hängen, was dann ein Statusbit in die SPS hinterherschiebt um dieser zu signalisieren dass der Rezeptdatensatz komplett ist, und sie mit was auch immer loslegen kann.

Den Status kannst du doch beim lesen in der SPS vlt. auch verwenden.
 
Zurück
Oben