Hysterese Möglichkeiten

OKL

Level-1
Beiträge
143
Reaktionspunkte
3
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo Gemeinde,

ich bin in Sachen SPS ja nicht sonderlich erfahren. Möchte gern mein Projekt HOME verbessern. In meiner Unwissenheit habe ich die Hysterese bezüglich Ladepumpe Warmwasser derzeit so gelöst:

REAL-Wert im DB für Obergrenze (Vorgabe)
REAL-WErt im DB für Untergrenze (Vorgabe)
REAL-Wert als tatsächlicher Vergleichswert

Ladepumpe ein: tatsächlicher Vergleichswert = Obergrenze = 58 Grad

Ladepumpe aus (negative Flanke) und Ladetemperatur >=58 Grad - setze tatsächlichen Vergleichswert auf Untergrenze

Das heißt, die Ladepumpe fängt bei 56 Grad wieder an und hört bei 58 auf.

Wie habt ihr derartige Vorhaben gelöst?

Danke euch.


MfG

Olaf
 
Wenn es funktioniert, dann hast Du es erstmal richtig gemacht.

Hier noch ein Beispiel, wie ich das auf die Schnelle lösen würde:

Code:
L #Istwert
L #Obergrenze
>R
R #PumpeEin
L #Istwert
L #Untergrenze
<R
S #PumpeEin
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Ich würde zwingend das ausschalten Dominant machen.

Code:
.
//Einschalten
L #Istwert
L #Untergrenze
<=R
S #PumpeEin

//Plausibilitätskontrolle der grenzen
O(
L #Obergrenze
L #Untergrenze
<=R
)

//Ausschalten
O(
L #Istwert
L #Obergrenze
>=R
)
R #PumpeEin
 
Danke euch. Wenn die Anlage komplett läuft, werde ich derartige Dinge verbessern... Man will ja auch später noch was zu tun haben :)
 
Danke euch. Wenn die Anlage komplett läuft, werde ich derartige Dinge verbessern... Man will ja auch später noch was zu tun haben :)

Du musst dir auch über die Mittelwertbildung deines IST-Wertes nachdenken.
Damit dein System sich nicht aufschaukelt und zu oft ein- und ausschaltet.


bike
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Du musst dir auch über die Mittelwertbildung deines IST-Wertes nachdenken.
Damit dein System sich nicht aufschaukelt und zu oft ein- und ausschaltet.


bike

Kann er, muss er nicht. Deswegen macht er es ja schon mit einer Hysterese. Wenn es totzdem zu oft Ein- und Ausschalten sollte, kann er ja die Hysterese erst mal vergrößern.
 
Kann er, muss er nicht. Deswegen macht er es ja schon mit einer Hysterese. Wenn es totzdem zu oft Ein- und Ausschalten sollte, kann er ja die Hysterese erst mal vergrößern.

Du machst eine Regelung direkt mit einem momentanen Temperaturwert vom Eingang?
Ohne MIttelwertbildung oder ähnlichem?
Wow, das ist großes Kino. :ROFLMAO:

Es ist der Hinweis, dass sowohl eine Hysterese als auch Mittelwertbildung sinnvoll ist, um eine Regelstrecke zu programmieren.


bike
 
Vielleicht kommt es darauf an welche Dynamik das System hat, bei
einer Heizung, wobei es in diese Projekt geht, kann man das wohl
vernachlässigen und ein endspechende langsame Temperaturänderung
bzw. Istwert erwarten. Es sei den der TE hat ein Kochsieder in einen 1l
Gefäß um das Heizungswasser warm zu machen.

Diese Erfahrung beruht auf das beobachten des eigenen Heizkessel ;)
 
A-häm ...
Wir sprechen hier aber nicht von einem PID-Regler, der (je nach Konfiguration so etwas schon implementiert) sondern von einer 2-Punkt-Regelung.
Ich glaube das man von der Schwankung des Eingangssignals abgesehen auch immer mit der Schwankung der Digitalisierung der Eingangsgröße rechnen sollte. Dafür könnte man dann schon mal eine Mittelwertbildung spendieren. Oder vielleicht einen Timer an den einen und den anderen Vergleicher um so etwas zu entprellen.
Aber jeder so wie er mag 8)
 
A-häm ...
Wir sprechen hier aber nicht von einem PID-Regler, der (je nach Konfiguration so etwas schon implementiert) sondern von einer 2-Punkt-Regelung.

@Lupo: Meine Antwort bezog sich nur auf bikes Einwurf mit anschließender Diskussion, das eine Mittelwertbildung sein MUSS. Die muss meiner Meinung nicht zwangsläufig sein. Es gibt noch andere Formen der Eingangssignalfilterung, die meiner Meinung nach sogar besser für die Aufgabenstellung geeignet sind. (Du hast ja einiges davon erwähnt)

Wobei die Frage, ob der TE das unbedingt machen muss, seine Entscheidung ist.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

hehe, es gibt ja viele Ideen und Vorschläge. Wie geschrieben, ich programmiere eigentlich Datenbanken und habe mit SPS nichts zu tun. Auch ist das Thema Heizung für mich neu. Bis vor 5 Jahren hatte ich auch nichts mit Elektrik zu tun, erst als wir das Haus gekauft haben, beschäftigte ich mich mit den Themen.

Ich bin schon froh, als totaler DAU meine Heizung hydraulisch verstanden und die komplette Elektrik und das SPS-Programm bis hier hin realisiert zu haben. Für einige ist das sicher kein Problem, wen genügend Erfahrung vorliegt.

Den Software-Regler habe ich von der Idee bis zur Realisierung eben selbst erstellt und nicht auf ein fertiges Produkt, wo ich Parameter, welche ich vielleicht nicht verstehe, angebe.

Nur kurz zu meiner Realisierung:

Ich errechne aller X(derzeit 35) Sekunden die eigentliche Solltemperatur anhand der Heizkurve und vergleiche es mit der IST-Temperatur. Wenn diese nicht X Grad (derzeit 2 Plus und 2 Minus) abweicht, unternehme ich nichts. Wenn diese Abweicht und die Tendenz der letzten Regelung geht in die richtige Richtung, dan warte ich weiterhin ab bis die Tendenz zu sehr stagniert, dann regle ich weiter mit einem Faktor (Abweichung in Grad Mal Faktor = Fahrt in Sekunden). Wenn der Mischer gerade voll am Anschlag AUF ist und ich heize gerade an, dann hebe ich den Faktor weiter nur beim Zufahren an, weil die alte Temperatur gerade noch ausreichte und gleich 80 Grad am Mischervorlauf anstehen werden. Das ist dann nicht die normale Abweicheung, welche entsteht, wenn draußen die Temperatur etwas wandert, der Puffer langsam kälter oder das Rücklaufwasser langsam wärmer wird.

Die Soll-Vorlauftemperatur errechne ich außerdem ensprechend ob Absenkbetrieb ist (z. b. Frostschutz oder gerade Warmwasserladung ist) oder ob normaler Heizbetrieb aktiv ist. Der Mischer hat nun auch zwei Endlagen. Der Mischer regelt, ob Rücklaufwasser mit in den Vorlauf gelangt.

Ist dann Soll und Ist unteschiedlich und weiter auseinander als meine Toleranzgrenze, dann rechne ich mit den Werten ohne Toleranz. Wenn ich so meinen Mischer beobachte, dann ist meine DAU-Regelung um Weiten besser als das fertig programmierte Gerät Gamma 2B.

Hinweise, wie genau ich das Ganze verbessern könnte, helfen mehr, als "nur" Begriffe in das Forum zu schmeißen, mit welchen man ohne Wikipedia-Studieren sowieso nichts anfangen kann (als DAU).

Ich kann mir nur soviel unter dem Mittelwert vorstellen, dass nicht die aktuelle ist-Temperatur geommen werden soll, sondern aus einer entsprechenden Zeitspanne die Werte zu einem Mittelwert gebildet werden. Wenn das so wäre, müsste man dann die ganzen anderen Bedingungen auch wieder berücksichtigen, was das Ganze nicht einfacher macht (Reaktion wenn Warmwasserbetrieb einsetzt, Frostschutzladung etc.)

Daher wäre es auch gut, wenn mir Personen das System erklären können, welche es nicht "nur" mal gehört haben oder den fertigen PID-Regler anwenden, sondern es vielleicht selbst programmiert haben.

Danke euch.


MfG

Olaf
 
Zuletzt bearbeitet:
Mittelwertbildung:

Du füllst zyklisch ein Array of Real mit dem aktuellen Messwert (an erster Stelle) und schiebst die "alten" Messwerte um eins nach hinten. Dann addierst Du alle Array-Inhalte zusammen und teilst die durch die Anzahl der Array-Felder. So erhältst Du den Mittelwert. Anzahl der Array-Felder und Intervall der Messung müssen den Anforderungen entsprechend festgelegt werden. Wobei es da viel Spielraum gibt. Bei einer Mittelwertbildung über die letzten 10 Sekunden brauchst Du Dir keine Gedanken über Warmwasserbetrieb, Frostschutz usw. machen. Das Messignal wird ja nur träger, aber nicht ungenauer. Was anderes wäre die dauerhafte Mittelwertbildung - dafür gibt es ein ganz andere Formel.

PID:
Meine Einschätzung: Einen PID-Regler programmiert hier niemand selber. Für die Profis hier bedeutet das nur zusätzlichen Zeitaufwand, die verdienen aber Ihr Geld damit. Einen PID wird also nur jemand "erfinden" wenn Ihm das Wissen um die Bibliotheken fehlt und er das Ganze als Hobby betreibt.
 
Hallo,

danke für deine Antwort.

Ich kenne die Bibliotheken und habe mich damit schon etwas beschäftigt. Was mich daran etwas stört:

- Ovesized - ich habe "nur" eine alte 315 und die Zykluszeit bzw. RAM sind nicht unendlich.
- Viele Parameter, die man erst verstehen lernen muss

Ich habe nur einen analogen Eingang (2AI und PT100, beide Kanäle für PT100). Um 8 Sensoren betreiben zu können, habe ich mir einen Multiplexer bauen lassen (genau für den Zweck, 0 bis 5 Volt). Der bekommt über Ausgänge der SPS den Impuls, immer die entsprechenden Kontakte zu schließen (inkl. Sens, Leitungskompensation). Das Abtastintervall kann ich einstellen, derzeit 500 Milisekunden. Das heißt, ich erhalte ohnehin aller 4 Sekunden "nur" einen Wert für den entsprechenden Bereich. Gut, ich habe dann natürlich keinen Mittelwert. Ich vergleiche aller 35 Sekunden (Parameter). Mir erschließt sich noch nicht so richtig der Vorteil, wenn ich nun den Mittelwert habe oder aber den tatsächlichen Wert.

Beispiel: Ich fahe 5 Sekunden den Mischer auf. Danach beginnen die 35 Sekunden Wartezeit. Solltemperatur ist 57,5 Grad. Mein Mischer hat glaube ich eine Gesamtfahrzeit von 180 Sekunden.
Nach Ansteuerung:
Sekunde 1: 55 Grad
Sekunde 10: 55 Grad
Sekunde 15: 55.3 Grad
Sekunde 20: 55.3 Grad
Sekunde 25: 55.5 Grad
Sekunde 30: 55,8 Grad
Sekunde 35: 55,8 Grad

Das heißt, die Temperatur ist weniger als 2 Grad positiv und negativ auseinander, ich regle nicht erneut. Ferner würde ich ohnehin nicht erneut regeln, da meine Regelung tendenziell in die richtige Richtung ging und sich der Wert entsprechend weit verändert hat. Die Hysterese (4 Grad) hat auch den Vorteil, wenn die Außentemperatur mal um 0,3 Grad hin und her pendelt, dass dort nicht gleich nachgeregelt wird. Wandert der Wert in die falsche Richtung (z. B. immer noch, weil die Vorlauftemperatur rasant ansteigt, Holzkesselanlauf), dann fahre ich sofort weiter zu. Warum jetzt also den Mittelwert von 55,4 bilden (wenn es jetzt 35 statt 10 Sekunden wären?) Wenn es in die falsche Richtung geht, ist das ja hinderlich, oder?

Ich = schwerer Fall, oder? Möchte es nur gern verstehen. Man müsste echt mal vergleichen, wie oft mein Baustein nachregeln muss und wie das ein fertiger PID-Regler handhabt.

Danke für die Hilfe.

Olaf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Mein letzter Beitrag war nur eine Begriffserklärung nicht eine Anwendungsempfehlung. Das mit der Mittelwertbildung hatte ja bike eingebracht - rostiger Nagel und ich, wir hatten uns dagegen ausgesprochen - wegen fehlender Dynamisierung. Und wenn Du sowieso nur alle 35s mit dem Wert arbeitest - dann hast Du eben einen zeitlichen Filter - das ist auch gut. Den hätte ich sowieso eher vorgeschlagen als eine Mittelwertbildung. Vergiss das mit der Mittelwertbildung für Dein Projekt.

Das Wort PID-Regler hatte ich nur eingebracht, weil bike irgendwie hatte durchblicken lassen, das es für Ihn nichts anderes gäbe als eine Mittelwertbildung. Bitte nicht ernst nehmen. Für Deine Anwendung würde ich auch keinen PID einsetzen. Übrigens: Ein PID wird üblicherweise im OB35 mit einem festen Takt (100ms, 1s, 2s oder länger) aufgerufen. Der frisst also keine Zykluszeit und der Datenspeicher ist auch kaum erwähnenswert.

PID-Regler setze ich immer bei zeitkritischen Regelungen ein, wenn ich schnell stabile Ergebnisse brauche (Prozesstechnik). Bei langsamen Prozessen ist der Vorteil, das man dem User bekannte Einstellmöglichkeiten (P,I,D usw) anbieten kann. Aber er ist kein Muss.
 
Ach, wegen oversized: Ich kann mir nicht vorstellen, das Du mit einer alten 315er bei einer Haus-Steuerung an die Grenzen kommst...
 
Derzeit sind implementiert:

- Türüberwachung, Zähler für Türöffnungen, Log Türöffungen, Zeiten für Türhistorie, Alarmanlage
- Wintergartensteuerung, Dachöffnung, Regensensor, Temperatur, Log Dachöffnungen und Zähler
- Heizungssteuerung, mehrere Dreiwegeventile, Ölkessel, Holzkessel, Ladesteuerung, Mischersteuerung, Heizkurve, Puffer; Log Ausgänge für Nachvollziehbarkeit Effektivität Steuerung (Mischer, Ventile, Entscheidungsstellen, Temperaturen, Frostschutzladungen mit Zeiten etc.), mehrere Betriebsarten mit unterschiedlichen Wochenzeitschaltuhren und Programmen, jeweils 4 Ein- und Ausschaltzeiten für Heizung, Warmwasser und Zirkulation. Betriebsstundenzähler und Brennerstarts. Baustein und Intelligenz für Multiplexer.

Derzeit ist etwa ein Drittel RAM belegt, mein Plan ist es aber, noch ausführlichere Berechnungen und Bewertungen durchzuführen (z. B. anhand Temperaturen und aktuellem/historischem Verbrauch Zeiten zu berechnen, wann wieder angefeuert bzw. nachgeladen werden muss etc.) Ich wollte mir auch die Option offen halten, wenn meine 315er mal abraucht, dass ich meine 314er mit 24 Statt 64 kb RAM noch verwenden kann.

Aktuelle Zykluszeit im Heizbetrieb 16 ms. Max. 35.

Klar, da ist noch viel Luft. Ich bin aber auch noch nicht fertig ;) Wie gechrieben, 314er als Reserve. Ein paar Prozent sind sicher noch drin, wenn man alles noch effektiver und besser programmiert. Bin derzeit aber mehr als zufrieden.

Grüße

Olaf
 
Zuviel Werbung?
-> Hier kostenlos registrieren
@asci25 and @ll

Auf diesem Wege mal ein Dickes Dankeschön für die umfangreiche Hilfe! Es ist sicher nicht immer einfach, sich in die Gedanken eines noch nicht erfahrenen Programmierers reinzudenken, das gelingt euch aber meist super!

Ich hoffe ich kann mal mit meinen Ideen helfen und punkten :)

Olaf
 
Zurück
Oben