TIA Zykluskontrollpunkt S7-1200 und S7-1500 mit HMI

[hubert]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo Miteinander,

wie sieht das bei der S7-1200 und S7-1500 mit dem Zykluskontrollpunkt zur HMI aus? Was ich genau meine, wenn komuniziert das HMI mit der SPS. Also wann werden die Daten vom HMI gelesen bzw. vom HMI wieder die die Steuerung geschrieben. Gibt es hier einen Zeitpunkt wo dies passiert oder schreibt das Panel permanet in die Steuerung?
Wir haben momentan bei der S7-1200 und einem KP300 das Problemm, dass wir bestimmte Sollwert mehrfach eingeben müssen, damit sie in der CPU übernommen werden. Schreiben wir allerdings die Wert über die Beobachtungstabelle rein, so werden diese sofort übernommen.

 

[Thomas_v2.1]

Ich weiß zwar auch nicht wann bei den genannten Steuerungen die Kommunikationsdaten eingebunden werden. Aber die Problematik wenn die Steuerung die Daten auch im Zyklus verarbeitet, ergibt sich nur wenn das SPS Programm auf die Daten lesend UND schreibend zugreift. Wenn das SPS Programm die Daten nur liest, ist es prinzipiell erstmal irrelevant wann die Kommunikationsdaten eingebunden werden. Zumindest wenn nur Werte von elementaren Datentypen (bool, int, dint, real, etc.) und keine Strukturen mit unbedingt zusammengehörigen Datensätzen geschrieben werden.

Ich würde darum erstmal prüfen, ob die problematischen Sollwerte vom Programm aus auch geschrieben werden. Eine Übergabe des Sollwertes als InOut Bausteinparameter wäre ebenfalls ein schreibender Zugriff zu bewerten.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Es kann auch Probleme geben, wenn man die HMI-Werte mehrmals im Programm liest. Dann ist es sehr wohl interessant, wann die Werte ins Programm übernommen werden. Zur Sicherheit kann man sich einen eigenen definierten "Zykluskontrollpunkt" schaffen, indem man die HMI-Variablen auf PLC-Variablen kopiert und nur mit den PLC-Variablen weiter arbeitet.

Harald

 

[Thomas_v2.1]

Hat dann aber nichts mit dem Problem von Hubert zu tun, dass zu schreibende Werte nicht immer von der Steuerung übernommen werden. Wenn im SPS Programm nur gelesen wird (auch mehrmals) sollten die Werte auf jeden Fall immer im Programm landen und nicht überschrieben werden.

 

[hubert]

Danke

@Thomas_v2.1
Ja in dem Programm kommt es vor, dass wir bestimmte Eingabewert vom HMI als INOUT Variablem angelebt haben. Der Hintergrund ist aber meistens, dass hier bestimmte Werte in Berechnungen mit einfließen und bei Falscheingabe korrigiert werden. Die korrektur geschieht aber nicht laufend, sonder nur im Fehlerfall.

@PN/DP
Wie würdest du so einen Zykluskontrollpunkt definieren, wenn du bestimmte Eingabewerte am HMI auch durch die SPS evtl. verändern musst bzw sie begrenzen würdest?

 

[rr_zx]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,

Wir hatten auch solche Probleme.
Bis heute ist der Fall aber bei Siemens nicht gelöst. (scho 8Monate offen)
Setzt doch mal in der Hardwarekonfig die minimale Zykluszeit der SPS auf 10ms. Danach hatten wir fast keine Probleme mehr.

Viele Grüsse
Ralph

Sent from my RM-892_eu_euro2_307 using Tapatalk

 

[Thomas_v2.1]

Das "Problem" gab es bei den S7-400er Steuerungen schon immer, bzw. man muss darauf achten dass Kommunikationsdaten entsprechend behandelt werden.

Bei einem InOut-Parameter ist es auch nicht relevant ob der Wert im Baustein beschrieben wird oder nicht. Denn er wird zumindest bei den 300/400er Steuerungen immer außerhalb überschrieben, auch wenn er intern nicht verwendet wird (nur bei elementaren Datentypen). Und da der Effekt auch bei der 1500er auftritt, scheint diese mit InOut-Parametern in ähnlicher Weise vorzugehen. Der Effekt tritt umso häufiger zu Tage, je mehr Zeit in dem Baustein im Verhältnis zum restlichen Programm verbracht wird, weil dann eben die Wahrscheinlichkeit größer wird, dass die Kommunikationsdaten eingebunden werden wenn der Baustein gerade bearbeitet wird.

Bei der 400er besteht Verbesserungsmöglichkeit darin, den Parameter in eine Struktur zu packen damit diese dem Baustein als Zeiger und nicht als Kopie übergeben wird. Das Problem bleibt aber weiterhin bestehen, nur wird die Wahrscheinlichkeit geringer wenn man die Anzahl der Anweisungen zwischen lesendem und schreibendem Zugriff möglichst gering hält.
Wirklich sauber bekommst du das gerade bei Sollwerten als Integer oder Real nur hin, wenn du Sollwertvorgabe und Sollwertrückmeldung trennst.

 

[rr_zx]

Das ist mir bewusst, dass dadurch nur die Wahrscheindlichkeit gesenkt wird. Wir haben dieses Verhalten im Zusammenhangt mit einer 1200 erlebt.
Wir haben Normbausteine in der Sps wo alle HMI-Variablen über INOUT in einem UDT übergeben werden.
Mit einer 300 Steuerungen hatten wir so nie Probleme, aber bei der 1200 hatten wir dan oft dieses "Problem".
Siemens konnte uns auch nicht das genau Verhalten des Datenaustausches sagen. Aber ich hoffe das wir irgendwan noch eine Antwort erhalten.

Gruss

Sent from my RM-892_eu_euro2_307 using Tapatalk

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Und wie habt ihr das Problem behoben?
Man könnte bei der 300/400er zur Not den ganzen DB per UBLKMOV umkopieren, aber sowas existiert bei der 1200er nicht soweit ich weiß.

Aber wenn nichtmal Siemens weiß wie das intern funktioniert ist das schon traurig.

 

[IBFS]

Es kann auch Probleme geben, wenn man die HMI-Werte mehrmals im Programm liest. Dann ist es sehr wohl interessant, wann die Werte ins Programm übernommen werden. Zur Sicherheit kann man sich einen eigenen definierten "Zykluskontrollpunkt" schaffen, indem man die HMI-Variablen auf PLC-Variablen kopiert und nur mit den PLC-Variablen weiter arbeitet.

Es kann auch Probleme geben ..... ...... in CLASSIC mit S7-300/S7-400 hatte ich nie Probleme mit dem DoppeltEingebenMüssen.

Da musste man sich darüber keinen Kopf machen. Aber jetzt, wo alles besser wird, hat man das dann auch noch am Hals.

Am Ende muss man noch für seine 300 Variablen jeweils ein Auftragsfach einrichten und jeweils Freischalten wer schreiben darf.

So ein Käse!

 

[hubert]

Hallo Miteinander,

da bin ich ja schon beruhigt dass es nicht nur mit so geht. Aber wenn ich schon höre, dass bei "Ralph" die Sache schon 8 Monate bekannt ist und Siemens immer noch keine Lösung hat finde ich das sehr traurig. Es sollte zumindestens Siemens Wissen, wie ihre neue CPU Serien intern arbeitet und wie die Kommunikation zum Bediengerät funktioniert.
Wir haben auch schon wegen der Sache Kontakt mit Siemens aufgenommen, aber so richtig konnten Sie uns auch nicht weiterhelfen.

Wir haben bis jetzt S7-300 und S7-200 im Einsatz gehabt und da hatten wir die Problem mit diesem Phänomen noch nicht. Bei der S7-400 kann ich nicht viel sagen, die ist bei uns sehr sehr selten im Einsatz.
Wir hatten das Problem erst in letzter Zeit mit der S7-1200, da wir nun unsere ganzen Standardanlage auf diese Umstellen müssen. Und hier haben wir halt nun vermehrt das Problem, dass wir die Werte mehrfach eingeben mussten.

Aber mal eine Frage an die Runde. Wir habt ihr das bei der S7-400 immer gebacht, wenn ihr Paramter über das Bediengerät geändert habt und auch diese Werte evtl. durch Überprüfungen in der S7-400 geändert habt? Würde mich einfach nur interessieren.

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

@PN/DP
Wie würdest du so einen Zykluskontrollpunkt definieren, wenn du bestimmte Eingabewerte am HMI auch durch die SPS evtl. verändern musst bzw sie begrenzen würdest?

Ich weiß jetzt nicht, ob das TIA-SCL den Code so frißt, aber ungefähr so würde ich das machen:

FUNCTION Check_HMI_Var_Int : BOOL
VAR_INPUT
    HMI_Var : INT ;                  [COLOR="#008000"]//zu prüfende Variable vom HMI[/COLOR]
    Maxwert : INT ;
    Minwert : INT ;
END_VAR
VAR_OUTPUT
    PLC_Var : INT ;                  [COLOR="#008000"]//Arbeitskopie in der PLC[/COLOR]
    xKorrektur : BOOL ;              [COLOR="#008000"]//True: HMI-Var muß korrigiert werden[/COLOR]
END_VAR
VAR_TEMP
    Tmp_Var : INT ;
END_VAR

    Tmp_Var := HMI_Var ;             [COLOR="#008000"]//HMI_Var vorsichtshalber kopieren, falls Übergabe ByRef[/COLOR]

    xKorrektur := True ;
    IF Tmp_Var > Maxwert THEN        [COLOR="#008000"]//größer Maxwert?[/COLOR]
        Tmp_Var := Maxwert ;         [COLOR="#008000"]//auf Maxwert setzen[/COLOR]
    ELSIF Tmp_Var < Minwert THEN     [COLOR="#008000"]//kleiner Minwert?[/COLOR]
        Tmp_Var := Minwert ;         [COLOR="#008000"]//auf Minwert setzen[/COLOR]
    ELSE
        xKorrektur := False ;
    END_IF;
    
    PLC_Var := Tmp_Var ;             [COLOR="#008000"]//die geprüfte und ggf. korrigierte Arbeitskopie[/COLOR]
    Check_HMI_Var_Int := xKorrektur ;

END_FUNCTION

Aufruf der Function:

[COLOR="#008000"]// Check HMI_Var_1[/COLOR]
    Check_HMI_Var_Int(
             HMI_Var := HMI_Var_1    [COLOR="#008000"]//hier der einzige Lesezugriff auf die HMI_Variable[/COLOR]
            ,Maxwert := 100
            ,Minwert := 0
            ,PLC_Var => PLC_Var_1    [COLOR="#008000"]//die Kopie, mit der das PLC-Programm arbeitet[/COLOR]
         ,xKorrektur => Tmp_BOOL_Var
    );
 
    IF Tmp_BOOL_Var THEN
        HMI_Var_1 := PLC_Var_1 ;     [COLOR="#008000"]//ggf. Korrektur auf HMI_Variable zurückschreiben[/COLOR]
    END_IF;

[COLOR="#008000"]// oder:

// Check HMI_Var_2[/COLOR]
    IF Check_HMI_Var_Int(
             HMI_Var := HMI_Var_2    [COLOR="#008000"]//hier der einzige Lesezugriff auf die HMI_Variable[/COLOR]
            ,Maxwert := 100
            ,Minwert := 0
            ,PLC_Var => PLC_Var_2    [COLOR="#008000"]//die Kopie, mit der das PLC-Programm arbeitet[/COLOR]
         ,xKorrektur => Tmp_BOOL_Var
    ) THEN
        HMI_Var_2 := PLC_Var_2 ;     [COLOR="#008000"]//ggf. Korrektur auf HMI_Variable zurückschreiben[/COLOR]
    END_IF;

Das PLC-Programm arbeitet mit einer Kopie der HMI-Variable, welche nur ein einziges mal gelesen wird.

Das PLC-Programm schreibt nur dann auf die HMI-Variable wenn es zur Korrektur nötig ist - hat dann aber Vorrang vor einer äußerst unwahrscheinlichen Änderung der HMI-Variable während der FC-Abarbeitung (dazu müßte sich die HMI-Variable vor UND während der FC-Bearbeitung ändern, also zweimal).

Das PLC-Programm kann auch gelegentlich Werte auf die HMI-Variable schreiben. Solange das nicht in jedem OB1-Zyklus passiert ist die Chance für eine Kollision mit Schreiben vom HMI äußerst gering. Der Bediener müßte zur selben Zeit einen Eingabewert ändern wenn auch das PLC-Programm meint einen Wert zuweisen zu müssen.

Harald

 

[IBFS]

@PN/DP
Mich stinkt es an, den TIA-Design-Pfusch mittels Codegebastel glatt zu ziehen.
Das führt jedes Migrationgesülze ad Absudum, oder?

btw. Mit S7-400 hatte ich bisher auch keine Problem mit Classic-S7

Also ..... SIEMENS ... in TIA V14 den Fehler beheben .... fertig!

 

[PN/DP]

Den "Designfehler" gibt es "schon immer"; er kommt einfach daher, wenn man entscheidet, daß die Kommunikation für "bessere" Performance jederzeit Variablen beschreiben darf und nicht nur im Zykluskontrollpunkt. Bei S7-300 gab es anfangs sowas nicht und die später eingeführte "priorisierte BuB-Kommunikation" kann man abschalten. Bei S7-318 und S7-400 besteht das Problem schon, jedoch die CPUen welche ich kenne steuern große Anlagen und die Zykluszeiten sind meist entsprechend hoch, so daß das Problem kaum auffällt. Man muß es halt wissen und sein Programm entsprechend aufbauen. Wobei Siemens allerdings eine perfekte Lösung verhindert, weil man in S7 Speicherzugriffe nicht verriegeln kann.

Harald

 

[hubert]

Zuviel Werbung?
-> Hier kostenlos registrieren

@PN/DP

ja das stimmt. Bei der S7-400 und S7-318 ist mir die Sache bekannt. Bei der S7-300 ist es halt noch nie so aufgefallen, wie jetzt bei der S7-1200. Wobei ich das momentan auch so sehen, dass die S7-1200 eher ein Ersatz für die S7-200 ist und nach meiner Ansicht nicht weiklich in die S7-300 rein geht.
Aber dein Ansatz mit dem getrennten HMI und SPS-Bereich ist auf jedenfall gut nur braucht man leider den Doppelt DB's Speicher um das zu machen und der normale Programmspeicher ist auch nicht unerheblich. Ich hoffe das Siemens hier eine performate Lösung hat, dass diese Phänomene nicht mehr so offensichtlich auftreten.

Wobei ich persönlich der Bin, dass die meiste Zeit ein HMI dran hängt und da ist es mir persönlich nicht so wichtig, dass Variablen im 100ms Takt in die SPS geschrieben werden. Wenn ich große SCADA Systeme wie WINCC anschau, da sind an der Visu Reaktionszeit von 2 Sekunden ganz normal.

 

[IBFS]

Wie kann es drehen und wenden, es ist dem Kunden nicht zuzumuten Variablenwerte
doppel oder dreifach eingeben zu müssen. Auch will ich nicht, außer der gewohnten
EINGABE/AUSGABE-HMI-Anbindung, da doch ein Haufen Zusatzaufwand haben.

Die Powerpoints reden allen immer ein, alles wird besser in effizienter ....
da habe ich keine Lust auf - zugegebenermaßen - hübsche Workarounds.

Der Kostendruck führt eher dazu, dass man weniger Zeit für ein Projekt hat.
Wenn dann TIA zäh wie Kaugummi ist und man noch einen Haufen extra
programmieren muss, dann wird man nicht fertig.

 

[hubert]

@IBFS
ja das stimmt. Den Vertrieblern wird in den ganzen Veranstaltungen weiß gemacht alles wir schneller besser und effizienter. Aber genau das Gegenteil ist momentan der Fall.
Wie man mit TIA sieht, wird einem Hardcore Programmierer immer mehr von effizient abgenommen und er wird immer stärker in eine starres Korsett gezwängt.

Aber man kann da leider nicht mehr viel machen. Die Dampfwalze TIA ist am anrollen. Irgendwie müssen wir uns damit anfreunden. Nur sind auch wir momentan gedrungen auf die Entwicklung von Siemens zurück zugreifen, da der Zustand auch für unsere Kunden nicht zumutbar war. Da wir dann gleich gesagt, vorher ist das alles gegangen und nun soll das auf einmal nicht mehr gehen.
Aber bei all dem Tadl an Siemens. Das neue TIA hat auch machmal seine guten Dinge. Es ist nicht alles schlecht ;-).

 

[PN/DP]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich habe wenig Erfahrung mit TIA (und eigentlich fast nur schlechte), doch bei diesem Problem muß ich TIA in Schutz nehmen. Denn das Problem ist kein neues TIA-Problem, das Problem existiert schon mindestens seit es die S7-400 gibt. Und es ist eigentlich kein Problem, sondern eine Standard-Aufgabe der Prozesssynchronisation und Interprozesskommunikation in Multitasking/Multithreading-Umgebungen. Das Problem ist erst deshalb ein auch für den Siemens-Support scheinbar unlösbares Problem, weil Siemens es versäumt hat, die dazu nötigen atomaren Operationen in Step7 vorzusehen, damit man Race Condition-Konstellationen vermeiden kann.

Man kann es nicht TIA anlasten, wenn man durch den Umgang mit S7-300 und deren Zykluskontrollpunkt quasi verwöhnt wurde und sich bisher keine Gedanken um Prozesssynchronisation und Interprozesskommunikation machen mußte.

Ich glaube zwar nicht, daß die SFC41 "DIS_AIRT" und SFC42 "EN_AIRT" zum temporären Verzögern von Interrupts auch die Kommunikationszugriffe sperrt, doch Ihr könntet ja mal auf Eurer S7-1200 ohne alles umzuprogrammieren folgendes ausprobieren:
- die Anweisung DIS_AIRT einfügen (Interrupts verzögern)
- Euren vorhandenen kritischen Code mit der Prüfung und Korrektur von HMI-Variablen
- die Anweisung EN_AIRT einfügen (Interrupts freigeben)
(en bloc oder ggf. vor und hinter jeder Eurer kritischen Stellen anwenden)

Ich meine, die beste Lösung wäre, wenn man wählen/einstellen könnte, ob man Variablen-Zugriffe der Kommunikation nur im Zykluskontrollpunkt oder jederzeit zulassen will. Dann würde ich das wegen der einfacheren Programmierung nur zulassen, wenn ich die höhere Kommunikationsperformance tatsächlich brauche - wüsste dann aber, daß ich die höhere Performance mir erhöhtem Programmieraufwand für die Zugriffs-Synchronisation bezahlen muß.
Aber mich fragt Siemens ja nicht

Harald

 

[PN/DP]

Wir hatten auch solche Probleme.
Bis heute ist der Fall aber bei Siemens nicht gelöst. (scho 8Monate offen)

Siemens konnte uns auch nicht das genau Verhalten des Datenaustausches sagen. Aber ich hoffe das wir irgendwan noch eine Antwort erhalten.

Hallo Ralph,

hast Du von Siemens eine Antwort mit Lösung erhalten?

Harald