# S7 Datenkonsistenz bei HMI Kommunikation



## Thomas_v2.1 (20 Februar 2015)

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:

```
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:

```
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.


----------



## rostiger Nagel (20 Februar 2015)

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.


----------



## Thomas_v2.1 (20 Februar 2015)

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.


----------



## Ralle (20 Februar 2015)

Mit libnodave war das aber auch schon bei 300-er SPS so, nicht konsistent.


----------



## Thomas_v2.1 (20 Februar 2015)

Ralle schrieb:


> 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


----------



## kons (21 Februar 2015)

> Mal angenommen ich schicke einer anderen Steuerung einen Startbefehl und einen zugehörigen Sollwert


So was sollte nie gemacht werden. 
Dafür gibt es guten alten Handshake..


----------



## rostiger Nagel (21 Februar 2015)

kons schrieb:


> 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.


----------



## Rainer Hönle (21 Februar 2015)

Thomas_v2.1 schrieb:


> 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).


----------



## rostiger Nagel (21 Februar 2015)

Rainer Hönle schrieb:


> Kenn ich nur bei der 318er, die ist aber eine verkappte 400er. Die 300er kommuniziert am Systempunkt (konsistent), die 400er "dauernd" (inkonsistent).



Rainer, was ist den der Systempunkt?


----------



## Rainer Hönle (21 Februar 2015)

rostiger Nagel schrieb:


> Rainer, was ist den der Systempunkt?



Helmut, der Zeitpunkt nach dem Ende des einen und vor dem Anfang des nächsten OB1-Aufrufs. Dort werden auch die PAEs und PAAs aktualisiert.


----------



## rostiger Nagel (21 Februar 2015)

Rainer Hönle schrieb:


> Helmut, der Zeitpunkt nach dem Ende des einen und vor dem Anfang des nächsten OB1-Aufrufs. Dort werden auch die PAEs und PAAs aktualisiert.



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?


----------



## Thomas_v2.1 (21 Februar 2015)

rostiger Nagel schrieb:


> 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.


----------



## rostiger Nagel (21 Februar 2015)

Dann kann es doch nicht funktionieren das die Daten Konsitent ankommen, 40 Byte on Block ist doch nichts.


----------



## Thomas_v2.1 (21 Februar 2015)

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.


----------



## rostiger Nagel (21 Februar 2015)

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.


----------



## Rainer Hönle (21 Februar 2015)

Thomas_v2.1 schrieb:


> 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.


----------



## Thomas_v2.1 (21 Februar 2015)

Rainer Hönle schrieb:


> 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


----------



## Thomas_v2.1 (21 Februar 2015)

Rainer Hönle schrieb:


> 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.


----------



## Thomas_v2.1 (21 Februar 2015)

rostiger Nagel schrieb:


> 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.


----------



## rostiger Nagel (21 Februar 2015)

Thomas_v2.1 schrieb:


> 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.


----------



## Thomas_v2.1 (21 Februar 2015)

rostiger Nagel schrieb:


> Den Status kannst du doch beim lesen in der SPS vlt. auch verwenden.


Indem ich es selber am Panel nachprogrammiere. Oder meinst du was anderes?


----------



## rostiger Nagel (21 Februar 2015)

der Status ist doch beim lesen und beim schreiben wirksam, ich bin bisher davon ausgegangen,
wenn dazu eine SPS Variable genutzt wird, das diese dann auch den zustand rausgiebt, ob
der Datensatz komplett gelesen bzw. geschrieben ist und die Werte auch gültig in der Steuerung
stehen.


----------



## Thomas_v2.1 (21 Februar 2015)

Ah, du meinst den Bearbeitungsstatus bei der WinCCflexible Funktion SchreibeDatensatzInSteurung. Das funktioniert wirklich. Wenn ich das anstoße wird erst nur der Bearbeitungsstatus=2 geschrieben, dann eine oder mehrere PDUs mit den Rezeptdaten, und dann nochmal separat der Bearbeitungsstatus=4 hinterher. Wenn man das im SPS-Programm auswertet (d.h. solange Bearbeitungsstatus=2 dann Finger weg) ist es garantiert konsistent. 
Den Status auszuwerten ist über die erweitere Rezepturanzeige aber nicht möglich, wenn ich das richtig sehe.


----------



## Thomas_v2.1 (21 Februar 2015)

Zu früh gefreut. Die Auswertung des Bearbeitungsstatus ist wohl nur bei einer 300er mit "nicht priorisierter BuB Kommunikation" ausreichend.

Ich habe bei meiner 1200er diesen Status auf ein Merkerwort gelegt, die Rezeptdaten in einen DB. Trotz Auswertung des Bearbeitungsstatus habe ich inkonsistente Daten in dem DB. Evtl. werden Merkerbereiche eher oder anders eingebunden als Datenbausteine.


----------



## Thomas_v2.1 (21 Februar 2015)

Bei der 1200er habe ich mir eben selber einen Fehler eingebaut, indem ich den Bearbeitungsstatus als InOut verwendet habe. Wenn man das richtig macht, dann funktioniert das mit dem Bearbeitungsstatus wohl auch bei Steuerungen welche die Daten mitten im Zyklus einbinden zuverlässig.


----------



## Larry Laffer (21 Februar 2015)

Hallo Thomas,
erstmal recht herzlichen Dank für deine Untersuchungen zu diesem (mich auch brennend interessierenden) Thema und im gleichen Zug für diesen Thread.
Für mich ist an dieser Stelle immer wieder interessant, Ereignisgesteuert Daten aus der SPS zu Lesen um sie dann zu speichern - es handelt sich hier i.d.R. um Daten, die zu einem gefertigten Bauteil erfasst / ermittelt wurden.
Wenn ich dich also recht verstanden habe dann ist es so, dass wenn man "priorisierte BuB" aktiviert hat man bei einer neueren 317 oder sogar einer 319 auch nicht sicherstellen kann, dass man mit der Rückmeldung der Lade-Routine die Daten wirklich zusammengehörig in der Visu hat ...? (es können also immer noch "alte" Daten mit in dem Block stecken ?)

Gruß
Larry


----------



## Thomas_v2.1 (21 Februar 2015)

Prinzipiell geht das nur 100%ig zuverlässig mit einem extra Handshake.
D.h. wenn man einen Datensatz konsistent aus der SPS lesen will, muss man erst ein Flag in der SPS setzen damit diese die Daten nicht mehr schreibend anfasst. Dann die Daten auslesen und über ein Flag die Bearbeitung in der SPS wieder freigeben.


Ich habe gerade nochmal versucht aufzudröseln wie weit die Daten überhaupt konsistent geschrieben werden. Im S7-Protokoll gibt es die Möglichkeit als Transportgröße DWord anzugeben. Selbst damit landet nicht einmal dieses DWord garantiert konsistent im Speicher!
Mein Testprogramm schreibt abwechselnd 0xa5a5a5a5 und 0x5a5a5a5a in die SPS. Mein SPS Programm prüft ob eines dieser beiden erlaubten Werte im Datenbaustein stehen, und das ist NICHT immer der Fall.

Beispiel was das für Auswirkungen haben kann:
Ich habe einen Sollwert als DINT.
Erste Einstellung: 1 (16#0000_0001)
Jetzt schreibt jemand von der Visualisierung einen neuen Sollwert -1 (16#FFFF_FFFF).
Es besteht die Möglichkeit, dass die SPS für einen oder mehrere Zyklen den Wert 65535 (16#0000_FFFF) sieht.

Es wäre zu prüfen ob das nur bei der 1200er so ist, oder ob das die 300/400er auch schon ignoriert haben.


----------



## christoph2630 (23 Mai 2015)

Hallo alle,
habe auch gerade ein Projekt mit einer 1200 + WinCC RT. Das HMI sendet Auftragsdaten an die SPS, bestehend aus diversen Sollwerten und Startbefehlen.
Ich stelle nun in der SPS die Aktualität sicher mit folgendem Mechanismus:
- die SPS initialisiert die Sollwerte im Auftragsdatenbaustein mit lauter -999999 Werten (also prozesstechnisch irgendein unsinniger Wert)
- die RT beschreibt alle Sollwerte neu und setzt das Startbit
- SPS erkennt irgendwann das Startbit und wartet solange, bis alle Sollwerte <> -999999 sind. Dann werden alle relevanten Sollwerte in einen separaten DB übernommen und effektiv gestartet. Bei Übernahme der Daten werden die HMI-Auftragsdaten wieder mit -999999 beschrieben.

Das erscheint mir als effiziente Prüfungsmethode - was meint ihr dazu?

LG, Christoph


----------



## Thomas_v2.1 (23 Mai 2015)

Sollte vom Prinzip her funktionieren.

Wenn du Rezepturen an einem Siemens-HMI verwendest, sollte es aber auch funktionieren wenn du den Bearbeitungsstatus in der SPS auswertest. Zumindest habe ich dabei noch keine Inkonststenz festgestellt.

Mit deiner Variante bist du unabhängig von Funktionen eines Siemens Gerätes, d.h. könntest unter Umständen auch eine andere Visualisierung verwenden.


----------



## Thomas_v2.1 (14 April 2017)

Mal eine Frage an die TIA-Experten:

Wie muss ich bei der Stringverarbeitung in der SPS (1200/1500) vorgehen, damit ein HMI garantiert einen konsistenten String einliest?
Die Strings liegen in optimierten Datenbausteinen.

Beispielweise wenn ich einen String dynamisch in der SPS mit CONCAT zusammensetze, dann muss ich wenn ich direkt auf dem HMI-String arbeite damit rechnen, dass der String während der Bearbeitung gelesen wird.
Jetzt könnte ich auf einem temporären String arbeiten, und wenn dieser fertiggestellt ist dem HMI-String zuweisen. Es ist jedoch nirgends angegeben, dass diese Operation ununterbrechenbar ist. Es wird dann höchstens die Wahrscheinlichkeit verringert, dass ein nicht konsistenter String gelesen wird.

Mit UMOVE_BLK lassen sich direkt keine Strings in "optimierten" DBs verschieben.


----------



## Fabpicard (14 April 2017)

Wenn du einen String zusammen baust, kostet das in der CPU wesentlich mehr Rechenzeit, als nur den fertig gebauten auf den Zugriffsbereich des HMI zu kopieren.
Das reine Kopieren sollte also so schnell laufen, das die Wahrscheinlichkeit das HMI liest nur einen Teil der neuen Daten weil es mitten in diesem Kopiervorgang liest, so gering ist, das du eher deinen Platz bei der NASA bekommst und zum Mars fliegst 

MfG Fabsi


----------



## Thomas_v2.1 (14 April 2017)

Das mit "die Wahrscheinlichkeit ist sehr gering" hatte ich bei der S7-400 schon einmal die sich bezüglich Kommunikation gleich verhält, und habe das Programm dann anschließend umgestellt als das Problem dann doch gelegentlich aufgetreten ist. Je kleiner das Programm ist, desto größer ist die Wahrscheinlichkeit.

Ich will es aber nicht höchstwahrscheinlich richtig machen, sondern richtig machen.
Und ich habe noch keinen Weg gefunden wie ich es richtig machen kann.


----------



## PN/DP (14 April 2017)

Fabpicard schrieb:


> Das reine Kopieren sollte also so schnell laufen, das die Wahrscheinlichkeit das HMI liest nur einen Teil der neuen Daten weil es mitten in diesem Kopiervorgang liest, so gering ist, das du eher deinen Platz bei der NASA bekommst und zum Mars fliegst


Das kannst Du voll vergessen. Weil SPS zyklisch arbeiten und das auch noch sooo schnell, kann man sich bezüglich Wahrscheinlichkeit für das Auftreten von "unwahrscheinlichen" Ereignissen merken: wenn eine Wahrscheinlichkeit > 0 besteht, dann wird das Ereignis noch zu Lebzeiten des Programmierers und ganz bestimmt auch noch während der Gewährleistungszeit auftreten.

SPS-programmieren hat exakt zu erfolgen und nicht so schlampig wie bei vielen Computer- oder Smartphone-Programmen. Eine Einstellung "_das wird schon nicht passieren, und wenn, dann merkt es bestimmt keiner_" zeugt von Verantwortungslosigkeit und disqualifiziert einen SPS-Programmierer für seinen Job.

Harald


----------



## Blockmove (14 April 2017)

Letztlich bleibt eigentlich nur das Arbeiten mit getrennten Datenbereichen für HMI und Logik.
Also eigenen Zykluskontrollpunkt bzw. HMI-Prozessabbild bauen.
Alles andere macht irgendwann Ärger

Gruß
Blockmove


----------



## Zombie (14 April 2017)

Ich mache bei beiden Richtungen (wenn ich es kann) ein zeitversetztes Freigeben.
Z.B. wenn ich Daten aus der Visu übertragen muss, gebe ich die Daten ein und speichere sie in der SPS ab. Dann muss man bestätigen und eine Wartezeit muss ablaufen. Vorher akzeptiere ich die eingegebenen Daten einfach nicht. So wird kein VOrgang mit halben Daten gestartet.

Auf der Visu läuft das etwas anders. Dort lasse ich die Daten in die Variablen schreiben und lasse dann eine Wartezeit auf der SPS ablaufen, die ein Bit setzt womit ich die Sichtbarkeit der angezeigten Daten steuere. Durch die Wartezeit muss die Visu die Daten gelesen haben, bevor sie im übernächsten Abfragezyklus das Bit zum anzeigen bekommt.

So kann ich zu jeder Zeit sicherstellen, dass nur angezeigt wird was auch vollständig ist. 
Das schließt leider schnelle Anzeigenwechsel aus, da ich mindestens 3 Sekunden brauche bis alles korrekt angezeigt wird.


----------



## Thomas_v2.1 (14 April 2017)

Zugriffe auf einfache Datentypen stellen auch kein unlösbares Problem dar, da diese höchstwahrscheinlich (wahrscheinlich weil von Siemens nicht dokumentiert) mit atomaren d.h. ununterbrechenbaren Anweisungen geschrieben werden können.
Wenn ich eine z.B. 16-Bit Integervariable beschreibe, dann geschieht das mit einer einzigen Anweisung die nicht unterbrechenbar ist.

Bei Variablen mit größeren Längen wie auch bei Strings ist das wahrscheinlich nicht mit einer atomaren Anweisung möglich.
Wenn ich selber auf einem Controller programmiere und ich Variablen auch in Interrupts verwende, dann ist das nur ohne anzunehmende Fehler möglich wenn ich auf diese Variablen mit atomaren Anweisungen zugreifen kann, oder ich muss die Interrupts für den Zeitraum des Zugriffs sperren. Das kann ich aber dann alles im Datenblatt des Controllers nachlesen, bzw. mir den Assemblercode ansehen.

Bei den 1200/1500 weiß ich das aber nicht wie Siemens das umgesetzt hat. Wenn ich aber davon ausgehe, dass Strings nicht mit atomaren Anweisungen kopiert werden können, fehlen mir so wie es aussieht die Werkzeuge um das zu gewährleisten. Das wäre nur mit einer Anweisung wie dem UMOVE_BLK möglich (das Äquivalent dazu könnte für diesen Zweck auch auf der S7-400 verwendet werden), der aber gerade so wie es aussieht mit Strings nicht funktioniert. Wahrscheinlich ist das Problem mit anderen großen Datentypen wie DT auch vorhanden.

Am einfachsten wäre es wenn es zwei Anweisungen gäbe mit denen es möglich ist HMI-Zugriffe zu sperren und wieder freizugeben.


----------



## ducati (15 April 2017)

Blockmove schrieb:


> Letztlich bleibt eigentlich nur das Arbeiten mit getrennten Datenbereichen für HMI und Logik.
> Also eigenen Zykluskontrollpunkt bzw. HMI-Prozessabbild bauen.
> Alles andere macht irgendwann Ärger
> 
> ...


tja, da hast Du leider Recht! Nur wer macht das denn in der Praxis? Vor allem wenn Siemens in den tollen 5min Videos einfach ne xbeliebige Variable per Drag n Drop aus dem SPS-Programm in die Visu zieht...
Das Ganze stoert mich bei den 400er schon lange. Bei den 300er ist es zum Glueck kein Problem, solange niemand diesen Haken setzt....
M.M. nach wollte Siemens in den neuen Steuerungen auf Teufel komm raus werbewirksam die Kommunikation beschleunigen! Warum um Gottes Willen haben die das nicht einstellbar gemacht?
Wir habens letztens mal getestet, ner 300er mit dem "priorisierte BuB" Haken kommuniziert genauso schnell wie ne 1500, wenn man die PDU ausser acht laesst.
Die Kommunikation mit HMI und anderen SPSn zu vereinfachen waere mal ne wirklich gute Sache gewesen, stattdessen machen die das mit dem TIA noch kommplizierter...
Danke Siemens!


----------



## Fabpicard (15 April 2017)

PN/DP schrieb:


> Eine Einstellung "_das wird schon nicht passieren, und wenn, dann merkt es bestimmt keiner_" zeugt von Verantwortungslosigkeit und disqualifiziert einen SPS-Programmierer für seinen Job.



Harald, ich schrieb nichts von "das merkt schon keiner"...
Da die tollen TIA-CPUs nun aber keinen eigenen Zykluskontrollpunkt mehr haben, bekommt man die gleichen Probleme wie bei den 400er CPUs vorher auch.
(gut, das wissen wir alle...)

Also was bleibt einem dann an Möglichkeiten?

a) eigenen Zykluskontrollpunkt schreiben. / Hier besteht nun einmal die Gefahr, dass das HMI genau in diesem kurzen Umkopierzeitraum liest/schreibt. Da bleibt nur die Wahrscheinlichkeitsanalyse mit der man dann bewerten muss, ob und wie wahrscheinlich dieses Ereignis eintreten kann und den Betrieb der Anlage stört.

b) eine Möglichkeit wie zombie sie beschreibt, was noch aufwändiger ist und alle sonstigen Nachteile enthält. Zusätzlichen Eingriff durch den Bediener und Wartenzeiten bei der Kommunikation.

( Möglichkeit c) einfach so arbeiten, als wäre es wie bei den 300er geht auch, klammere ich hier aber einfach aus, weil sche*** )

Aus diesen Möglichkeiten muss nun der Programmierer verantwortungsbewusst, die für seine Anwendung optimale Version auswählen und korrekt umsetzen. 

Wir haben auch Anlagen, bei der teils für eine SPS "riesige Datenmengen" auf einen Schlag geändert werden. Das geht dann eben nur bei Auftragswechsel oder in Zeiten auf denen die SPS eben nicht auf diese Daten zugreift.

Solltest du noch eine mir bisher unbekannte wesentlich bessere Möglichkeit kennen, dann würde ich mich natürlich freuen, dies mal an einer unserer Anlagen auszuprobieren 

MfG Fabsi


----------



## Thomas_v2.1 (15 April 2017)

Bei der 400er kann ich dieses Problem aber durch UBLKMOV konkret bei Strings umgehen.
Wir haben nämlich beispielsweise eine Anlage, wo wir einem MES-System einen eingescannten Barcode als String übermitteln. Bzw. das MES greift über einen OPC-Server auf die Daten zu. Ich wollte zwar ein zusätzliches Handshakesignal, aber der vom MES wollte es so haben, dass er auf eine Änderung des Strings reagiert. Funktioniert ja auch prinzipiell.
Wenn wir die Anlage jetzt mit einer 1500er umsetzen dann muss ich dem Kunden sagen, dass es jetzt einmal wöchentlich zu einem Datenversatz kommt, weil das mit der 1500er nicht mehr zuverlässig umzusetzen ist. Bei 10.000 Stück pro Tag ist man sehr schnell an der Eintrittswahrscheinlichkeit von 1.


----------



## Blockmove (15 April 2017)

@Thomas

Bei der Kopplung zum MES kämpe ich genau mit den selben Themen.
Ich arbeite hier mit getrennten Datenbereichen, aber auch hier sind zusätzliche Handshakes notwendig.
Da ich aber systembedingt nix am Verhalten ändern kann, muß eben der MES-Programmierer hier damit klar kommen.
Allerdings arbeiten die MES-Kollegen wohl zusammen mit Siemens an OPC-UA. Da werden sie wohl auf die selben Tretminen treffen 

Gruß
Blockmove


----------



## Larry Laffer (15 April 2017)

Die Lösung für dieses Problem wäre, die Variable (ob nun String oder Array oder Struct) bit-getriggert zu lesen.
Ich hatte schon einmal (zu Flex-Zeiten) versucht, die bit-getriggerten Kurven dafür zu missbrauchen. Das konnte man für einen String (da habe ich es nicht gebraucht) oder für ein Array ganz gut machen - für ein Struct war es hingegen nicht sinnvoll umsetzbar, da mir im VB-Script "ein bißchen" die Konverter gefehlt haben.

Aber @Thomas:
Vielleicht wäre es für deinen String (wenn es nicht zu viele sind) ein umsetzbarer Work-Around - TIA müßte das eigentlich noch genauso machen können ...

Gruß
Larry


----------



## Thomas_v2.1 (15 April 2017)

Ich stelle die Daten der Gegenseite nur zur Verfügung, d.h. ich kann es über ein Triggerbit nicht kontrollieren. Die einzige Möglichkeit die ich sehe ist wieder auf "nicht optimierte" DBs zu wechseln, denn da scheint es auch bei der 1500 ein UBlockmove zu geben.
Das ist aber ein grundsätzliches Problem: wie kann ich für die normalen HMI-Zugriffsfunktionen Konsistenz über größere Datensätze gewährleisten.


----------



## Larry Laffer (15 April 2017)

Thomas_v2.1 schrieb:


> Das ist aber ein grundsätzliches Problem: wie kann ich für die normalen HMI-Zugriffsfunktionen Konsistenz über größere Datensätze gewährleisten.



Nach meiner Meinung gibt es da in der Siemens-Welt (also TIA-WinCCFlexibel) zur Zeit keine Option.
Man bräuchte (und darüber bin auch schon öfters gestolpert) eine Funktion, die eine gwünschte Variable (oder einen Variablenblock oder eine Struktur) quasi synchron einliest - wenn das nur in einem Script funktionieren würde dann hätte ich damit gar kein Problem - aber das gibt es leider nicht und ich kann mir auch nicht vorstellen, das Siemens so etwas angehen würde ...

Gruß
Larry


----------



## Thomas_v2.1 (16 April 2017)

Ich habe gestern mal ein paar kurze Tests gemacht. Wenn ein String gelesen wird der direkt mit Concat zusammengesetzt wird, dann führt das wie nicht anders zu erwarten zum gelegentlichen Lesen von Strings während der Bearbeitung.
Wenn ich den String in einer temp-Variable zusammensetze und dann in den HMI-Bereich umkopiere, habe ich bisher bei ~2000 Lesevorgängen noch keinen Fehler feststellen können, auch wenn das SPS-Programm nichts anderes macht als nur diesen String zu kopieren.

Es könnte natürlich auch sein, dass Siemens so eine String-Kopierfunktion intern ununterbrechenbar gestaltet hat, oder mein Programm wird intern irgendwie soweit optimiert wird, dass ich das Problem nicht mehr sehen kann. Mal sehen ob ich den Test noch etwas mehr automatisieren kann und es dann ein paar Stunden laufen lassen kann.

Wobei es eigentlich der falsche Weg ist als Programmierer so etwas auszuprobieren müssen. Das gehört eigentlich ordentlich dokumentiert.


----------



## Thomas_v2.1 (16 April 2017)

Strings werden defintiv nicht konsistent / ununterbrechenbar kopiert. Ich habe das SPS-Programm nochmal vollständig aufgeräumt, Webserver deaktiviert usw.

CPU: 1214 FW2.2, Zykluszeit 1ms
Client: WinCC 7.3, Aktualisierung alle 250ms


```
#tmpString1 := 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa';
#tmpString2 := 'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb';
IF ((#num1 MOD 2) = 0) THEN
    "HMISTRINGS".testString1 := #tmpString1;
ELSE
    "HMISTRINGS".testString1 := #tmpString2;
END_IF;
```
#num1 ist eine Variable die jeden Zyklus um 1 erhöht wird.

Ungefähr jeder 250. Lesevorgang ist nicht konsistent, d.h. der String besteht dann zum Teil aus 'a' und zum Teil aus 'b'.


----------



## Fabpicard (16 April 2017)

Auf der Gegenseite zur SPS, zumindest bei den PC-Systemen könnte man noch eine "Korrekt-Abfrage" sehr einfach realisieren:
Der gelesene Datensatz muss 2 oder 3 mal hintereinander den genau gleichen Inhalt haben, dann filterst du solche falschen Lesezyklen automatisch aus, weil dies nie 2 mal hintereinander passieren kann...
Verlangsamt natürlich etwas die Kommunikation...

MfG Fabsi


----------



## Blockmove (16 April 2017)

Fabpicard schrieb:


> Auf der Gegenseite zur SPS, zumindest bei den PC-Systemen könnte man noch eine "Korrekt-Abfrage" sehr einfach realisieren:
> Der gelesene Datensatz muss 2 oder 3 mal hintereinander den genau gleichen Inhalt haben, dann filterst du solche falschen Lesezyklen automatisch aus, weil dies nie 2 mal hintereinander passieren kann...
> Verlangsamt natürlich etwas die Kommunikation...
> 
> MfG Fabsi



Solange du Einfluß auf das PC-Programm hast ...

Wir haben gerade sowieso Kontakt mit Softing. Ich frag mal bei denen nach, ob sie das Verhalten mit ihrem OPC-Server verifizieren können.
Die Kollegen von Delta Logic sind ja hier im Forum vertreten. Vielleicht kommt da ja auch eine  Aussage.

Gruß
Blockmove


----------



## Thomas_v2.1 (16 April 2017)

Fabpicard schrieb:


> Auf der Gegenseite zur SPS, zumindest bei den PC-Systemen könnte man noch eine "Korrekt-Abfrage" sehr einfach realisieren:
> Der gelesene Datensatz muss 2 oder 3 mal hintereinander den genau gleichen Inhalt haben, dann filterst du solche falschen Lesezyklen automatisch aus, weil dies nie 2 mal hintereinander passieren kann...
> Verlangsamt natürlich etwas die Kommunikation...



Wenn du weißt wie ein richtiger Datensatz aussieht, dann brauchst du ihn ja gar nicht erst zu lesen. Da müsste man an den String schon eine Prüfsumme an das Ende anhängen.

Bei meinem Test verwendet WinCC die zyklischen Lesedienste. D.h. es meldet den Datenbereich mit dem String für die automatische Aktualisierung im Zeitraster von 250ms an.
Die SPS schickt dann auf jeden Fall alle 250ms ein Telegramm, aber es sind dort nur Daten enthalten wenn sich der String auch ändert. Darum kommt auch nicht alle 250ms ein String über die Leitung, weil es sein kann dass zufällig zum Intervall der gleiche Stringinhalt vorhanden ist.

Daran, dass trotzdem ein inkonsistenter String gesendet wird, kann man auch sehen wie das in der SPS umgesetzt wird. Wenn sich ein HMI anmeldet, wird in der SPS eine Art Interrupt gebildet, der in dem angefragten Intervall das SPS-Programm an beliebiger Stelle unterbricht und dann die angeforderten Speicherbereiche zusendet.

Es gibt auch noch die nicht-zyklischen Lesedienste, d.h. normales Polling. Da müsste man testen ob diese anders verarbeitet werden. Bei WinCC/TIA-WinCC und den meisten OPC-Servern habe ich aber keine Kontrolle darüber wie die Variablen gelesen werden, ich kann aber sehen welche Dienste verwendet werden. Die Siemens-Produkte verwenden soweit ich das gesehen habe, wenn möglich immer die zyklischen Dienste, weil es weniger Netzlast verursacht.


----------



## rostiger Nagel (16 April 2017)

Ganz ehrlich, sollte sich doch ein Anwender keine Gedanken darüber machen müssen,
ob im Familiären System Daten Konstint ankommen, das ist doch eigentlich eine Fehlkonstruktion
des Systems. Gerade wenn es neu entwickelt wurde und der Hersteller Jahrzehnte Erfahrung damit hat,
dürfte das Ergebnis anders aussehen.


----------



## Thomas_v2.1 (16 April 2017)

Das Verhalten der S7-300 war da natürlich am komfortabelsten. Da musste man sich keine großartigen Gedanken dazu machen, da immer eindeutig ist wie und wann die Kommunikation abläuft.
Bei der S7-400 war das Verhalten auch schon so wie bei der 1200/1500, da musste man an einigen Stellen auch schon ein paar Klimmzüge machen um alle Fälle abzudecken.

Solange du hier die Strings (bzw. das Problem dürfte auch bei anderen Datentypen >4 Byte wie DT(L) auftreten) einem Benutzer nur zur Anzeige bringst, dann sieht er einmal kurz einen falschen Text, und 2-3 Sekunden später wieder den richtigen. Wenn der Kunde das so hinnimmt Ok, wenn er das korrigiert haben will, dann muss du dem Kunden wohl oder übel sagen: das geht bei der 1500 nicht anders, zumindest nicht in den neuen tollen "optimierten" DBs. Siemens nennt solche Fehler dann einfach "Systemverhalten".

Das mit dem Stringhandling wird in der SPS ja nicht gerade weniger.


----------



## Blockmove (17 April 2017)

Thomas_v2.1 schrieb:


> Solange du hier die Strings (bzw. das Problem dürfte auch bei anderen Datentypen >4 Byte wie DT(L) auftreten) einem Benutzer nur zur Anzeige bringst, dann sieht er einmal kurz einen falschen Text, und 2-3 Sekunden später wieder den richtigen. Wenn der Kunde das so hinnimmt Ok, wenn er das korrigiert haben will, dann muss du dem Kunden wohl oder übel sagen: das geht bei der 1500 nicht anders, zumindest nicht in den neuen tollen "optimierten" DBs. Siemens nennt solche Fehler dann einfach "Systemverhalten".



Hast du es schon mal mit nicht optimierten DBs und UBLKMOV probiert.
Beu UBLKMOV wird zwar nicht durch das PLC-Programm unterbrochen, aber ob die Speicherbereiche während der Ausführung wirklich konistent bleiben ...

Gruß
Blockmove


----------



## Thomas_v2.1 (17 April 2017)

Wie ich gerade feststelle, lassen sich mittels UMOVE_BLK auch in "nicht-optimierten" DBs keine Strings verschieben.

Vielleicht bin ich aber auch einfach zu blöde für die TIA-Logik. Laut Beschreibung besitzen die Parameter von UMOVE_BLK überhaupt keinen Datentyp. Wenn ich den Baustein in mein Programm ziehe, dann wird dort "byte" angezeigt. Ich kann damit aber trotzdem ein Array-Element (und nur Arrays) vom Type DATE oder weitere die beschrieben sind kopieren. Aber kein Arrayelement vom Datentyp String.
Das würde ich gerne mal von dem Siemens-Verantwortlichen logisch beschrieben bekommen, warum das alles so ist wie es ist.


----------



## christoph2630 (17 April 2017)

In meinen Programmen habe ich bei wichtigen Kommunikationsdaten dann noch zusätzlich eine DINT-Checksumme über alle Bytes gebildet - sowohl in SPS als auch im HMI (script). Erst wenn die Checksummen von SPS und HMI gleich sind, werden die Daten akzeptiert und in den Arbeitsbereich übernommen. Wobei man ehrlicherweise sagen muss, dass das einfache Addieren von Bytes auch noch keine 100%-ig sichere Überwachung ist - aber das könnte man mit komplexeren Algoritmen evtl. noch verbessern....


----------



## Thomas_v2.1 (17 April 2017)

christoph2630 schrieb:


> In meinen Programmen habe ich bei wichtigen Kommunikationsdaten dann noch zusätzlich eine DINT-Checksumme über alle Bytes gebildet - sowohl in SPS als auch im HMI (script). Erst wenn die Checksummen von SPS und HMI gleich sind, werden die Daten akzeptiert und in den Arbeitsbereich übernommen. Wobei man ehrlicherweise sagen muss, dass das einfache Addieren von Bytes auch noch keine 100%-ig sichere Überwachung ist - aber das könnte man mit komplexeren Algoritmen evtl. noch verbessern....



Ja, aber das kann es eigentlich nicht sein. Wie beschrieben, wenn beispielsweise eine Fremdfirma Strings aus deiner SPS auslesen will. Die werden mit den Augen rollen, wenn du denen sagst du hast da hinten am String noch eine Prüfsumme die sie bilden müssen, und dass es öfters vorkommt dass diese nicht passt.

Dann sind wir wirklich beim TIA-Sprichwort: Automatisieren sie in 5 Minuten was früher nur 1 Minute gedauert hat.


----------



## poitouesel (7 Mai 2018)

Hallo,

google hat mich zu diesem Thread gebracht, ich knoble auch gerade an solchen Problemen auf einer S7-1500. Was mir eingefallen ist: die Siemens Kommunkationstask hat immer Prio 15. Wenn ich das Beschreiben der von der Kommunikationstask gelesenen Bereiche in einem zyklischen Interrupt mit höherer Prio (z. B. 17) mache, sieht die Kommunikationstask immer konsistente Daten (geeignete Synchronisationsmaßnahmen zwischen zyklischem Interrupt und dem übrigen Anwendungscode auf der SPS voraussgesetzt). Allerdings könnte es sein, dass ein Übertragungsvorgang durch den zyklischen Interrupt unterbrochen wird und sich so doch wieder Inkonsistenzen ergeben. 

Weiter gedacht: Wenn man grundsätzlich allen Anwendungscode in einem zyklischen Interrupt mit höherer Prio als 15 ausführt, so erreicht man, dass Kommunikationstask und Anwendungscode nur blockweise abwechselnd auf die Daten zugreifen können und alles meistens konsistent ist (auch hier kann ein begonnener Kommunkationsvorgang durch den zyklischen Interrupt unterbrochen werden). Dieser Ansatz würde aber zu zusätzlichen Latenzen bei Kommunikationsvorgängen führen.

Gruß
pe


----------



## Onkel Dagobert (18 November 2018)

*Anlage mit einer S7-1512SP und einem KP700*

Ich habe aktuell eine kleine Anlage mit einer S7-1512SP-1 PN und einem KTP700 Basic PN. Die minimale Zykluszeit habe ich auf 10ms eingestellt. Das ist bei mir inzwischen Standard, egal bei welcher S7. Es treten sporadisch die bekannten Probleme auf, wie das hängenbleiben einer Schaltfläche, oder eben auch Hinweise auf eine Dateninkonsistenz der HMI-Daten. Ähnliche Phänomene hatte ich in der Vergangenheit auch in Kombination ET200S-CPU und KTP600. Dort half es, die Zykluszeit minimal zu erhöhen, bzw. den OB1 mit dem OB35 zu synchronisieren.

Zu dem vielfach angesprochenen Zyklus-Kontrollpunkt.
Wenn es diesen gibt/gäbe, dann ist lediglich gewährleistet dass die HMI-Daten über den SPS-OB1-Zyklus konsistent sind. Es ist aber nicht gewährleistet, dass der HMI-Datensatz vom HMI konsistent in die SPS übertragen wurde, auch nicht bei der S7-300. Die SPS, die ja nun mal definitiv nur begrenzt Zeit hat, ihren Zyklus abzuarbeiten, kann ja nicht darauf warten bis das HMI mit der Datenübertragung fertig ist. Sehe ich das soweit richtig? Somit ist es vermutlich unmöglich, eine wirklich sichere HMI-Datenkonsistenz zu schaffen.



Thomas_v2.1 schrieb:


> ... An einer realen Anlage mit einem großen Programm ist die Wahrscheinlichkeit gering, dass daraus Probleme entstehen. Aber da ist das Problem definitiv.


@Thomas, ich nehme an, man kann aus deiner Aussage "großes Programm" = "größere Zykluszeit" ableiten? Das würde sich mit meinen Erfahrungen decken.

Zu dem KTP700.
Die Architektur eines solchen Basic-Panels ist komplett anders als bei einem Comfort-Panel oder bei einer RunTime. Ich vermute, dass so ein sch..önes Basic-Panel bezüglich der Kommunikation auch wesentlich lahmer ist.

Daraus leite ich ab, dass die Kombination "schneller SPS-Zyklus" und "lahme HMI-Kommunikation" das Problem verschärft?

Unter dem Gesichtspunkt, dass ich bisher alles richtig interpretiert habe, fasse ich für die S7-1?00 noch mal zusammen:


es gibt keinen Zyklus-Kontrollpunkt
es gibt keine Gewähr auf konsistente HMI-Daten
kleine OB1-Zykluszeiten verschärfen das Problem
leistungsschwache Panels verschärfen das Problem

So gesehen, könnte man die Mindest-Zykluszeit noch weiter vergrößern, oder den selbst kreierten Zyklus-Kontrollpunkt in einen Weckalarm auslagern. Letzteres teste ich demnächst, wenn ich wieder an der Anlage bin.


----------



## Blockmove (19 November 2018)

@Onkel
Was mich etwas stutzig macht, ist dass du auch Probleme mit einer ET200S-CPU hast.
Meines Wissens hat die ET200S einen Zykluskontrollpunkt.


----------



## wave (19 November 2018)

Ich kann nix fachliches zu Eurer Diskussion beitragen bin aber sehr irritiert das so was Grundlegendes wie Datentransfer von einem grossen Hersteller nicht 100% konsistent ausgelegt wird.
Ist das bei der Konkurrenz auch so problematisch?


----------



## Onkel Dagobert (19 November 2018)

Blockmove schrieb:


> @Onkel
> Was mich etwas stutzig macht, ist dass du auch Probleme mit einer ET200S-CPU hast.
> Meines Wissens hat die ET200S einen Zykluskontrollpunkt.



Hallo Dieter, der Zykluskontrollpunkt ist das eine, konsistente HMI-Daten das andere. Ich hatte das, so wie ich es verstanden habe, im zweiten Absatz in #56 erläutert. Ich hoffe, ich verbreite keine Unwahrheiten. Aber wenn man sich mal den ganzen Beitrag reinzieht, und nicht nur das liest was man gerne lesen möchte, dann geht auch daraus hervor dass ein Zykluskontrollpunkt alleine nicht ausreicht, zuminmdest nicht in jedem Fall.

@wave,
ich denke schon dass dieses Problem generell auch andere HMI-Systeme betrifft, welche mit Echtzeitsystemen kommunizieren.


----------



## Blockmove (19 November 2018)

Onkel Dagobert schrieb:


> Hallo Dieter, der Zykluskontrollpunkt ist das eine, konsistente HMI-Daten das andere. Ich hatte das, so wie ich es verstanden habe, im zweiten Absatz in #56 erläutert. Ich hoffe, ich verbreite keine Unwahrheiten. Aber wenn man sich mal den ganzen Beitrag reinzieht, und nicht nur das liest was man gerne lesen möchte, dann geht auch daraus hervor dass ein Zykluskontrollpunkt alleine nicht ausreicht, zuminmdest nicht in jedem Fall.



Es gibt wesentliche Unterschiede bei konsistenten Daten zwischen S7-300, S7-400 und S7-1500.
Bei S7-300 hast du den Zykluskontrollpunkt. Die Daten werden also nur einmal zu Beginn des Zyklus übertragen.
Innerhalb des Zyklus können keine Inkonsistenzen aufgrund der Übertragung auftreten.

Bei S7-400 und S7-1500 hast du keinen Zykluskontrollpunkt.
Das Panel liest und schreibt asynchron zum Zyklus. Somit hast du mögliche Inkonistenzen während der Abarbeitung.
Häufiges Symptom sind z.B. hängende Schaltflächen oder falsche Ausgabe von Werten.

Bei der S7-1500 kommt das Thema Call-By-Value und Call-by-Reference bei In-Out-Parametern hinzu.
In Verbindung mit dem fehlenden Zykluskontrollpunkt ist das besonders ekelhaft.

Andere Inkonsistenzen resultieren aus dem Übertragungsprotokoll / Feldbus sowie dem  Mengengerüst.
Also Dinge wie maximale Anzahl der konsistent übertragenen Variablen oder Rezepturdaten.

Das Hochsetzten der Zykluszeit verringert das Risiko, löst aber nicht das Grundproblem.

Gruß
Blockmove


----------



## Thomas_v2.1 (19 November 2018)

Onkel Dagobert schrieb:


> Daraus leite ich ab, dass die Kombination "schneller SPS-Zyklus" und "lahme HMI-Kommunikation" das Problem verschärft?


Das sollte keinen Unterschied machen. Ein einzelner Befehl wie das Setzen eines Bits oder das Ändern eines Sollwertes wird immer als ein einzelnes Telegramm an die SPS geschickt. Wenn die SPS das Telegramm komplett vorliegen hat dann wird es verarbeitet.

Hast du bei der ET200 CPU evtl. die priorisierte HMI Kommunikation aktiviert? Dann verhält sich diese wie eine S7-400 oder 1200/1500. Ansonsten habe ich bei den 300ern noch nie irgendwelche Probleme gehabt.

Was mir noch einfällt was ich noch nie getestet habe ist, ob bei der 300er auch wenn große Arrays (z.B. 200 Bytes von einem langen String) geschrieben werden, diese komplett konsistent im Zykluskontrollpunkt eingebunden werden. Eine Standard-Stringlänge von 254 bekommt man bei der 300er nie konsistent in die SPS geschrieben, weil diese Anzahl nicht in eine PDU passt. Darum ist pauschal die Standard-Stringlänge zu verwenden nicht unbedingt eine gute Idee. Gerade bei der immer weiter verbreitenden MES-Kommunikation bei der diverse Strings an PCs mit Datenbanken ausgetauscht werden, muss man diese Fälle sehr genau betrachten.


----------

