Optimering av styrsystem för soldriven vattenrening

Berätta om dina pågående projekt.
Användarvisningsbild
Hesabon
Inlägg: 278
Blev medlem: 6 oktober 2010, 21:30:26
Ort: Finland

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av Hesabon »

Som fortsättning på mitt föregående inlägg:

Jag hade en tanke på att centralenheten också skulle kommunicera med solpanelernas laddningsregulator över Modbus, men den tanken har jag skrotat. Regulatorns Modbus klarar endast 9600 baud, vilket är på tok för långsamt. Det skulle uppstå sådana väntetider på svar, att programmet helt enkelt skulle haka upp sig.
Tyvärr skulle nog en del av de 24 olika parametrar som regulatorn kan erbjuda kunna vara mycket nyttiga och användbara, så jag har som plan B att låta en separat processor, ex. en Arduino Nano, kontinuerligt samla in parametervärdena över Modbus, och sedan på begäran leverera "de senaste" till centralenheten över I2C (400 kbps).
Jag tänker ändå, att den inkommande sommaren tittar jag hur långt man kommer med befintliga sensoreringar och parametrar. Ifall de parametrar som nu s.a.s uteblir, skulle kunna förbättra beräkningarna, så får jag planera det tillägget nästa vintersäsong.

En sådan viktig parameter, vilken endast regulatorn kan ge är, att laddningen av batterierna går över i s.k ”floating”. Det är nämligen då som regulatorn anser att batteriet är fullt laddat.
Den uppgiften behövs bl.a för att beräkna i vilket skick batteriet är. Mellan två tillfällen av ”Batteriet fullt laddat” räknar man hur mycket laddning man tagit ut Cout [As] och hur mycket laddning gått in Cin [As] och förhållandet mellan dessa Cout/Cin [%] anger konditionen. (As är ju samma som Coulomb, men jag mäter Ampere, och jag mäter sekunder, därför As :wink: )
Av en kommentator tidigare i tråden fick jag veta, att ett nytt batteri grovt sett kan ligga på ca 90%, men att det ganska snart kan falla till 60..70%. I något skede faller nivån sedan så lågt, att det börjar bli dags att byta ut batteriet. Vet inte exakt vilken nivå det är, men det märker man sedan. => Viktigt att ha något man kan följa.
Sedan sägs det, att speciellt blybatterier (som används här), trots att de är batterier avsedda för solpanelsanläggningar, inte tycker om att alltför ofta tömmas mycket, att det tär på livslängden.
Jag har försökt hitta mera information om den saken, men det verkar bara finns riktgivande information, inget som man kunde använda i beräkningar.
Förhoppningen är förstås, att jag genom att kontinuerligt följa med laddnings- och urladdningsnivåer, hur ofta och hur mycket och sådant, skall lära mig att förstå hur det hänger ihop.
Man kunde kanske då försöka optimera belastningen av batteriet på ett annat sätt.(?)

Men som sagt, det blir ingen Modbus nu åtminstone. Senare…

Menyhanteringen, eller meny-”navigeringen”, som jag kallar rutinen, är uppbyggd utgående från LCD-displayens begränsningar: 4 rader á 20 tecken och styrd av Hitachi-kretsen HD44780. (Den kretsen har redan minst 40 år på nacken, men är de facto standard för små textdisplayer – trots sina egenheter och begränsningar.)
Alla menyer har max 4 rader och max 18 tecken. Den näst sista teckenpositionen på raden är ett tomrum före den sista, vilken är reserverad för cursorn, vilken är en pil till följande meny (”>”).
Menyhierarkin är som ett [liggande] träd, med pil Vänster går man till föregående nivå [mot roten], med pilarna Upp och Ner flyttar man cursorn till föregående/följande rad, och med pil Höger går man till följande nivå enligt den rad som cursorn står på. Inga menyer ”scrollas” (har inte flera än fyra rader), bara för att hanteringen blir enklare så.
Det sätter kanske en del begränsningar, men jag tycker nog att jag får ihop en tillräckligt logisk menyuppdelning ändå. Det här användargränssnittet är ju trots allt inte för vilken användare som helst, utan endast för ”tränade” systemadministratörer. Viss statusinformation får och kan vem som helst titta på, men alla egentliga inställningar kräver, att man först klarat av pin-koden.

I slutändan på grenarna i menyträdet kan man sedan ställa in 1 - 4 parametrar. Vissa tas i användning genast, andra kräver kvittering med att trycka Enter (t.ex. tid och datum ställer du in alla "delar", och först därefter kvittering).

För menyerna behövs en hel del textsträngar och för hierarkin behövs parametrar vilka pekar på föregående/nästa nivå. Det kan vara besvärligt att hantera alltihop, i synnerhet då man vill lägga till eller ändra menyer och nivåer. När jag höll på med mitt växthusprojekt utvecklade jag ett system i LibreOffice Calc (som MS Excel). Kalkylbladet producerar automatiskt både textsträngarna och menykartan så, att man med enbart Copy-Paste kan flytta in dom i Source-filen.

Jag hade tänkt lägga in några bilder av displayen och navigeringen, men LCD-displayen verkar uppdateras med en sådan frekvens, att absolut ingen text syns på bilden. Jag skall försöka med en kort video, i annat fall kanske bara skissa upp det.
Jag får återkomma till det.
Användarvisningsbild
Hesabon
Inlägg: 278
Blev medlem: 6 oktober 2010, 21:30:26
Ort: Finland

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av Hesabon »

Igår stötte jag på ett praktiskt problem vilket gjorde, att jag idag stort fick stöka om i programmet.

För att dokumentationen skulle vara mera lättläst hade jag gått in för att spara olika grupper av variabler och parametrar i behållare. Med en behållare avser jag en struktur (struct) som består av olika typer av data vilka logiskt hör ihop. Eftersom man hänvisar med namnet till variablerna i behållaren blir programmet enklare att läsa, naturligtvis förutsatt att variabelnamnen är tillräckligt beskrivande. :wink:
Nu är ju saken den, att jag samlar ihop och statistikför mycket mera än det som för närvarande används i processen. Exempelvis mäts och statistikförs solintensiteten, men jag vet inte hur jag skall använda den informationen i själva processen. Den effekt solpanelerna ger ut är förstås beroende av solintensiteten och jag mäter både laddning och förbrukning, men inte vet jag det matematiska sambandet mellan solintensitet och panelström i olika situationer, t.ex vid olika [batteri-]laddningsnivå. Förhoppningsvis kan jag efter hand komma till någon insikt genom att följa med dessa värden och hur de beter sig.
Jo, jag erkänner nog, att jag garanterat är ute efter mera data än vad som faktiskt behövs. :humm:

Programmet noterar också t.ex. maximum och minimum under dagen för olika parametrar (batterispänning, tryck, solljus, mm) och de värdena påverkar ju inte något annat.
Ändå är de intressanta, så jag vill kunna avläsa dem möjligast enkelt.

Igår började jag så fundera på hur jag skulle kunna bläddra igenom de här parametrarna och då upptäckte jag, att tanken med behållare ["struct-metoden"] är helt bakvänd här! Eftersom varje variabel då kräver, att man tar fram värdet på den med dens unika namn, blir det bara omständigt och krångligt att konstruera rutinerna som visar värdena på displayen.

Så blev jag då tvungen att spola tanken med strukturer.
Nu är variablerna som hänför sig till olika sensoreringar i stället grupperade enligt typ i matriser, och för att göra programmet läsbart har jag definierat enumereringar (jag vet inte vad annat det kan heta bland programmerare i Sverige – i finskan finns ingen översättning, var och en använder sin egen rotvälska finglish) vilka används som index i matriserna.

Nu är tanken då den, att jag i respektive matris har en samling parametrar vilka jag kan hänvisa till med parameterns namn, eller med ett numeriskt index. Det senare gör då, att jag enkelt kan göra en meny där jag kan "scrolla" igenom matriserna och kolla upp värdena. För att veta vilken parameter man läser krävs förstås en samling strängar med parametrarnas namn, men där kan man ju plocka fram det rätta namnet med samma index, så det är ingen konst med det.

Som jag nämnde i förra inlägget är jag tvungen att definiera många variabler globalt för att möjliggöra att programmet hela tiden rullar på, utan att stanna upp och vänta på något.
En annan sak som kräver en del globala variabler i detta fall är, att vissa variabler används av båda processerna (på var sin CPU-kärna).
Alla de variablerna används dock så, att bara den ena processen skriver en variabel, men båda processerna får läsa den.

Ja, så det var alltså städ-dag idag...
Användarvisningsbild
MiaM
Inlägg: 12368
Blev medlem: 6 maj 2009, 22:19:19

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av MiaM »

Med data om solinstrålning osv och i förlängningen data om hur mycket sol som behövs v.s. hur mycket mer panelerna kunnat ge, så kan det kanske gå att dra nån slutsats om ifall det skulle vara lönsamt att använda extraenergin till något?

Minns att jag nog redan dragit upp det tidigare, men ändå. T.ex. skicka överskottsenergi till de boende på ön, eller liknande. Eller till nån laddningsstation där folk kan ställa sina batterier för laddning, eller nåt. Eller kanske inget alls :)
Användarvisningsbild
Hesabon
Inlägg: 278
Blev medlem: 6 oktober 2010, 21:30:26
Ort: Finland

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av Hesabon »

Du har så rätt, det grämer mig alltid litet när solen skiner för fullt, och alla tankar och kanistrar redan är fulla och inget att göra med den dyrbara gratisenergin man plockar ner.

Och alla hus har redan egna solpaneler. Det finns ingen "marknad" för mera el.

Det bästa vore, att hela tiden utnyttja den till max för vattenrening. Signaturen nifelheim var redan tidigt inne på rätt spår i ett inlägg här i tråden. Förslaget var att varför inte
bara sätta dit en extra tank parallellt med den nuvarande 200-liters tanken?
Just det är en sak som jag hoppas kunna räkna ut ifall det lönar sig och i så fall hur stor den tanken skall vara. Kanske 200 liter, kanske något mindre(?)

Större än vad man med den befintliga produktionskapaciteten hinner fylla lönar sig ju inte, ifall man nu inte vill lagra vatten någon längre tid.

På tal om det så tål nog vatten som renats med omvänd osmos en mycket längre lagring än t.ex. "stads-"vatten".
Tidigare hämtade vi kommunalt kranvatten från fastlandet i 15-liters plastkanistrar. Ifall man lämnade det stående kunde man redan efter en dryg vecka se början till algbildning. Vattnet var nog ändå alldeles drickbart utan bismak, men så vill man nu inte ha det.
Förutsatt att man skruvat locket på ordentligt, så kan det osmosrenade vattnet faktiskt stå flera veckor i samma kanistrar, utan minsta tecken på algbildning. Därför kunde man också tänka sig att bygga upp en "buffert" i en extra tank i god tid före sommarinvasionen/högsäsongen, men det är nog inte säkert att det är lönt. Förbrukningen, vad det än gäller - tid, pengar, vatten - allt, tenderar ju att växa fast tillgången ändå.
Användarvisningsbild
MiaM
Inlägg: 12368
Blev medlem: 6 maj 2009, 22:19:19

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av MiaM »

Jag har aldrig upplevt något synligt fel på det kommunala vatten jag ibland har i dunkar, men däremot tycker jag att plastdunkarna lämnar en smak av just plast.

Jag är å andra sidan den sorts person som känner klar skillnad på smaken på Coca Cola i vanlig plastflaska, aluminiumburk och glasflaska, där glasflaska smakar avsevärt bättre. Jag är också den sorts person som nästan aldrig dricker rent vatten, och om det sker så är det direkt ur kranen, för jag tycker att allt kommunalt vatten och även "mineralvatten" smakar äckligt grustag. Kom nu just på att jag har nog inte smakat avfrostningsvatten från kyl/frys, och inte heller "batterivatten" från biltillbehörsbutiker. Det sistnämnda ska man kanske låta bli, men avfrostningsvattnet från kyl/frys är ju knappast sunkigare än luften och varorna som funnits i kyl/frys.

Tyvärr anses väl regnvatten inte vara rent nog för att dricka sen många år pga alla föroreningar.
Användarvisningsbild
MadModder
Co Admin
Inlägg: 31120
Blev medlem: 6 september 2003, 13:32:07
Ort: MadLand (Enköping)
Kontakt:

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av MadModder »

Avfrostningsvattnet från frys smakar... gammal frys. Även om den är ny :)
Påminner lite om att käka snö.
Användarvisningsbild
MiaM
Inlägg: 12368
Blev medlem: 6 maj 2009, 22:19:19

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av MiaM »

Apropå äta snö :D


(Sorry, ska försöka låta bli att spåra ur tråden i framtiden)
Användarvisningsbild
Hesabon
Inlägg: 278
Blev medlem: 6 oktober 2010, 21:30:26
Ort: Finland

Re: Optimering av styrsystem för soldriven vattenrening

Inlägg av Hesabon »

Jä..ln!
Fastän som finländare menar jag förstås Pe..le!
Jag stötte på en bugg i Espressifs (= ESP32-processortillverkaren) drivrutiner. Det kom en uppdatering (ESP32 ver 3.2.0) till Arduino IDE:ns BoardManager. Tajmingen på I2C-kanalerna har där ändrats så, I2C inte fungerar, utan ger bara en massa felmeddelanden.
Den tidigare versionen (3.1.3) fungerar som den skall, så det var iofs ingen sak att gå tillbaka, men eftersom jag anmälde buggen till Espressif, så måste jag ju vara tillgänglig för att testa patcharna.

Testpatchar utanför den officiella Arduino IDE-versionshanteringen måste laddas på ett helt annat sätt (manuellt) så det är inte bara att uppdatera och återställa efter behov, men nu lyckades jag få till ett script som gör det enkelt att växla. Nu kan jag iaf fortsätta med mitt eget också.

I min applikation sätts nog I2C-kanalernas tajmning nog på prov. Det mest krävande är att den ena har förutom 5 "lokala" slavar en sjätte ca 8m längre bort, som dessutom är ansluten över en linjebuffer.
Men med ovannämnda version 3.1.3 fungerar det.

Parallellt får man sedan se hur det går med patchandet.

Tilläggsinfo för den som är intresserad: Jag analyserade I2C bussen med versionerna 3.1.3 resp 3.2.0. Där ser man skillnaden.
När datat är sänt på I2-kanalen skall processorn frigöra kanalen genom att låta SCL-signalen gå hög. Då kvitterar slaven med ACK eller NACK.
I (3.1.3) är tiden mellan den sista databyten tills det processorn frigör I2C-kanalen ca 2 us, men i (3.2.0) är den 16 us. (detta på I2C i sk Fast Mode, dvs 400k).

Felmeddelandena som kommer pekar på att retursignalerna är "oväntade". Min felbedömning här är inte alls säker, men det verkar alltså som att något "tajmar ut" i drivrutinen och så förstår processorn inte
varifrån ACK/NACK signalen kommer.
Skriv svar