TIA HLK-Programm bei 1500 komplett im 100ms Task? Pro, Contra

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo,
ich muss seit langem mal wieder ein paar HLK-Anlagen programmieren, diesmal mit der 1500. Ich habe bestehende Bausteine für die 300 die ich prinzipiell größtenteils übernehmen werde.
Da es bei solchen Anlagen relativ viele Regler im Programm gibt, habe ich es damals so programmiert, dass ich meine Regler im OB1-Zyklus nur mit einer 1 oder 2 Hz Taktflanke aufgerufen habe. Das funktioniert prinzipiell zwar, ist aber beim Beobachten eines Reglers im Online-Status etwas hakelig.

Jetzt überlege ich mir, ob ich beim Neuschreiben der Bausteine diese nicht so auslege, dass sie den Aufrufzyklus als Parameter mitgeteilt bekommen, und ich dann das komplette Programm in 100ms Interrupt aufrufe.
Da gerade im HLK-Bereich vieles Bausteine mit den entsprechenden Reglern modular zusammengeschaltet werden, macht das die Programmierung relativ einfach.

Im HLK-Bereich sind 100ms Zyklus allemal ausreichend. Ich sehe zur Zeit nur Pros für diese Programmierung.
Contra: es sieht für einen anderen Programmierer auf den ersten Blick evtl. etwas ungewohnt aus wenn der OB1 mehr oder weniger leer ist. Sonst fällt mir nichts ein was dagegen sprechen könnte.

Da aber jeder so seine Ansichten hat: Spricht etwas grundlegendes dagegen es so zu tun?


BTW:
Was mir beim Schreiben gerade noch einfällt: Kann ein Zeitinterrupt-OB eigentlich durch HMI-Kommunikation unterbrochen werden? Wenn nicht, dann hätte es auch noch den Vorteil sich um das Problem mit der Unterbrechung durch HMI-Kommunikation nicht mehr kümmern zu müssen.

 

[Onkel Dagobert]

Hallo Thomas,

in meinem aktuellen (und ersten) 1513-er HLK-Projekt rufe ich 200 PID-Regler (200, weil systematisch) im 500us Weckalarm auf, und das über einen Aufrufverteiler, also pro Aufruf nur einen Regler. Das ergibt eine Abtastrate von 1s pro Regler. Die HMI-Kopplung läuft im OB1 mit einer eingestellten Mindestzykluszeit von 10ms. Das gesamte Feeling ist gefühlsmäßig ;-) wie bei einer 315-er.

Wenn ich deine Zeilen richtig verstehe, wäre für dich eventuell auch ein Synchronisation des OB1 mit einem Weckalarm interessant. Du setzt z.Bsp. im OB30 einen Merker. Diesen fragst du am Ende des OB1 in einer Schleife ab. Erst wenn der Merker gesetzt ist, beendest du die Schleife und setzt den Merker zurück. Das habe ich mal in einer HLK-Bib von Siemens gesehen.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hi Onklel,

das Aufteilen von Programm- und Regler-Zyklus finde ich aber immer etwas aufwändig zu programmieren. Da hast du immer eine Menge Schnittstellen zu beschalten, das mache ich bei meinen sonstigen Automatisierungsaufgaben auch immer so.
Bei der Programmierung mit CFC wie bei PCS7 läuft auch das gesamte Programm in einem zyklischen OB. Bei HLK ist 100ms ja auch kein Problem, selbst 500ms wären drin, solange du nicht irgendwelche Klappen über einen 2-Punkt-Stellungsregler positionieren musst.

Auf 200 Regler komme ich zwar nicht, wahrscheinlich irgendwas um die 50. Ich habe noch kein Gefühl wie schnell die 1500er sind (den genauen Typen der zum Einsatz kommt habe ich auch noch nicht). Ich werde aber das einfache Äquivalent des FB41 CONT_C aus der 300er Lib verwenden und nicht die neuen aufgeblasenen Reglerbausteine.

Meinst du deine 200 Regler bekommst du nicht mit dem restlichen Programm in 100ms abgearbeitet? Zur Not verschiebt man alles in einen 200ms Zyklus.

 

[ducati]

Was mir beim Schreiben gerade noch einfällt: Kann ein Zeitinterrupt-OB eigentlich durch HMI-Kommunikation unterbrochen werden? Wenn nicht, dann hätte es auch noch den Vorteil sich um das Problem mit der Unterbrechung durch HMI-Kommunikation nicht mehr kümmern zu müssen.

Die HMI-Kommunikation unterbricht das SPS-Programm eigentlich nie...

Bei der 300er (Standarteinstellung) wird im Zykluskontrollpunkt kommuniziert.

Bei der 400er, 1500er und 300er (mit Einstellung Priorisierte Bedien Beobachten Kommunikation) wird parallel zum OB1 bzw. parallel zum Weckalarm kommuniziert.


Ansonsten spricht nichts dagegen, sein komplettes Programm in den OB35 zu legen. Wie Thomas schon sagt, PCS7 macht das komplett so. Ich hab früher auch schon zeitkritische Programmteile in nen schnellen Weckalarm gelegt und zeitunkritische in nen langsamen... das funktioniert schon.

Gruß.

 

[maxder2te]

Jetzt überlege ich mir, ob ich beim Neuschreiben der Bausteine diese nicht so auslege, dass sie den Aufrufzyklus als Parameter mitgeteilt bekommen, und ich dann das komplette Programm in 100ms Interrupt aufrufe.
Da gerade im HLK-Bereich vieles Bausteine mit den entsprechenden Reglern modular zusammengeschaltet werden, macht das die Programmierung relativ einfach.

Soweit mir bekannt ist, ist das bei den den IEC-Steuerungen eher die StandardVorgangsweise.
Bei B&R gibt es sowas wie einen Freilaufenden Task eigentlich nur über einen Umweg (mit Zwang zur Mindestzykluszeit).

Im HLK-Bereich sind 100ms Zyklus allemal ausreichend. Ich sehe zur Zeit nur Pros für diese Programmierung.
Contra: es sieht für einen anderen Programmierer auf den ersten Blick evtl. etwas ungewohnt aus wenn der OB1 mehr oder weniger leer ist. Sonst fällt mir nichts ein was dagegen sprechen könnte.

Da aber jeder so seine Ansichten hat: Spricht etwas grundlegendes dagegen es so zu tun?

Ich persönlich bin der Meinung, dass man sich als S7-Programmierer daran gewöhnen muss, dass nicht alles im OB1 aufgerufen wird sondern dass man Multitasking nutzt.

Ich habe noch kein Gefühl wie schnell die 1500er sind (den genauen Typen der zum Einsatz kommt habe ich auch noch nicht).

Sofern du an deiner Programmierweise nichts änderst, gilt die grobe Faustregel: S7-31x = S7-151(x-1) oder S7-151(x-2).
Zwischen 1516 und 1517 ist der Performance Sprung recht groß (ca. Faktor 5, da hier ein gröberer Unterschied der Hardware-Architektur besteht).
Wir haben Messungen am Tisch, dass ein Programm, welches weitgehend 1:1 (nicht optimiert) von einer 317F (V3) auf eine 1516F (V2.1) portiert wurde, auf dieser ca. 5-10% schneller läuft. Mit optimierten Bausteinen holt man noch ein bisschen was raus.

Ich werde aber das einfache Äquivalent des FB41 CONT_C aus der 300er Lib verwenden und nicht die neuen aufgeblasenen Reglerbausteine.

Der tut gut Dienst.

 

[Thomas_v2.1]

Zuviel Werbung?
-> Hier kostenlos registrieren

Die HMI-Kommunikation unterbricht das SPS-Programm eigentlich nie...

Bei der 300er (Standarteinstellung) wird im Zykluskontrollpunkt kommuniziert.

Bei der 400er, 1500er und 300er (mit Einstellung Priorisierte Bedien Beobachten Kommunikation) wird parallel zum OB1 bzw. parallel zum Weckalarm kommuniziert.

Ob das Programm unterbrochen wird oder von einem anderen Prozessor (Kern) o.Ä. auf den Speicher parallel zugegriffen wird, siehst du als Programmierer nicht. Bezüglich Datenkonsistenz ist beides gleich problematisch.
Es könnte ja auch sein, dass ein Weckalarm eine höhere Priorität besitzt, und dann von der HMI-Kommunikation nicht unterbrochen werden kann (wie UBLKMOVE).
Hast du das schonmal getestet ob das im Weckalarm immer noch passiert, oder lässt sich das irgendwo nachlesen?

 

[RONIN]

... 1500er ... wird parallel zum OB1 bzw. parallel zum Weckalarm kommuniziert.

Ich glaub das auch nicht ganz.

Der Weckalarm (OB30) denn man in TIA einfügt hat Priorität 13. Die HMI unterbricht bis Klasse 15.
Kann man auch testen dass die HMI bei Klasse 13 Zwischenergebnisse aus dem OB30 anzeigen kann.
Stellt man auf 16 um bekommt man keine Zwischenergebnisse mehr.

Abhängig der Priorität bekommt die HMI als einmal Werte innerhalb des OBs und einmal nur außerhalb des OBs.
Für mich sieht das nicht nach paralleler Abarbeitung (Lesen/Schreiben während das Programm arbeitet) sondern nach Unterbrechung der Abarbeitung aus um zu kommunizieren. Oder irre ich hier?

Die Zeit läuft schon außerhalb weiter, der Aufruf des OB passiert immer nach 100ms, aber je weiter unten die Anweisung im OB steht, desto mehr könnte Sie von einer (mal längeren/ mal kürzeren) HMI-Unterbrechung zuvor nach hinten geschoben werden. Glaube ich.

 

[ducati]

Hmm, gute Frage... wir hatte da mal einiges ausprobiert, aber so richtig eindeutig sind die Ergebnisse auch nicht.

Ich vermute, der eigentliche "Kommunikationstreiber" läuft schon parallel. Aber evtl. wird zum holen der Daten aus dem DB der OB "kurz" unterbrochen.

Bei ner 300er konnten wir mit aktiver "priorisierter BUB" Haken bis zu 10 mal schneller kommunizieren... Aber die Zykluszeit stieg auf jeden Fall nicht in der gleichen Größenordnung an.

Ich denke, das ganze ist ziemlich komplex und von vielen Faktoren abhängig...

Teilweise läuft ne Kommunikation ja auch über mehrere OB1-Zyklen, das muss dann ja parallel erfolgen, oder auch in Teilen abwechselnd, aber das wär ja noch abstruser

Die TIA-Hilfe schreibt folgendes, aber auch nicht so ganz eindeutig:

Definition


Die Größe des Datenbereichs, der nicht gleichzeitig durch konkurrierende Prozesse verändert werden kann, wird als konsistenter Datenbereich bezeichnet. Ein Datenbereich, der größer als der konsistente Datenbereich ist, kann somit in seiner Gesamtheit verfälscht werden.


Das heißt, ein in sich zusammengehöriger Datenbereich, der größer als der konsistente Datenbereich ist, kann zu einem Zeitpunkt teilweise aus neuen und aus alten konsistenten Datenblöcken bestehen.


Beispiel


Eine Inkonsistenz kann entstehen, wenn ein Kommunikations-Baustein z. B. durch einen Prozessalarm-OB mit höherer Priorität unterbrochen wird. Verändert das Anwenderprogramm in diesem OB jetzt die Daten, die teilweise bereits vom Kommunikations-Baustein verarbeitet wurden, stammen die übertragenen Daten:


zum einen Teil aus der Zeit vor der Prozessalarm-Bearbeitung


und zum anderen Teil aus der Zeit nach der Prozessalarm-Bearbeitung.


Das bedeutet, dass diese Daten inkonsistent (nicht zusammengehörig) sind.


Auswirkung


Wenn große Datenmengen konsistent übertragen werden sollen, dann darf die Übertragung nicht unterbrochen werden. Dadurch kann z. B. die Alarmreaktionszeit der CPU verlängert werden.


D. h.: Je größer die Menge der garantiert konsistent zu übertragenen Daten, desto länger die Alarmreaktionszeit eines Systems.


Datenkonsistenz bei SIMATIC


Existiert im Anwenderprogramm eine Kommunikationsfunktion, welche auf gemeinsame Daten zugreift, kann der Zugriff auf diesen Datenbereich z. B. über den Parameter DONE selbst koordiniert werden. Die Datenkonsistenz der Kommunikationsbereiche, die lokal mit einem Kommunikationsbaustein übertragen wird, kann deshalb im Anwenderprogramm sichergestellt werden.


Bei S7-Kommunikationsanweisungen "PUT" / "GET" muss bereits bei der Programmierung bzw. Projektierung die Größe der konsistenten Datenbereiche berücksichtigt werden, da im Anwenderprogramm des Zielgerätes (Server) kein Kommunikationsbaustein vorhanden ist, der die Kommunikationsdaten in das Anwenderprogramm einsynchronisiert:


Bei der S7-300 und C7-300 (Ausnahme: CPU 318-2 DP) werden die Kommunikationsdaten in Blöcken zu 32 Bytes im Zykluskontrollpunkt des Betriebssystems, konsistent in den Anwenderspeicher kopiert. Für alle größeren Datenbereiche wird keine Datenkonsistenz garantiert. Ist eine definierte
Datenkonsistenz gefordert, so dürfen die Kommunikationsdaten im Anwenderprogramm nicht größer als 32 Bytes sein (je nach Ausgabestand maximal 8 Byte).


Bei der S7-400 uns S7-1500 werden im Gegensatz dazu die Kommunikationsdaten in Blöcken zu 462 Bytes nicht im Zykluskontrollpunkt, sondern in festen Zeitscheiben während des Programmzyklusses bearbeitet. Systemseitig wird die Konsistenz einer Variable garantiert. Auf diese Kommunikationsbereiche kann dann, z. B. von einem OP oder von einer OS, mit den "PUT" / "GET"-Anweisungen bzw. Lesen/Schreiben von Variablen konsistent zugegriffen werden.

...

Gruß.

 

[RONIN]

Zuviel Werbung?
-> Hier kostenlos registrieren

Ich vermute, der eigentliche "Kommunikationstreiber" läuft schon parallel. Aber evtl. wird zum holen der Daten aus dem DB der OB "kurz" unterbrochen.

Ja, genau so hätte ich es mir auch gedacht. Heißt schon dass die Kommunikation die Aufrufzeit-Schwankung von Reglern beeinflusst. Ist aber vernachlässigbar.

@Thomas: Bei Standard-Regelprozessen mit dem FB41-CONT_C kann man die Regler sogar problemlos im OB1-Standard-Zyklus laufen lassen.
Die Zeit einfach messen und dann variabel übergeben. Wenn er einmal mit 101ms und einmal mit 131ms aufgerufen wird und man das am CYLCE übergibt entsteht kein nennenswerter Fehler.

 

[ducati]

Der Weckalarm (OB30) denn man in TIA einfügt hat Priorität 13. Die HMI unterbricht bis Klasse 15.
Kann man auch testen dass die HMI bei Klasse 13 Zwischenergebnisse aus dem OB30 anzeigen kann.
Stellt man auf 16 um bekommt man keine Zwischenergebnisse mehr.

Abhängig der Priorität bekommt die HMI als einmal Werte innerhalb des OBs und einmal nur außerhalb des OBs.

Wenn jetzt die (HMI-) Kommunikation durch den Weckalarm unterbrochen wird, ist das m.M. nach genauso problematisch wie andersrum

Aber wie auch in der Hilfe steht, selbst bei ner 300er mit "Kommunikation" im Zykluskontrollpunkt war auch nicht immer alles per see konsistent.

Ich hatte mal nen Fall mit GET-Kommunikation einer 300er mit nem REAL-Wert auf Adresse 30! Die Probleme damit hatte ich auch auf Inkosistenz zurückgeführt, aber beiweisen konnte ichs auch nicht

Gruß.