netappie schreef op zaterdag 28 december 2024 @ 13:47:
[...]
Als het warmteverlies te laag ingesteld staat dan zal de temperatuur vaak niet gehaald worden.
De datapunten in jouw grafiek zijn dan een gevolg van die instelling, niet van het werkelijke verlies.
Begrijp je wat ik bedoel? Een beetje als: "Mijn kinderen hebben genoeg aan 50 euro kleedgeld per maand omdat ze 600 per jaar aan kleding uitgeven." Dat hoeft niet waar te zijn.
Ja, als de stooklijn ("Warmteverlies" in Quatt taal) de enige variabele is waarop vermogen bepaald wordt. Maar ze sturen op kamertemperatuur, dus zou er ook real-time correctie toegepast moeten worden. Een integrator (i in PID, zie eerdere posts van mij en o.a. @
Stefannn ), dat is een getal dat steeds verder oploopt als de temperatuur onder de gewenste temperatuur is, zou na een paar uur echt al wel een groot getal moeten zijn, en zou dus binnen een paar uur waarschijnlijk wel vol vermogen van de Quatt moeten vragen.
Dan krijg je op den duur een overshoot (en dan loopt de integrator weer terug, omdat je weer boven de gewenste temperatuur zit), maar dat is hoe "real-time correctie" (een "controller") werkt.
Wat dus wel zou kloppen is dat een te laag vermogen voor eerst te langzaam opwarmen en daarna een grote overshoot zou zorgen, maar niet dat hij het helemaal niet haalt.. Het zorgt daarmee wel voor meer ruis op de datapunten, maar de trend ervan zou wel moeten kloppen lijkt me.
Een goed ingestelde stooklijk/warmteverlies zorgt er vooral voor dat het "real-time" stuk minder hard bij hoeft bij te sturen, en dus sneller opwarmen en minder overshoot, en daarmee minder ruis op de datapunten.
Edit: Even een plaatje ter illustratie:
Eerst: Ik heb geen Quatt, maar volg dit topic met veel interesse, net zoals Stefannn.
Ik lees met OpenTherm de thermostaat uit. Die stuurt iedere ongeveer 15 minuten de ketel aan, en blijft dan X minuten branden. De gele grafiek bovenin is teruggerekend hoeveel % van de tijd hij aan staat (dus hoeveel hij moduleert, in de tijd)
Blauw bovenaan is een waarde die ik reverse-engineered heb vanuit de kamertemperatuur met een PID controller, door de parameters te schatten. Inmiddels verander ik die parameters niet meer, want het schat hem goed genoeg.
Onderin is hoe de blauwe bovenin is berekend: Een i-term (integrator) en een pd-term (waarvan d uitstaat, dus alleen p eigenlijk). De P-term is gewoon de "fout" van de temperatuur op dat moment. De I-term is juist de optelsom daarvan: als P positief is loopt I op, als P negatief is loopt I af. De P en I tel je op tot de blauwe, en die is weer precies hetzelfde als de blauwe bovenon, behalve dat die bovenin nooit onder 0 kan komen (dus negatief wordt op 0 gezet, want je kan niet van 15 minuten -1 minuut aanstaan)
Wat er hier dus te zien is is een typische overshoot: de temperatuur loopt niet snel genoeg op, en de P en I term lopen samen vrij hard op. Daarna geeft de vloerverwarming eindelijk echt warmte af, en gaat P vlak en daarna weer naar 0. Maar er zit al zoveel warmte in de vloer dat de termperatuur daarna nog vrij lang blijft oplopen, ondanks dat de PID al terugloopt. Dat gaat zodanig dat uiteindelijk P al een tijd negatief is, maar zelfs I al "leeg" is. Een uurtje of wat later is P weer positief geworden en herhaalt het verhaal zich, al is het met een kleinere overshoot.
Dit gedrag stabiliseert zich uiteindelijk altijd (dat is een eigenschap van een PID controller, als er niet teveel ruis is e.d.).
Helaas is er na de 2e overshoot wel ruis in mijn huis, namelijk mensen die wakker worden. Er is dus te weinig tijd om te stabiliseren. En in de avond is de vloer afgekoeld, en begint het feest weer opnieuw. Ik heb inmiddels genoeg info om zelf een goede stooklijn te maken, en ik ga hem maken naar inspiratie van @
Stefannn , nu nog tijd vinden
[
Voor 44% gewijzigd door
nairolf op 28-12-2024 14:35
]