- Beiträge
- 9.189
- Reaktionspunkte
- 2.934
-> 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:
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:
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.
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;
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;
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.