Problem mit Heizungsvorlaufregelung

[Homesps]

Hallo,

in Anlehnung an Beispiele hier im Forum habe ich mir eine Temperaturregelung für meinen Heizungsvorlauf gebaut. Geregelt wird eine Belimo-Regelkugelhahn ohne Endschalter.

Jetzt konnte ich bereits zweimal beobachten, dass der Kugelhahn auf zu stand, dh kein Warmwasser wird zugemischt, die POS am ACTUATOR_3P aber auf 255, also auf. Die Regelung kommt so zu einem Stillstand, bis ich (oder die Automatik) einen Diagnoselauf startet.

Nach Lesen des Quellcodes ist mir nicht klar, wie dieser Zustand entsteht und ich weiß auch nicht, wie ich das in der Steuerung nachvollziehen kann.

Wenn ich den ACTUATOR_3P richtig lese, gibt es keine Totzeit zwischen dem Umschalten, obwohl _RMP_NEXT dies mit TL bietet.  Könnte ich dies in ACTUATOR_3P mit

VAR_INPUT CONSTANT
   T_LOCKOUT: TIME := T#100ms;
END_VAR
VAR
   ramp : _RMP_NEXT:=(TL:=T_LOCKOUT);
END_VAR

hinzufügen?

Gruß
Klaus

[gelöscht durch Administrator]

[hugo]

welches system / steuerung version benutzt du?

[Homesps]

Hallo Hugo,

ich benutze eine Wago 750-849.

Gruß
Klaus

[hugo]

welche parameter hast du am ft_piwl anliegen?

[Homesps]

Hallo Hugo,

den FT_PIWL habe ich wie folgt konfiguriert:

KP=1
KI=0.1
LIM_L=0
LIM_H=100

Eben habe ich gesehen, dass der Kugelhahn ungefähr in Stellung 50% stand, POS aber 255 anzeigt. Die Wärmezufuhr reicht nun nicht mehr aus, die Vorlauftemperatur fällt langsam ab und die Steuerung regelt nicht mehr hoch. Mir fiel auf, dass durch den Temperaturabfall sich für kurze Zeit der Ausgang Y am FT_PIWL ändert und dann das Relais für "Hahn zu" schaltet. So "tackert" sich das dann langsam in Richtung Hahn zu und POS=255.
Meine T_CAL stand dabei schon auf T#2h, dh dieser Zustand muss sich recht schnell eingestellt haben.

Mir ist auch aufgefallen, dass die Regelung beim Einregeln viele sehr kurze Schaltimpulse abgibt. Wenn die Temperatur sich recht schnell ändert, auch gerne mal in verschiedene Richtungen kurz hintereinander. Ich vermute, dass dadurch die mechanische Stellung und die simulierte Position auseinanderlaufen.

Gruß
Klaus

[hugo]

kannst du mal einen screenshot mit aktuellen werten an alles ausgänge senden? aus der ojnline darstellung

[Homesps]

Hier ist ein Online-Screenshot, allerdings nicht im "defekten" Zustand, sondern beim Regeln wenn es funktioniert.

[gelöscht durch Administrator]

[hugo]

genau so sollte es sein ... ich benötige einen screen shot wenn es ausser tritt kommt hoffe das geht

versuch bitte auch den baustein (instanz des ft_pidwl) zu öffnen und die variablen zu fotografieren

[Homesps]

Ich hatte die T_CAL mittlerweile auf T#1h Stunde gesetzt, damit das nicht mehr passiert... ist jetzt wieder höher. Mal sehen, wann es wieder diesen Zustand gibt.

Gruß
Klaus

[Homesps]

So, jetzt habe ich ein Bild und konnte das Verhalten auch beobachten.

Situation:
Die Soll-Vorlauftemperatur springt von 25 auf 45°C. Der Hahn geht voll auf und die gemessene Temperatur steigt langsam.

Beobachten konnte ich nun, das Y am FT_PIWL immer mal wieder kurz sinkt. Anschließend geht der Wert sofort wieder hoch.

Ich vermute, durch die steigende Temperatur wird der P-Teil des Reglers kleiner und Y wird < 100. Dies schaltet sofort Out2 am ACTUATOR_3P.
Der I-Teil des Reglers regelt natürlich sofort wieder hoch (TIst immer noch kleiner TSoll) auf 100 und der ACTUATOR_3P schaltet dann auch sofort wieder Out1. Mann sieht, das POS eigentlich immer auf 255 bleibt.

Aber in der mechanischen Welt, hat der erste Impuls an Out2 den Hahn in Richtung Zu in Bewegung gesetzt. Der sofortige Gegenimpuls an Out1 führt dann vermutlich nicht zu einer Bewegung in Richtung Auf sondern wird duch die Trägheit des Hahns "aufgefressen". Dadurch läuft dann die wirkliche Stellung und die simulierte Position auseinander.

Meine erste Idee wäre, über eine Lockout-Zeit im ACTUATOR_3P das sofortige Umschalten zu verhindern und so die simulierte mit der realen Position in Deckung zu bringen.

Gruß
Klaus

[gelöscht durch Administrator]

[gravieren]

Hi

Aber in der mechanischen Welt, hat der erste Impuls an Out2 den Hahn in Richtung Zu in Bewegung gesetzt. Der sofortige Gegenimpuls an Out1 führt dann vermutlich nicht zu einer Bewegung in Richtung Auf sondern wird duch die Trägheit des Hahns "aufgefressen". Dadurch läuft dann die wirkliche Stellung und die simulierte Position auseinander.

In der Tat kann es so sein.

Inder der Praxis stimmt der Simulierte Wert NICHT exakt mit der realen Stellung überein.

Was jedoch nicht weiter schlimm ist.
Der PID-Regler sollte diesen Versatz aus-regeln.


TIP 1:
Wenn die "laufzeit für die volle Bewegung" falsch/knapp angegeben wird, dann kann es passieren, dass der Steller NICHT komplett öffnet/schließt.

Klartext --> T_RUN --> z.b. 90 Sekunden --> Reelle Laufzeit des Stellers --> versuche mal denn Wert auf z.b. 100 Sekunden zu erhöhen.

Hintergrund, bei kalkulierten 90 Sekunden werden sonst keine Öffnungsimpulse mehr ausgegeben.  (Soweit ich weiß)
Hiermit wird möglicherweise die Fehlstellung kompensiert.


TIP 2: Wenn möglich --> Endschalter für Klappenstellung anschliessen.


TIP 3: T_DIAG verkleinern ?  --> Wird hierbei ein Kallibierfahrt angestoßen ? --> Vielleicht können die Kollegen hierzu entwas sagen.

TIP 4: Normalerweise die beste Lösung --> Reelle Stellungsrückmeldung --> Selten Realisiert, in der Praxis teuer.

TIP 5: Steller mit Analogeingang --> z.b. 0-10 Volt  -->  0% bis 100%


Gruß Karl

 

[Homesps]

Hallo,

dieses Problem bereitet mir mittlerweile echte Schwierigkeiten.

T_DIAG ist auf T#30m und trotzdem gibt es immer wieder die Situation, dass POS=255 ist und der Hahn komplett zu (also eigentlich 0).

Hat noch jemand eine Idee, was ich machen kann oder ist die einzige Lösung mir einen Antrieb mit Endlagensignal zu kaufen?
Wie kann ich die Lockoutzeit der ramp im ACTUATOR_3P aktivieren? Vielleicht hilft das.

Wenn die "laufzeit für die volle Bewegung" falsch/knapp angegeben wird, dann kann es passieren, dass der Steller NICHT komplett öffnet/schließt.

Die konfigurierte Laufzeit liegt ziemlich genau 10s über der wirklichen Laufzeit. Bei der Diagnose kann man das sehr schön beobachten.

Gruß
Klaus

[Homesps]

Ich versuche es jetzt mal mit anderen Limits am RANGE_TO_BYTE, low=10 und high=90.

Die Idee ist, dass das "gezappel" von Y am FT_PIWL dann nicht mehr zu diesen schnellen Impulsen des ACTUATOR_3P führt.

Mal sehen, wie das funktioniert.

Gruß
Klaus

[Homesps]

Kurzes Feedback: Es scheint, dass mit den Limits 5 und 95 am RANGE_TO_BYTE das Problem behoben ist. Mittlerweile habe ich T_DIAG auf T#4h hochgesetzt und das Problem tritt nicht auf.

Gruß
Klaus