S7 Datenkonsistenz bei HMI Kommunikation

[Larry Laffer]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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]

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]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

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.

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

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

 

[wave]

Zuviel Werbung?
-> Hier kostenlos registrieren

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]

@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]

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