Halve året vil nok de fleste inverterpumper også gå som on/off.
Eksempelvis styringsregime som hadde funka bedre for både meg og KE: On/off ut fra hysterese. Så lenge den er innenfor f.eks. +/- X grader av beregnet temperatur skal den være på. Som en vanlig termostat. Kommer den over skrur den seg naturligvis av - fram til returtemp(+deltaT, om du ikke har ekstern tempsensor) ramler under beregnet turledningstemp igjen. Hysteresen stiller sluttbruker etter hvor mye tempsvingning man tolerer. Så kjører det i enkleste fall en 'dum' PID-regulator som bestemmer frekvensen. Arbeidspunktet for PID-regulatoren kunne gjerne vært 'lærende' - dvs at den husker gjennomsnittlig effektbehovet ved gitte utetemperatur og bruker tilsvarende frekvens som utgangspunkt. Så kan PID-regulatoren finjusterer frekvensen opp/ned etter etter om tempen stiger eller synker.
Først nå når det nærmer seg 0 grader ute begynner jeg å ha så stort varmebehov at pumpa må gå hele døgnet. Så får vi se om gradminuttreguleringen funker greit utover vinteren.
Jeg kommer nok uansett til å programmere inn at GM settes tilbake (f.eks fra -20 til -120) dersom temperaturen er bare litt over beregnet. Det vil unngå unødvendige stopp og unødvendige oppgiring av frekvens når den skal "ta igjen det tapte". Så kan det også hende jeg endrer på 'sperrebånd' for å hindre pumpen i å gå på lavere frekvens enn jeg spesifiserer når det blir kaldt ute, slik at den starter opp på en passe frekvens etter varmvannsproduksjon.
(Jeg kjører nå med sperrebånd på 20-22hz for å få pumpen til å jobbe på 23hz og dermed gi en varmebærerflow over 5l/minutt som er det minste den innebygde flowmåleren kan måle. Før lå flowmåling og vippet mellom 0 og 5 og dermed ble også energiberegningen helt feil og 'målt COP' lavere enn reell.)
Men jeg har bygget opp en allergi mot "Kan du ikke bare...", både fra barndommen og gjennom mange år på jobben. Til ethvert stort komplisert problem finnes det en løsning som er åpenbar, enkel ... og feil!
Jeg har tillit til at Nibe-utviklerne vet hvordan de skal gjøre jobben sin. Hvis det var så enkelt som det framstilles her, ville de gjort det.
Mine innsigelser er ikke på det reguleringstekniske, men på innfallsvinkelen: Den totale mis-respekten for fagfolkene på Nibe, og denne overforenklede "Kunne de ikke bare...". Hvis det virkelig er så enkelt, da er det vel bare å lage noe bedre selv! Da Modbus forrige gang ble diskutert i denne tråden kom det fram at det er fullt mulig å "bløffe" VPen til å tro at den leser noe annet fra sine sensorer enn den faktisk leser. Og svært mange av "konklusjonene" kan også overskrives. I praksis kan man ta over full kontroll av VPen - enten direkte, ved å overskrive pumpas egne konklusjoner, eller ved å bløffe den ved å overskrive sensor-verdier. Så når du spør: Hvorfor kan ikke Nibe ganske enkelt gjøre sånn-og-slik? - da spør jeg i retur: Hvorfor kan ikke du ganske enkelt gjøre sånn-og-slik?
Jeg kjenner til din erfaring med "kan du ikke bare...", jeg har også full forståelse for dette. Derimot synes jeg du avsporer problemstillingen. Jeg hevder at Nibes GM prinsipp hører hjemme der man har stort aeal med nedstøpte rør. Jeg regner med du ikke har hatt kontakt med utviklerene til Nibe, jeg har helle ikke snakket med disse direkte men jeg har vert i kontakt med servicesjefen til Nibe og de har hatt en gjennomgang av min pumpe. De konkluderer med at pumpen gjør jobben sin som den skal, de klarer ikke engang å innrømme at pumpens regulering kunne vert bedre. Den norske importøren er noe mindre bastante og ser utfordringen, den norske importøren har ikke muligheter til å gjør endringer så der er det ikke noe å hente. Oppgaven til varmepumpen er enkel: Produser vann på innstillt temperatur. Nibe tenker for avansert, de skal ta igjen det tapte under pausen og overproduserer varme når en stund etter at den er startet. Typisk kan en pumpe gå hele natten og til og med lage jevn temperatur, så ut på dagen synker behovet for varme og romtermostatene regulerer ned flow på sløyfene. Dette medfører at temperaturen stiger og varmepumpen stanser. Ofte topper pumpen varmtvannet før pausen når den først er i gang. Alt velstand så langt. Utover dagen benyttes vann fra tanken for å vedlikeholde temperaturen i rommene, på ett tidspunkt vil varmepumpen starte igjen. Starten skulle jeg gjerne sett var basert på temperaturavvik, Nibe teller istedet GM noe som medfører at temperaturavviket vil variere mellom de forskjellige startene. Når den så starter vil den peise på for å ta igjen det tapte, den durer på med høyere frekvens. Temperaturen stiger men er fortsatt under beregnet, derfor teller GM fortsatt nedover og frekvensen settes enda høyere. Ikke engang når temperaturen begynner å nærme seg målet sakker den ned, temperaturen fortsetter å øke og først nå vil GM klatre oppover. Det er fortsatt på dagtid og effektbehovet er lavere enn om natten, temperaturen blir dermed så høy at den slår ut på maxtemp som gjerne er 5 grader over ønsket temp. Som regel stopper pumpen etter en slik syklus og venter på ny at GM skal synke. En har fått en temperaturvariasjon på opp mot 10 grader. En time senere er det på an igjen. Hadde pumpen behersket seg og konsentrert seg om rett temperatur kunne flere av disse stoppene vert unngått. Unngår man slike stopp har man jevnere temperatur og mindre slitasje, det burde vere ett mål i seg selv.
Modbus: Javisst er det mulig å skrive til pumpen, men man kan ikke "bløffe" hva som helst. Det er flere metoder som er interresant å prøve ut, jeg har prøvd flere med ulik suksess. Eksempler er: -styre varmepumpens start og stopp ved å skrive GM til varmepumpen, på denne måten kan man introdusere start stopp basert på temperaturavvik (hysterese). Dette er testet og virker. -unngå flere av de unødvendige stoppene ved å sørge for at GM ikke når null. Dette er testet og virker. -man kan også steppe frekvensen opp og ned ved å manipulere GM, men GM vil før eller siden nå null selv om effektbehovet er jevnt. Dette er den mest krevende delen av ekstern regulering, GM kalkuleres fortsatt av pumpen så man må skrive til modbusen så ofte at man setter den interne beregningen ut av spill. Dette fungerer også til en viss grad men jeg har ikke fått til noe som fungerer optimalt. Det krever litt tolmodighet når man skal eksprimentere med dette for man må se over tid hvordan en endring påvirker. Når Nibe i tillegg nekter å utlevere sin "konfidensielle" reguleringsformel må man eksprimentere for å finne ut hvordan man skal få de rette utslagene. Husk at man ikke kan sette Nibes GM beregning ut av funksjon (så vidt jeg kjenner til) så det er ikke rett frem å påvirke det eksternt.
Så kan det også hende jeg endrer på 'sperrebånd' for å hindre pumpen i å gå på lavere frekvens enn jeg spesifiserer når det blir kaldt ute, slik at den starter opp på en passe frekvens etter varmvannsproduksjon.
(Jeg kjører nå med sperrebånd på 20-22hz for å få pumpen til å jobbe på 23hz og dermed gi en varmebærerflow over 5l/minutt som er det minste den innebygde flowmåleren kan måle. Før lå flowmåling og vippet mellom 0 og 5 og dermed ble også energiberegningen helt feil og 'målt COP' lavere enn reell.)
Jeg har ikke klart å finne sperrebånd fra Modbus, vet du om det er mulig?
At pumpen ikke klarer å måle lavere flow enn 5L står heller ikke noen steder i Nibes manualer, det er ganske utrolig at en så viktig detalje ikke er med.
Burde vel vært en 2-40 på 1.5-6kW versjonen egentlig. Det er jo ikke kritisk for annet enn energimålingen til pumpa dette - men jeg mener energimålingen burde vært nyttet til mer enn info da den faktisk er den beste indikasjonen pumpa har på hvor mye energibehov huset har.
Når pumpen ikke får målt lav flow vil den heller ikke klare å telle kw produsert når flow er lav, de som regner på COP vil jo isåtilfelle få ett alt for lav COP, noe som igjen er grunn til å klage til Nibe. Så jeg tenker Nibe er oppmerksom på denne problematikken også...
Siden jeg enda ikke har fått noen VP i huset, så jeg ikke har noe å verifisere en modell mot - og forsåvidt ikke har noen utviklet modell å verifisere enda - anser jeg det som en hypotetiserende skrivebordsøvelse uten noen reell verdi om jeg skulle komme med en teoretisk vurdering av hva oppdateringen av Nibe-programvaren betyr for styringen, basert på null praktisk erfaring med Nibe og ufullstendig informasjon.
Jeg ser med forventning fram til dine praktiske forsøk og observasjoner. Kan denne utvidelsen gi deg jamnere varme i huset, er det jo det positivt!
Jeg synes bare din "kan du ikke bare" sammenligning er drøy siden jeg har brukt svært mye tid på få Nibe i tale, jeg har vert i kontakt med folk som normalt ikke håndterer after-sales saker og hadde stort håp om å få hjelp der. Jeg ble dermed skuffet når disse folkene ikke innrømmer svakheter med sin regulering. Jeg har gjort endel forsøk og kan med enkle metoder eksempelvis begrense det jeg kaller "uønsket stopp". Men det vil nok ta noe tid før en har en fullfungerende regulering. Det er mange begrensinger man møter når man skal styre noe via modbus, modbus har treg oppdatering så den er langt fra ideel til en slik oppgave. Men å skrive GM går fint via modbus så det er nok veien å gå.
Målet er ikke bare jevn temperatur, målet er jevn temperatur med lavest mulig turtemperatur og en en fornuftig start og stopp av pumpen. Temperaturen i rommene styres av romtermostater og er dermed ikke varmepumpens oppgave, men jo mer temperaturen i tanken svinger jo større utfordring er det å holde jevn romtemperatur.
Min "kan du ikke bare" var min måte å ekkoe din holdning til Nibe.
Det er mulig du har bygget deg en skikkelig simuleringsmodell av din installasjon, der du kan teste ut din egen alternative styring, og du nå med den ny-tilgjengelige parameteren kan sette inn i modellen din hvordan du vil justere den. Så kan du prøve det ut, og se om det har den effekten på kjøring av kompressoren, bruk av elkolbe og ikke minst: på romtemperaturen, som modellen din tilsier. Hvis ikke, må du raffinere modellen. Det er slik jeg kommer til å jobbe når jeg får pumpa i hus.
Å bare prøve litt her, litt der - "Skal vi se... Kanksje hvis vi justerer den verdien opp med 10% og den andre ned med 20%, da kan det bli bedre!", uten noe grundig analyse bak de 10% opp eller 20% ned, det blir bare famling i mørket. For å få grunnlagsdata for å bygge opp simuleringsmodellen din kan du naturligvis systematisk stege deg gjennom hele det lovlige verdiområdet for en parameter av gangen, og senere systematisk kombinasjoner av to og to parametere, og se hvordan pumpa oppfører seg, for å få en forståelse av interaksjonen mellom de ulike funksjonene, nok til å bygge modellen (og forståelsen) din. Siden modellen må omfatte også slukene, og du ikke har kontroll med hvordan utetemperaturen endrer seg, og bare delvis med hvordan brukeren oppfører seg (f.eks. hva de setter termostaten i de enkelte rom til), må du under utprøvingen og oppbygging av modellen gjøre noen antalgelser, særlig om slukene, og det kan hende du i ettertid må trimme litt opp. F.eks. kan du kanskje måtte legge inn effekten av solvarme gjennom et stort sørvent panorama-vindu, men at det gir deg en modell-oppførsel som samsvarer med pumpas faktiske oppførsel den dagen det var stekende sol fra morgen til kveld...
Når du har en slik modell, der du legger inn styring etter Nibes GM-modell, og pumpa oppfører seg rimelig likt i simuleringsmodellen og i det virkelige liv, da kan du prøve med din egen styringsmodell, og se om den simulerte VPen faktisk oppfører seg bedre. Eventuelt kan du begrense endringene til det du faktisk kan gjøre, de parametrene du kan sette via Modbus. Da kan du få testet det ut, ved å gjøre nettopp disse endringene, og se om VPen i virkeligheten oppfører seg slik som i din simulering. Hvis ikke må du justere modellen din.
Det er på den måten jeg mener det er fornuftig å jobbe. Hvis det du arbeider ut fra er nettopp en slik modell, da er det jo kjempeflott - det er noe helt annet enn å bare famle seg fram tilfeldig i setting av parametere, uten noen helhetlig forståelse.
Hvis du har en modell: Er du villig til å fortelle noe om hvordan den er utviklet? Har du basert deg på et standard basis simuleringsverktøy? Er det en analytisk, diff-ligning-orientert modell (jeg har ikke mye peiling på slike!), eller en diskret, hendelses- og objekt-orientert modell? I tilfelle en diskret modell: Hvor lavt ned har du gått i modelleringen, f.eks. er VPen ett komplekst objekt, eller et sett med samvirkende del-funksjoner? Hvilke attributter har slukene? Har du noen mekansime for å skripte oppførselen til eksterne kilder (brukere, sol/vind/utetemperatur etc.)? Har du noen mekansime for å logge faktiske eksterne verdier slik at du lett kan gerenere et skript for å kjøre simuleringen med ulike modeller - og i så fall: Hvordan handterer du at en simulering av varmesystemets oppførsel kan påvirke hvordan eksterne enheter opptrer? F.eks. kan det hende at en bruker skrur opp termostaten fordi det ble for kaldt, men ville ikke ha gjort det hvis det ikke ble for kaldt - hva antar du da i simulatoren din dersom den alternative styringen betyr av varmen holdes oppe? Antar du fortsatt at brukeren justerer termostaten, helt unødig?
Etc. etc. Men for å være ærlig: Jeg tror ikke at du har noen slik modell. Sammenlignet med det jeg her beskriver (som er mitt mål), virker det som at du ligger på nivå 'prøve å skru litt her og litt der'. Korriger meg om jeg tar feil her - men da skulle jeg også ønske at du ville fortelle litt mer detaljer om modellen din.
Før jeg begynner å teoretisere, vil jeg ha såpass godt grunnlag som en slik modell kan gi meg. Ellers blir det bare rå gjetting. Det kan andre få ta seg av.
Du har en fantastisk evne til å få det til å høres ut som at dette er rakettforskning, og dette klarer du altså uten å ha egen erfaring med Nibe. Dette dreier seg om å lage en temperatur ved hjelp av frekvensen til en kompressor, det er ikke rakettforskning! En hvilken som helst termostat gjør akkurat det samme. Selv med oljeovnen min var det enkelt å få 23 grader flatt i stuen min, uten nevneverdi slingring. Min holding kommer av erfaring, jeg var overbevist om at jeg invisterte i den beste varmepumpen på markedet, inntill jeg satte den i drift.
Utfordringen her er todelt, den ene utfordringen er at Nibe ikke lager regulering som benytter seg av temperatur som faktor. De benytter seg av temperatur over tid noe som er nødt til å gi forsinkelse på resultatet. Dette kan jeg ikke gjøre noe med, jeg har ikke mulighet til å styre kompressoren direkte slik som Nibes regulering gjør. Det er kun Nibe som kan gjøre endringer i reguleringen. Det eneste jeg kan gjøre er å påvirke modbus variablene som er tilgjengelig, med de begrensingene som finnes i modbus. Hadde jeg kunnet skrevet ønsket kompressorfrekvens til Nibe hadde saken vert enkel. Når Nibe heller ikke dokumenterer varmepumpens virkemåte så er det utfordrene å lage styring-på-styring. Dermed må man teste en hel del for å se hvordan responsen blir.
Mine påstander er basert på erfaring, samtaler med Nibe, dokumentasjon fra Nibe, en rekke epostsamtaler med Nibes serviceavdeling og utveksling av erfaring med andre som har Nibe varmepumper. At du Keal sår tvil om disse erfaringene er helt greit for meg, du er så overbevist om at Nibe gjør alt rett at jeg ikke skjønner hvorfor du ikke har handlet varmepumpe enda. Jeg ser frem til den dagen du setter i gang varmepumpen din og febrilsk stiller opp og ned på gradminuttinnstillingene i ett tappert håp om å forbedre reguleringen. Da kan vi snakkes! Er du sporty gir du meg lesetilgang til Uplinken din så jeg kan få oppleve den perfekte innstallasjonen din. Jeg vil også ønske deg velkommen til å synse rundt reguleringen om du skulle falle for fristelsen.
Eksempelvis styringsregime som hadde funka bedre for både meg og KE:
On/off ut fra hysterese. Så lenge den er innenfor f.eks. +/- X grader av beregnet temperatur skal den være på. Som en vanlig termostat. Kommer den over skrur den seg naturligvis av - fram til returtemp(+deltaT, om du ikke har ekstern tempsensor) ramler under beregnet turledningstemp igjen. Hysteresen stiller sluttbruker etter hvor mye tempsvingning man tolerer. Så kjører det i enkleste fall en 'dum' PID-regulator som bestemmer frekvensen.
Arbeidspunktet for PID-regulatoren kunne gjerne vært 'lærende' - dvs at den husker gjennomsnittlig effektbehovet ved gitte utetemperatur og bruker tilsvarende frekvens som utgangspunkt. Så kan PID-regulatoren finjusterer frekvensen opp/ned etter etter om tempen stiger eller synker.
Først nå når det nærmer seg 0 grader ute begynner jeg å ha så stort varmebehov at pumpa må gå hele døgnet. Så får vi se om gradminuttreguleringen funker greit utover vinteren.
Jeg kommer nok uansett til å programmere inn at GM settes tilbake (f.eks fra -20 til -120) dersom temperaturen er bare litt over beregnet. Det vil unngå unødvendige stopp og unødvendige oppgiring av frekvens når den skal "ta igjen det tapte".
Så kan det også hende jeg endrer på 'sperrebånd' for å hindre pumpen i å gå på lavere frekvens enn jeg spesifiserer når det blir kaldt ute, slik at den starter opp på en passe frekvens etter varmvannsproduksjon.
(Jeg kjører nå med sperrebånd på 20-22hz for å få pumpen til å jobbe på 23hz og dermed gi en varmebærerflow over 5l/minutt som er det minste den innebygde flowmåleren kan måle. Før lå flowmåling og vippet mellom 0 og 5 og dermed ble også energiberegningen helt feil og 'målt COP' lavere enn reell.)
Jeg kjenner til din erfaring med "kan du ikke bare...", jeg har også full forståelse for dette. Derimot synes jeg du avsporer problemstillingen. Jeg hevder at Nibes GM prinsipp hører hjemme der man har stort aeal med nedstøpte rør.
Jeg regner med du ikke har hatt kontakt med utviklerene til Nibe, jeg har helle ikke snakket med disse direkte men jeg har vert i kontakt med servicesjefen til Nibe og de har hatt en gjennomgang av min pumpe. De konkluderer med at pumpen gjør jobben sin som den skal, de klarer ikke engang å innrømme at pumpens regulering kunne vert bedre. Den norske importøren er noe mindre bastante og ser utfordringen, den norske importøren har ikke muligheter til å gjør endringer så der er det ikke noe å hente.
Oppgaven til varmepumpen er enkel: Produser vann på innstillt temperatur.
Nibe tenker for avansert, de skal ta igjen det tapte under pausen og overproduserer varme når en stund etter at den er startet. Typisk kan en pumpe gå hele natten og til og med lage jevn temperatur, så ut på dagen synker behovet for varme og romtermostatene regulerer ned flow på sløyfene. Dette medfører at temperaturen stiger og varmepumpen stanser. Ofte topper pumpen varmtvannet før pausen når den først er i gang. Alt velstand så langt.
Utover dagen benyttes vann fra tanken for å vedlikeholde temperaturen i rommene, på ett tidspunkt vil varmepumpen starte igjen. Starten skulle jeg gjerne sett var basert på temperaturavvik, Nibe teller istedet GM noe som medfører at temperaturavviket vil variere mellom de forskjellige startene. Når den så starter vil den peise på for å ta igjen det tapte, den durer på med høyere frekvens. Temperaturen stiger men er fortsatt under beregnet, derfor teller GM fortsatt nedover og frekvensen settes enda høyere. Ikke engang når temperaturen begynner å nærme seg målet sakker den ned, temperaturen fortsetter å øke og først nå vil GM klatre oppover. Det er fortsatt på dagtid og effektbehovet er lavere enn om natten, temperaturen blir dermed så høy at den slår ut på maxtemp som gjerne er 5 grader over ønsket temp. Som regel stopper pumpen etter en slik syklus og venter på ny at GM skal synke. En har fått en temperaturvariasjon på opp mot 10 grader. En time senere er det på an igjen. Hadde pumpen behersket seg og konsentrert seg om rett temperatur kunne flere av disse stoppene vert unngått. Unngår man slike stopp har man jevnere temperatur og mindre slitasje, det burde vere ett mål i seg selv.
Modbus:
Javisst er det mulig å skrive til pumpen, men man kan ikke "bløffe" hva som helst.
Det er flere metoder som er interresant å prøve ut, jeg har prøvd flere med ulik suksess.
Eksempler er:
-styre varmepumpens start og stopp ved å skrive GM til varmepumpen, på denne måten kan man introdusere start stopp basert på temperaturavvik (hysterese). Dette er testet og virker.
-unngå flere av de unødvendige stoppene ved å sørge for at GM ikke når null. Dette er testet og virker.
-man kan også steppe frekvensen opp og ned ved å manipulere GM, men GM vil før eller siden nå null selv om effektbehovet er jevnt. Dette er den mest krevende delen av ekstern regulering, GM kalkuleres fortsatt av pumpen så man må skrive til modbusen så ofte at man setter den interne beregningen ut av spill. Dette fungerer også til en viss grad men jeg har ikke fått til noe som fungerer optimalt. Det krever litt tolmodighet når man skal eksprimentere med dette for man må se over tid hvordan en endring påvirker. Når Nibe i tillegg nekter å utlevere sin "konfidensielle" reguleringsformel må man eksprimentere for å finne ut hvordan man skal få de rette utslagene. Husk at man ikke kan sette Nibes GM beregning ut av funksjon (så vidt jeg kjenner til) så det er ikke rett frem å påvirke det eksternt.
Keal, har du noen bidrag til dette?
Jeg har ikke klart å finne sperrebånd fra Modbus, vet du om det er mulig?
At pumpen ikke klarer å måle lavere flow enn 5L står heller ikke noen steder i Nibes manualer, det er ganske utrolig at en så viktig detalje ikke er med.
Spurte om dette med flowmåleren og fikk som svar at det ikke fantes måler som måler mindre enn 5L/min.
Tok meg et 10 sekunder på google for å finne at samme sensor som benyttes også finnes i 1-20 og 2-40 i tillegg til 5-100. ( http://www.grundfos.com/directsensors/products/flow_temperature/vfs/vfsc.html )
Burde vel vært en 2-40 på 1.5-6kW versjonen egentlig.
Det er jo ikke kritisk for annet enn energimålingen til pumpa dette - men jeg mener energimålingen burde vært nyttet til mer enn info da den faktisk er den beste indikasjonen pumpa har på hvor mye energibehov huset har.
Hva med deg Keal, har du noe mer tanker om dette?
Jeg ser med forventning fram til dine praktiske forsøk og observasjoner. Kan denne utvidelsen gi deg jamnere varme i huset, er det jo det positivt!
Målet er ikke bare jevn temperatur, målet er jevn temperatur med lavest mulig turtemperatur og en en fornuftig start og stopp av pumpen. Temperaturen i rommene styres av romtermostater og er dermed ikke varmepumpens oppgave, men jo mer temperaturen i tanken svinger jo større utfordring er det å holde jevn romtemperatur.
Det er mulig du har bygget deg en skikkelig simuleringsmodell av din installasjon, der du kan teste ut din egen alternative styring, og du nå med den ny-tilgjengelige parameteren kan sette inn i modellen din hvordan du vil justere den. Så kan du prøve det ut, og se om det har den effekten på kjøring av kompressoren, bruk av elkolbe og ikke minst: på romtemperaturen, som modellen din tilsier. Hvis ikke, må du raffinere modellen. Det er slik jeg kommer til å jobbe når jeg får pumpa i hus.
Å bare prøve litt her, litt der - "Skal vi se... Kanksje hvis vi justerer den verdien opp med 10% og den andre ned med 20%, da kan det bli bedre!", uten noe grundig analyse bak de 10% opp eller 20% ned, det blir bare famling i mørket. For å få grunnlagsdata for å bygge opp simuleringsmodellen din kan du naturligvis systematisk stege deg gjennom hele det lovlige verdiområdet for en parameter av gangen, og senere systematisk kombinasjoner av to og to parametere, og se hvordan pumpa oppfører seg, for å få en forståelse av interaksjonen mellom de ulike funksjonene, nok til å bygge modellen (og forståelsen) din. Siden modellen må omfatte også slukene, og du ikke har kontroll med hvordan utetemperaturen endrer seg, og bare delvis med hvordan brukeren oppfører seg (f.eks. hva de setter termostaten i de enkelte rom til), må du under utprøvingen og oppbygging av modellen gjøre noen antalgelser, særlig om slukene, og det kan hende du i ettertid må trimme litt opp. F.eks. kan du kanskje måtte legge inn effekten av solvarme gjennom et stort sørvent panorama-vindu, men at det gir deg en modell-oppførsel som samsvarer med pumpas faktiske oppførsel den dagen det var stekende sol fra morgen til kveld...
Når du har en slik modell, der du legger inn styring etter Nibes GM-modell, og pumpa oppfører seg rimelig likt i simuleringsmodellen og i det virkelige liv, da kan du prøve med din egen styringsmodell, og se om den simulerte VPen faktisk oppfører seg bedre. Eventuelt kan du begrense endringene til det du faktisk kan gjøre, de parametrene du kan sette via Modbus. Da kan du få testet det ut, ved å gjøre nettopp disse endringene, og se om VPen i virkeligheten oppfører seg slik som i din simulering. Hvis ikke må du justere modellen din.
Det er på den måten jeg mener det er fornuftig å jobbe. Hvis det du arbeider ut fra er nettopp en slik modell, da er det jo kjempeflott - det er noe helt annet enn å bare famle seg fram tilfeldig i setting av parametere, uten noen helhetlig forståelse.
Hvis du har en modell: Er du villig til å fortelle noe om hvordan den er utviklet? Har du basert deg på et standard basis simuleringsverktøy? Er det en analytisk, diff-ligning-orientert modell (jeg har ikke mye peiling på slike!), eller en diskret, hendelses- og objekt-orientert modell? I tilfelle en diskret modell: Hvor lavt ned har du gått i modelleringen, f.eks. er VPen ett komplekst objekt, eller et sett med samvirkende del-funksjoner? Hvilke attributter har slukene? Har du noen mekansime for å skripte oppførselen til eksterne kilder (brukere, sol/vind/utetemperatur etc.)? Har du noen mekansime for å logge faktiske eksterne verdier slik at du lett kan gerenere et skript for å kjøre simuleringen med ulike modeller - og i så fall: Hvordan handterer du at en simulering av varmesystemets oppførsel kan påvirke hvordan eksterne enheter opptrer? F.eks. kan det hende at en bruker skrur opp termostaten fordi det ble for kaldt, men ville ikke ha gjort det hvis det ikke ble for kaldt - hva antar du da i simulatoren din dersom den alternative styringen betyr av varmen holdes oppe? Antar du fortsatt at brukeren justerer termostaten, helt unødig?
Etc. etc. Men for å være ærlig: Jeg tror ikke at du har noen slik modell. Sammenlignet med det jeg her beskriver (som er mitt mål), virker det som at du ligger på nivå 'prøve å skru litt her og litt der'. Korriger meg om jeg tar feil her - men da skulle jeg også ønske at du ville fortelle litt mer detaljer om modellen din.
Før jeg begynner å teoretisere, vil jeg ha såpass godt grunnlag som en slik modell kan gi meg. Ellers blir det bare rå gjetting. Det kan andre få ta seg av.
Utfordringen her er todelt, den ene utfordringen er at Nibe ikke lager regulering som benytter seg av temperatur som faktor. De benytter seg av temperatur over tid noe som er nødt til å gi forsinkelse på resultatet. Dette kan jeg ikke gjøre noe med, jeg har ikke mulighet til å styre kompressoren direkte slik som Nibes regulering gjør. Det er kun Nibe som kan gjøre endringer i reguleringen. Det eneste jeg kan gjøre er å påvirke modbus variablene som er tilgjengelig, med de begrensingene som finnes i modbus. Hadde jeg kunnet skrevet ønsket kompressorfrekvens til Nibe hadde saken vert enkel. Når Nibe heller ikke dokumenterer varmepumpens virkemåte så er det utfordrene å lage styring-på-styring. Dermed må man teste en hel del for å se hvordan responsen blir.
Mine påstander er basert på erfaring, samtaler med Nibe, dokumentasjon fra Nibe, en rekke epostsamtaler med Nibes serviceavdeling og utveksling av erfaring med andre som har Nibe varmepumper. At du Keal sår tvil om disse erfaringene er helt greit for meg, du er så overbevist om at Nibe gjør alt rett at jeg ikke skjønner hvorfor du ikke har handlet varmepumpe enda. Jeg ser frem til den dagen du setter i gang varmepumpen din og febrilsk stiller opp og ned på gradminuttinnstillingene i ett tappert håp om å forbedre reguleringen. Da kan vi snakkes! Er du sporty gir du meg lesetilgang til Uplinken din så jeg kan få oppleve den perfekte innstallasjonen din. Jeg vil også ønske deg velkommen til å synse rundt reguleringen om du skulle falle for fristelsen.