I-Anteil des PI-Reglers "RLT30_FB_CTRL_PI" hängt sich auf.

Begonnen von rrbd, 05. November 2012, 06:47:35

Vorheriges Thema - Nächstes Thema

0 Mitglieder und 1 Gast betrachten dieses Thema.

rrbd

Hallo,

ich habe festgestellt, dass sich der o.g. Regler bei Betrieb mit Phoenix ILC 150 nach ein paar Stunden zuverlässig aufhängt. Nach dem Kaltstart eines Neuen Programms funktioniert zunächst alles wie erwartet, wenn ich nach ein paar Stunden wieder nachsehe hängt der Regler.

Der Effekt:
- P-Anteil funktioniert weiterhin wie zu erwarten
- I-Anteil hängt fest.

In der beobachteten Situation (Temperaturregler Zuluft, mehrere Grad Regelabweichung, ähnlich wie im Screenshot (dort aber zufällig nur geringe Regelabweichung)) krabbelt sonst der Regler-Ausgang langsam aber stetig in die richtige Richtung zur Korrektur der Abweichung, wenn der Fehler dann auftritt zappelt der Ausgang nur noch etwas hin und her, recht offensichtlich P-Regler-Reaktionen.

RESET des I-Anteils bringt die Angelegenheit meist wieder in Gang, Kaltstart der SPS zuverlässig.

Die Reglerparameter im Screenshot sind beliebige Werte, mit denen ich versucht habe, die Reaktionen zu testen, und nicht die eigentlich für die Anwendung vorgesehenen.

Ich werde parallel mal im SPS-Forum fragen, ob da jemand eine Abhilfe weiß, und mir wohl lieber erst mal selbst einen PI-Regler "bauen".

Grüße

Rainer

[gelöscht durch Administrator]

rrbd

Hallo,
ich habe auch zu diesem Problem (wie bei der ACTUATOR_3p- Frage) ein gepacktes Testprogramm bereit gestellt: http://www.bielefeldundbuss.de/OSCAT/PI_Test_ab.zwe

Das Testprogramm habe ich ein paar Stunden auf einer ICL 130 laufen lassen, sie simuliert die Verhältnisse in einer Heizungs-Temperaturregelung; Regler-Istwert und Regler-Sollwert entsprechen verzehnfachten Temperaturwerten (in der HLK-Technik gebräuchliches Verfahrren), also grob 50°C . Der Sollwert ändert sich allmählich über den unteren Sinusgenerator mit 12 Stunden Periodendauer, und die gemessene Temperatur wird über einen Sinusgenerator mit 10 Minuten Periodendauer und einer Rückkopplung simuliert. Das sah realistisch aus.

Dann habe ich die Eingangs-Situation "eingefroren", indem ich während des Programmlaufes beide Periodendauern (über die Eingangsvariablen) drastisch verlängert habe. Ergebnis: Betrag der Regelabweichung ca 5.0, Actuator_3P schaltet mit 2 Hz (so jedenfalls auf dem Bildschirm sichtbar) zwischen Position 126 und 127 hin und her.

Erwartetes Verhalten:     Das (mittlere)  Ausgangssignal des PI-Reglers sollte sich über den Integralanteil ganz allmählich verringern.
Tatsächliches Verhalten: Ausgangssignal pendelt unendlich zwischen den beiden selben Werten umher.

Ich habe sicherheitshalber KI in verzehnfahcungs-Schritten von 0.00001 bis 10000.0 geändert: kein Effekt. Der Regleraugang pendelt nun bereits seit über einer Stunde zwischen 49.81 und 79.71. Das ist definitiv so nicht brauchbar.

Die Fragen sind:
a) Irgendein Beschaltungsdetail nicht optimal und behindert den I-Regler?
b) Reagiert der Reglerbaustein überhaupt auf Eingangsänderungen zur Laufzeit? KP-Änderungen wirken sichtbar und genau wie erwartet.

Mit diesem Programm habe ich's noch nicht versucht, in einer realen Anlage war es aber so, dass der I-Regler zunächst ganz eindeutig funktionierte, bei Eingefrorenen Eingängen mit Regelabweichung sah man den Ausgang stetig in die richtige Richtung "krabbeln", Versuch zu einem Späteren Zeitpunkt zeigte dann das Bild wie im Testprogramm ohne I-Regelung

Wer kann Licht in's Dunkel bringen?

Grüße


Rainer

[gelöscht durch Administrator]

rrbd

Hallo,

nach ein paar weiteren Stunden ohne Änderung beim Ausgangswert habe ich nun mal den Reglereingang RST kurz auf 0 gesetzt. Mich wundert, dass der Regler Ausgang daraufhin auf 0% gegangen ist, was für mich nach Durchsicht des Handbuchs ("Mit RST kann der interne Integrator jederzeit auf 0 gesetzt werden") bedeutet, dass zu dem Zeitpunkt kein P-Anteil am Ausgang vorhanden war? Der Ausgang stieg dann auf gut 10% und verharrt dort wieder.

Was auch immer das bedeuten mag.

Grüße

Rainer

rrbd

Hallo,
Es könnte sein, dass die Ursache der beobachteten Absonderlichkeiten schlicht mein Fehler war, in das Testprogramm  hier auf meinem PC ist die veraltete  "oscat_basic_330" statt der korrekten  "oscat_basic_333"-Lib. eingebnden, siehe auch hier: http://www.oscat.de/community/index.php/topic,2005.msg10498.html#msg10498. Ich überprüfe in den nächsten Tagen noch mal, ob hier tatsächlich Entwarnung gegeben werden kann.

Grüße

Rainer