marsalova poustevna

[vlkazajac]

marsal64, riesis zaver nabijania nad uroven SOC 80 % s cielom odstranit mikrocykly. Z cca 5 kWp ciste teoreticky mozes "valit" do baterie 100 A = 0,33 C kym je bateria hlbsie pod 80 %. Ak by si nastavil vytazovanie s obmedzenim prudu do baterie na 0,25 C pre SOC pod 80 % malo by to na bateriu daleko lepsi vplyv ako odstranenie mikrocyklovania. Riesenim by bolo venovat sa radsej algoritmu "prudkosti " nabijania v case a mikrocykly riesit ako doplnkovu fičuru....

Ze vytazovanie riesis regulaciou prudu je dobre !

[marsal64]

Dobré, tedy řešit variabilní nastavení hodnoty nabíjecího proudu baterií, aby se neomezovalo nabíjení při nižším SOC, ale aby se současně při nižším SOC neomezovalo vytěžování, když je proudu ze slunce nadbytek i pro nabíjení. Plus ono šetření baterie. To stojí za zamyšlení. Šetření baterie tímto způsobem je ovšem zesložitěno situací, když je bojler nahřátý a v pokojíčku vytopeno = vytěžovat není kam.

[diablo007]

Dobré, tedy řešit variabilní nastavení hodnoty nabíjecího proudu baterií, aby se neomezovalo nabíjení při nižším SOC, ale aby se současně při nižším SOC neomezovalo vytěžování, když je proudu ze slunce nadbytek i pro nabíjení. Plus ono šetření baterie. To stojí za zamyšlení. Šetření baterie tímto způsobem je ovšem zesložitěno situací, když je bojler nahřátý a v pokojíčku vytopeno = vytěžovat není kam.

No tak pro tyto případy mít přímotop někde pod střechou a topit pánubohu do oken jak se říká. Pokud je potřeba udržet zátěž dá se to pálit i takto nesmyslně. Nebo pak ještě nějaké mašinky na těžbu

[vlkazajac]

Nezmyselne palenie by nezmyselne amortizovalo menic. To radsej odopnut cast panelov ( pre paralelne stringy je to jednoduche ), alebo to odkomunikovat s regulatorom nabijania, ak taka moznost je.

[youda]

Marsal64,

máš v těch měničích FW s podporou commandu MNCHGC?
Tedy, jestli je pro tvoje typy vůbec takový FW dostupný.

Pokud ne, tak pozor na to, že standardní hodnota nabíjecího proudu se ukládá na EEPROM, která má omezený počet zápisů. Budeš-li tedy nastavovat maximální nabíjecí proud pomocí PLC příliš často, můžeš si měniče odpravit.

[marsal64]

Marsal64,

máš v těch měničích FW s podporou commandu MNCHGC?
Tedy, jestli je pro tvoje typy vůbec takový FW dostupný.

Pokud ne, tak pozor na to, že standardní hodnota nabíjecího proudu se ukládá na EEPROM, která má omezený počet zápisů. Budeš-li tedy nastavovat maximální nabíjecí proud pomocí PLC příliš často, můžeš si měniče odpravit.

Rozumím, komplikace při přenastavování měniče (ale i případném odepínání panelů, což mi také přijde jako dobrý nápad) tady jsou: zatím asi zůstanu u stávající popsané varianty a nejprve si odpozoruji, kolik vlastně nabíjím, aby "optimalizace" nepřinesly více škod než užitku. A protože slunce se krátí, asi to nechám nejdřív na jaro .

[marsal64]

Takový způsob úmrtí LFePO4 nastává při samovybíjeni. Stačí drobná závada v separátoru která se lavinovitě zhorší. Nafouklý článek ukazuje na vleklé podbití.
Ale už jsem viděl spoustu baterek které dopravila vadná BMSka nebo vadný balancer.
Zkus stabilizovaným zdrojem nabíjet proudem 0,01C

Tak to jsem zvědav, co řeknou zkušenější:
- nafouklé baterky jsem byl schopen oživit tak, že dávají z původních nominálních 100Ah nyní 70Ah (3,45 -2,9V, ovšem při proudu tak 5A , takže jde o "oživení")
- nenafouklé baterky se ukázaly jako neoživitelné

[padre]

Pokud ne, tak pozor na to, že standardní hodnota nabíjecího proudu se ukládá na EEPROM, která má omezený počet zápisů. Budeš-li tedy nastavovat maximální nabíjecí proud pomocí PLC příliš často, můžeš si měniče odpravit.

Externí EEPROM vydrží cca 1 000 000 zápisů. Takže pokud předpokládáš, že budeš měnič používat 30 let, můžeš použit cca 90 zápisů za den. Pokud FW měniče používá rolování buněk pro zápis v EEPROM (což nevíme) je to skoro bez omezení.

[youda]

Externí EEPROM vydrží cca 1 000 000 zápisů. Takže pokud předpokládáš, že budeš měnič používat 30 let, můžeš použit cca 90 zápisů za den. Pokud FW měniče používá rolování buněk pro zápis v EEPROM (což nevíme) je to skoro bez omezení.

Úvaha správná, ale obávám se, že perioda měření 20ms představuje řádově jiné číslo, než 90 zápisů za den:

Proud měřím relativně rychle přímo na shuntu (jeden cyklus měření mého PLC je mezi 10 až 20 ms) a vytěžuji tedy tak, aby tento proud byl dodržen.

Výchozí předpoklady:

• Dejme tomu, že světlo je cca 10h denně, ale dynamicky omezovat nabíjecí proud ve spolupráci s vytěžovačem nám bude stačit vždy jen jednu hodinu, někde u konce nabíjení baterie.
• Perioda meření je zde 20 milisekund, ale dejme tomu, že měnit hodnotu proudu budeme jen jednou za 1000ms, tedy jednou za sekundu.

Výpočet:
1h = 3600 sekund, takže to máme 3600 zápisů denně. Uvažovaných 90 zápisů denně je od toho opravdu daleko.
Endurance 1000 000 zápisů / 3600 = výdrž EEPROM 277 dnů.

To vše samozřejmě za předpokladu, že:

• V kódu neuděláme nikde chybu a nestane se třeba to, že budeme hodnotu proudu do měniče posílat 24x7. Tedy i v době, kdy je to zbytečné.
• EEPROM bude fungovat perfektně až do konce a nestane se, že by se s jejím opotřebením zvyšovala chybovost.
• Každý den dojde jen k jednomu plnému nabití baterie. Nikoliv tedy, že zapnutím silného spotřebiče naši baterii o pár procent vybijeme a následně ji bude měnič opět znovu dotahovat do plna a náš algoritmus znovu řídit nabíjecí proud.

Závěr:
Samozřejmě, faktorů majících vliv na opotřebení paměti je ve skutečnosti mnohem více. Pozitivně například může působit to, že v rámci roku je poměrně velké množství dní, kdy bude stačit řízení pomocí vytěžovače, a k automatickému omezování proudu tak náš algoritmus vůbec nebude muset přistoupit. Ano, měnič může stránky EEPROM rotovat, ale také nemusí. Zároveň, náš algoritmus není jedinou věcí, která EEPROM používá. Pomůže, pokud CPU před zápisem kontroluje obsah EEPROM a přepis provede jen v případě, že se nové hodnoty opravdu liší od uložených. Stejně tak by pomohlo, pokud má měnič implementován vyrovnávací buffer, jehož přepis do EEPROM provádí asynchronně, se zpožděním několika sekund. Jenomže to jsou všechno jen dohady a bylo by zvláštní, pokud by takové ochranné mechanismy v interním kódu měniče byly, když v normální aplikaci s tímto chováním výrobce vůbec nepočítá.

Každopádně, tento způsob řízení měničů může podstatným způsobem zkrátit jejich životnost, neboť k tomuto úkolu nebyly navrženy. Měnič má umřít na to, že mu vystřílí FETy a vyschnou kondenzátory. Nikoliv proto, že umoříme jeho řídící obvody nesmyslnou honbou za spálením všech wattů ze střechy a vyhlazením každé vlnky na baterii.

Pokud by problém se zničením EEPROM neexistoval, nevznikla by patchovaná verze firmwaru s příkazem MNCHGC.

[josse]

Je tam ještě jedna nevýhoda: Pokud se změní hodnota, která se zapisuje do EEPROM, a nepoužije se MNCHGC, MPPT se zastaví a začíná najíždět, když se použije MNCHGC, pak to udělá, sníží, zvýší, a jede dál. Je tam tedy "hloupou" cestou cyklování baterií ... On ty panely asi na sekundu úplně odpojí a najetí do plného výkonu jsou klidně 2-3 sekundy. Lepší je řídit vytěžování pak pozor MNCHGC a až jako poslední možnost změnit nabíjecí proud natvrdo.

[marsal64]

Takže "Stř.V" je PWM 6P, "Stř.Z" je MPPT 3P2S.
Právě tlačím očima výrobu a vidím, že pro tyto situace se PWM prostě moc nehodí (nebo to mám pro PWM dát 2S?? To snad ne?!). Podotýkám, že "Stř.V" a "Stř.Z" jsou stejné panely, vedle sebe a stejně orientované.
Myslím tedy, že objednám ještě jedno MakeSky.

[Vitek]

Takže "Stř.V" je PWM 6P, "Stř.Z" je MPPT 3P2S.
Právě tlačím očima výrobu a vidím, že pro tyto situace se PWM prostě moc nehodí (nebo to mám pro PWM dát 2S?? To snad ne?!). Podotýkám, že "Stř.V" a "Stř.Z" jsou stejné panely, vedle sebe a stejně orientované.
Myslím tedy, že objednám ještě jedno MakeSky.

kam to máš napojené do axperta?
on totiž mppt celkem papá i já pozoruji že má vlastní spotřebu velkou proti MPPT externímu, a taky se mi to v těchto dnech nelíbí. pokud nechceš čekat přijed si ke mě, makesky mám bud ti to odprodám nebo zapůjčím než ti dojde...

[marsal64]

kam to máš napojené do axperta?

PWM do Easun, viz podpis. Neraději bych ten Easun vyhodil ze systému úplně a vyměnil celkově za "zimní měnič" typu Victron jánevím 300W s minimální vlastní spotřebou; s tím, že bych to PWM Easunu vyměnil za Makesky. Druhého Axperta VMII bych používal jako "letní měnič". Přepínač je na to nachystaný... Jediná překážka je má lenost, protože z Easunu vyčítám do PLC spotřebu, musel bych to udělat jinak, ale už se chci vrhnout na FVE doma a nepředělávat furt poustevnu...
A ještě je tu druhý důvod - Easun Axpert je při malých výkonech tichý, takže (nejen) v noci je ticho. Druhý Axpert VMII hučí pořád :-/.

[vlkazajac]

Takže "Stř.V" je PWM 6P, "Stř.Z" je MPPT 3P2S.
Právě tlačím očima výrobu a vidím, že pro tyto situace se PWM prostě moc nehodí (nebo to mám pro PWM dát 2S?? To snad ne?!). Podotýkám, že "Stř.V" a "Stř.Z" jsou stejné panely, vedle sebe a stejně orientované.

Ak sú to tieto panely :
viewtopic.php?f=62&t=4132#p72467
tak by mali mať optimum okolo 27,0 - 27,5 V. Prepad výkonu pri 26,3 V je nepochopiteľný, odporúčam vylúčiť eventualitu, že je regulátor vo float. Podozrenie je silné ......

[marsal64]

Takže "Stř.V" je PWM 6P, "Stř.Z" je MPPT 3P2S.
Právě tlačím očima výrobu a vidím, že pro tyto situace se PWM prostě moc nehodí (nebo to mám pro PWM dát 2S?? To snad ne?!). Podotýkám, že "Stř.V" a "Stř.Z" jsou stejné panely, vedle sebe a stejně orientované.

Ak sú to tieto panely :
viewtopic.php?f=62&t=4132#p72467
tak by mali mať optimum okolo 27,0 - 27,5 V. Prepad výkonu pri 26,3 V je nepochopiteľný, odporúčam vylúčiť eventualitu, že je regulátor vo float. Podozrenie je silné ......

Ano, jsou to tyto panely. Když je osvit jen trochu větší, než byl v dokumentované situaci, panely na PWM se probouzejí a dávají, protože jejich napětí už stoupne výše než je napětí baterky. Rozumím tomu ale tak, že pokud má baterka 26.3V a panely stejné napětí, tak panely nedají s PWM v 1S zapojení nic. Roli mohou hrát přechodové odpory, kabely.

[josse]

Takže "Stř.V" je PWM 6P, "Stř.Z" je MPPT 3P2S.
Právě tlačím očima výrobu a vidím, že pro tyto situace se PWM prostě moc nehodí (nebo to mám pro PWM dát 2S?? To snad ne?!). Podotýkám, že "Stř.V" a "Stř.Z" jsou stejné panely, vedle sebe a stejně orientované.

Ak sú to tieto panely :
viewtopic.php?f=62&t=4132#p72467
tak by mali mať optimum okolo 27,0 - 27,5 V. Prepad výkonu pri 26,3 V je nepochopiteľný, odporúčam vylúčiť eventualitu, že je regulátor vo float. Podozrenie je silné ......

Ano, jsou to tyto panely. Když je osvit jen trochu větší, než byl v dokumentované situaci, panely na PWM se probouzejí a dávají, protože jejich napětí už stoupne výše než je napětí baterky. Rozumím tomu ale tak, že pokud má baterka 26.3V a panely stejné napětí, tak panely nedají s PWM v 1S zapojení nic. Roli mohou hrát přechodové odpory, kabely.

Pokud neteče žádný proud odpory jsou jedno jaké jsou. Kdyby bylo nás panelech o +1V více, bylo by to nejspíše vedením...

[vlkazajac]

Aha... už mi to došlo. V skutočnosti ide o to, že ako krivky pre STC, tak aj realistickejšie krivky pre NOCT, sú pre malé úrovne osvitu posunuté doľava, teda nielen vrcholy, ale celé "čiary". Pre najmenšie osvity jednoducho nie je dostatok napätia ( nad napätie batérie ). Tu má skutočne 2S s mppt obrovskú výhodu nad 2P s pwm. Nie je to problém so stratou napätia vo vedení.

Ilustračný obrázok z datalistu Jinko :

male napatie.jpg

[marsal64]

marsal64, riesis zaver nabijania nad uroven SOC 80 % s cielom odstranit mikrocykly. Z cca 5 kWp ciste teoreticky mozes "valit" do baterie 100 A = 0,33 C kym je bateria hlbsie pod 80 %. Ak by si nastavil vytazovanie s obmedzenim prudu do baterie na 0,25 C pre SOC pod 80 % malo by to na bateriu daleko lepsi vplyv ako odstranenie mikrocyklovania. Riesenim by bolo venovat sa radsej algoritmu "prudkosti " nabijania v case a mikrocykly riesit ako doplnkovu fičuru....

Ze vytazovanie riesis regulaciou prudu je dobre !

Díky Tvé inspiraci, vlkazajac, jsem udělal novou verzi vytěžovače včetně "emergency vytěžování", tedy pokud je SOC pod stanovenou hranicí (SOC hr), stejně se vytěžování pouští, když proud do akumulátorů je nad stanovenou mezí (I Ak>=hr). Říkám tomu "emergency vytěžování" (bez ohledu na jazykáře) vs. "standardní vytěžování", kdy se vytěžuje proudem (I Ak<hr), aby se stále trochu dobíjelo.
Začíná se mi to líbit a pořád je to velmi jednoduché, protože se reguluje proporcionálně podle rozdílu aktuálního proudu a jedné nebo druhé proudové hranice .

Kód: Vybrat vše

  // Stávající hodnota do pracovní proměnné
  CurDDVoltage := PhaseVoltage;

  // bylo dosaženo limitu měniče?
  IF (REAL_TO_UINT(mer[41].v_lsec) > PhaseDDPwLim) OR (axpert2.stats.acOutActivePower > PhaseDDPwLim)
  THEN  CurDDVoltage := CurDDVoltage - 0.5;  // rychlé snížení výkonu
  ELSE
    // rozhodování podle SOC - pokud je SOC pod rozhodovací hranicí, pak jen emergency vytěžování, pokud nad ní, standardní vytěžování
    IF (mer[51].v_lsec >= PhaseDDFromAbovePercSOCVyt)
    THEN CurDDVoltage := CurDDVoltage + (mer[29].v - TargetCurrent) * 0.001; // standardní vytěžování
    ELSE CurDDVoltage := CurDDVoltage + (mer[29].v - TargetEmergencyCurrent) * 0.001;  // emergency vytěžování
    END_IF;

  END_IF;

  // Limituj hodnoty pro regulaci na 0..maximální nastavená hodnota
  CurDDVoltage := MIN(PhaseDDTemperaturePhasePercVyt / 10, CurDDVoltage);
  CurDDVoltage := MAX(0, CurDDVoltage);

  // Přenos hodnoty pracovní proměnné na výstup
  PhaseVoltage := CurDDVoltage;

[marsal64]

Ptám se a zjišťuji porůznu, čím bych (časem) ten svůj odešlý pack nahradil.
Tady je FYI informace z evbattery, která přišla dnes (100Ah):


Dobrý den,

cena za článek je 2 180,- Kč bez DPH /kus.
Bohužel termín dodání až někdy listopad - prosinec.

[marsal64]

Tentokrát mi odešlo v poustevně po roce a čtvrt to naftové topení https://www.aliexpress.com/item/4000019936948.html.
Strategie přežití je jasná - koupit rovnou dvě nové. Na youtube jsou k tomu krásná videa, jak to lidi opravují, jedno z videí je, jak to kolega dělá v hubertusu v zimě, kdy mu to odešlo (https://www.youtube.com/watch?v=v7f5IKdYiuI).
Distribuce je btw z ČR, ale ještě to nebylo po dvou dnech expedováno a kolega na Ali přede mnou si stěžuje, že mu to nedošlo... Pestrý to činský svět.