Pylontech US3000 Plus - nastavení

[kadlos]

Pokud si pamatuji správně, tak SCC freeze a midnight charging řeší FW 71.82

Ondro nemáš odkaz? rád bych to případně upgradnul, klidně mužu až na verzi .86 což je oficialni . občas SCC zamrzne cca na 30s...
Bavíme se teda o PIP 5048 MK že?

Sorry za offtopic.
Díky Vítek

Tady https://www.fve-mp.cz/aktuality/navod-n ... pp-solar-6

[josse]

Pokud si pamatuji správně, tak SCC freeze a midnight charging řeší FW 71.82

Ondro nemáš odkaz? rád bych to případně upgradnul, klidně mužu až na verzi .86 což je oficialni . občas SCC zamrzne cca na 30s...
Bavíme se teda o PIP 5048 MK že?

Sorry za offtopic.
Díky Vítek

Tady https://www.fve-mp.cz/aktuality/navod-n ... pp-solar-6

Tak to jsou prasata, ani nejsou schopný zkopírovat změny mezi verzemi. Tohle se nedělá, z tohoto zdroje nedoporučuji aktualizovat!

[youda]

Josse,

ano, v tom příspěvku s fotkami grafů jsem opravdu napsal CC a CV opačně.
CC má být 52.5V
CV má být o 0.5V nižší, tedy 52V.

Nikde jsem nepsal, že ten prudký pokles nabíjecího proudu zajistí balancery. Naopak, psal jsem zcela jasně a srozumitelně, že ten pokles proudu zajistí MOSFET v cihle. Na to okamžitě zareaguje měnič přechodem do CV = 52V = 3.46V per článek. Do cihly pak teče už jen cca 0.2A, což evidentně stačí na to, aby to balancery srovnaly. Při tomto nastavení se to zastavuje na balančním napětí 3.485V per článek. 100% SOC je BMS oznámeno ve chvíli, kdy aspoň 13ks článků už má 3.485V a zbývající dva články jsou ještě trošku níže.

Samozřejmě to mám v ostrovu, a z DS nepřicucávám.

Pokud by měnič byl blbě nastavený, nepřešel by do CV, ale snažil se tam i přes MOSFET stále prát plný proud, tak se po chvilce rozsvítí červený alarm a baterky se úplně vypnou. Mě se to nestává, ale lidem kteří právě používají (špatně implementované) DCC občas ano, a pak brečí. DCC je super idea, ale musí se prostě dotáhnout do konce a před vypuštěním otestovat.

Jinak jak ses ptal na větrák, tak ten tam opravdu není a ani se to při provozu nehřeje. Elektronika je ale zavřená v plechové bedně, takže je klidně možné, že některý polovodič vysokou teplotu během provozu má. Paliče to ale nejsou určitě, kdybys to viděl rozebrané, tak bys hned pochopil, že nejsou stavěné na nějaké vysoké proudy. Jinak na MOSFETu je teplotní čidlo a jeho aktuální teplota se dá vyčítat přes CLI. Možná, až bude příležitost, připojím se k tomu během poslední fáze nabíjení a podíváme se, jaké teploty tam jsou.

Co se týče "premature float bugu" v Axpertu, ta chyba je o tom, že pokud přijde mrak, tak axpert přejde do floatu dříve, než jsou baterky plně nabité. Jelikož u Olova je napěťový rozdíl mezi bulkem a floatem dost velký, tak to vadí a olověná baterka s Axpertem opravdu může trpět podbíjením. V případě LFP není "premature float bug" žádný problém, protože rozdíl mezi CC a CV bývá minimální, například jen těch 0.5V. Takže, ikdyž by Axpert přešel během dne do "floatu", tak lithium stále nabije až do plna. Proto také australani napsali, že u PIP-MK a FW 71.86 nebudou zatím premature float bug řešit, jelikož tento FW a měnič MK je primárně používán vlastníky LFP baterek.

PS:
- Kdo nabíjí Pylontechy na 53.2V = 3.55V na článek, bez přechodu do nižšího CV, tak je blázen a zažívá právě overvoltage alarmy. A už mne dost unavuje, furt dokola vysvětlovat na všech fórech, že údajům ve specsheetu Pylontechu je potřeba rozumnět a nikoliv je pouze tupě nasázet do nastavení měniče. U 53.2V se to chová přesně jak píšeš: balancery to nestíhají pálit, mosfet to neudrží a baterky se při každém druhém nabíjecím cyklu vypnou na overvoltage alarm.

- Kdo je nabíjí na 56V = 3.73V na článek, tak je úplný sebevrah, to snad nemá ani cenu otvírat.

[youda]

No ta sestava ktera by se u kolegy prozatim delala by byla prave dost mala - jeden axpert 5kw s ACDCAC tedy king pokud mam dobre zjisteno a na zacatku dve cihly us3000. Pozdeji dalsi.

Takze se bojim jestli by to proste nezlobilo. Bude to v objektu kde zatim neni lidska posadka, ale je tam spotreba. Takze je treba aby to fungovalo autonome, spolehlive. No mam co studovat.

grafy atp jsou ficury, ktera neni primarne zadana. Pokud bude ok pokud nebude ok ale musi to fungovat jak ma.

PavelR,

fungovat to bude, akorát se prostě nesmíš spoléhat na vestavěnou BMS, ale k řízení měniče použít ICC a z něj pak datový kabel do master Pylonu. Největší problém budeš mít se sehnáním toho "kabelu", protože ve skutečnosti je to custom konvertor RJ-11 RS232 na USB.

Pokud ale v práci používáš Victrony, a nemáš tedy problém začínajícímu kolegovi pomoci s úvodním nastavením VenusGX a propojením všech datových kabelů, pak nechápu, proč se chceš trápit s něčím, co by pro tebe bylo poprvé. Navíc, jestli Victron komponenty nakupujete za velkoobchodní ceny, tak je přece pořídíš výrazně levněji, než co je videt na eshopech (narozdíl od číňanů je na Victronech pořád ještě smysluplná marže).

[rokytna]

No, zase abych úplně nekecal: Ve fabrické verzi Axpert King / PIP-MK bylo pár chyb a minimálně dvě z nich nový FW skutečně opravil:

Nevíte někdo kde by se dal dohledat Release Notes pro FW pro MK ? tam by to mělo být potvrzeno.

Všude je obvykle k dispozici jen ten ZIP s novou verzí (např. 71.86) ale ani v něm nic takového není.
Jediná šance je pak si skládat střípky z procházení fóra.
Ale třeba někdo oficiální Release Note má a může dát odkaz ? dík

[josse]

...Proto také australani napsali, že u PIP-MK a FW 71.86 nebudou zatím premature float bug řešit, jelikož tento FW a měnič MK je primárně používán vlastníky LFP baterek...

Já to čtu tak, že Australani vydali na premature-float-bug opravu:

But for those of you who have already done so, we do at least have patched firmware that fixes the premature-float bugs.
Coulomb and Weber's patched firmware:

A beta version of 71.80d (WP: b1.8d, LCD: 01.82) patched firmware which only fixes the premature float bugs

A Coloumb+Weber doporučují i pro LiFePO4 FW s opravenou chybou. Jediné kde to opravdu nevadí, není třeba jsou LiIon.

Se vším co jsi napsal souhlasím, je to prostě o tom, že tomu spousta instalačních firem nerozumí a nastaví to blbě, protože to opíší z příručky. To napětí se musí nastavit na úbytky, počty cihel a tak podobně. Ty jsi si komunikaci napsal sám. Od tebe to musí zkopírovat jako z příručky i s počtem cihel

Já jsem se pokusil sepsat fyzikální podstatu jak to Pylon dělá a když budu mimo limit co dokáže BMS (chápej: interní mosfet vyzářit tepla) tak to prostě fungovat nemůže, takže i když to má interní BMS tak to stejně dokážu zvenčí zničit(rozhodit, rozbalancovat a jak Ota v jiném příspěvku psal, skoro nadobro uspat, že to probudí až servis). Není to pro úplné blbce.

[josse]

Paliče to ale nejsou určitě, kdybys to viděl rozebrané, tak bys hned pochopil, že nejsou stavěné na nějaké vysoké proudy.

Jak je to udělané? Už to někdo překreslil a vysvětlil?

[Jan Novák]

Doc. Youda to ma ve sve laboratori.

[youda]

Jednu cihlu US3000 jsem před časem otevřel a nafotil vnitřek:
viewtopic.php?p=107463#p107463

Willcz, pak odhalil místa, kde jsem se spletl, a našel i kousek datasheetu od balančních obvodů:
viewtopic.php?p=107514#p107514

Komu se nechce koukat na obrázky a číst to celé, tak ve zkratce:
- SOC počítá 1x čip Texas Instruments BQ34Z100
- balancuje 2x čip Maxim Integrated MAX17830GUN/V
- maximální balanční proud, dle použitých odporů, je pouhých 70mA per článek

==>

• Tenhle balanční obvod není žádný "palič", dělaný k tomu, aby se přetlačoval s nabíječkou. Ideální pro něj je, pokud si nabíječka nechá dynamicky diktovat parametry (právě ono DCC).
• Není-li zprovozněna datová komunikace, nebo je-li DCC implementováno blbje, pak to musí zachránit FET. Ten, co je vidět na referenčním designu v prvním příspěvku. Na fotkách pajšlu vidět není, je namontován ze spodu desky (jak prozradil Kodl69).
• Pokud měnič na konci nabíjení nepřejde do "floatu", ale tlačí dál, nelze to ubalancovat MAXem ani uchladit na FETu a baterka se vypne na overvoltage alarm. Na protokolech CAN i RS485 tuto skutečnost BMS oznámí v příslušeném registru a navíc událost zapíše do interního logu BMS.
• Podle toho, kolik baterka zažila různých alarmů, přepětí na článcích, podbití článků apod, se postupně snižuje čítač SOH.

PS:
O víkendu, až u toho budu přes den, schválně zkusím znovu vyjet pomocí diagnostiky, jak jsou na tom teď články v jednotlivých cihlách. Naposledy jsem na to koukal v listopadu 2019 a články v první cihle vypadaly po nabití takto: (po kliknutí se screenshot zvětší)

cells112019.png

Zajímavé je, že v každé cihle jsou vždy dva články, které jsou napěťově trošku níž, než zbylých 13ks a přesto cihla vyreportuje 100% SOC. Na screenshotu výše jsou to Cell6+Cell7, které mají 3.45V, zatímco zbylých 13 článků má 3.47V. Jelikož takto se chovají opravdu všechny cihly, evidentně je toto chování zakódováno přímo ve FW. Zkoušel jsem i to, co se stane, když tlačím trochu proudu do plně nabité cihly a vypozoroval jsem, že se to snaží udržet na napětí 3.485V per cell.

[zbek]

Mam dotaz mate už někdo SOH na baterkach menši než 98 ?

[youda]

Já zatím furt 100.
Ale když budeš opravdu hodně smutnej, to nechám ze solidarity jednou vybít do mrtě, aby mi tam skočilo 99.

[PavelR]

No ta sestava ktera by se u kolegy prozatim delala by byla prave dost mala - jeden axpert 5kw s ACDCAC tedy king pokud mam dobre zjisteno a na zacatku dve cihly us3000. Pozdeji dalsi.

Takze se bojim jestli by to proste nezlobilo. Bude to v objektu kde zatim neni lidska posadka, ale je tam spotreba. Takze je treba aby to fungovalo autonome, spolehlive. No mam co studovat.

grafy atp jsou ficury, ktera neni primarne zadana. Pokud bude ok pokud nebude ok ale musi to fungovat jak ma.

PavelR,

fungovat to bude, akorát se prostě nesmíš spoléhat na vestavěnou BMS, ale k řízení měniče použít ICC a z něj pak datový kabel do master Pylonu. Největší problém budeš mít se sehnáním toho "kabelu", protože ve skutečnosti je to custom konvertor RJ-11 RS232 na USB.

Pokud ale v práci používáš Victrony, a nemáš tedy problém začínajícímu kolegovi pomoci s úvodním nastavením VenusGX a propojením všech datových kabelů, pak nechápu, proč se chceš trápit s něčím, co by pro tebe bylo poprvé. Navíc, jestli Victron komponenty nakupujete za velkoobchodní ceny, tak je přece pořídíš výrazně levněji, než co je videt na eshopech (narozdíl od číňanů je na Victronech pořád ještě smysluplná marže).

No chtel jsem trosku katovat kosty. Proste cena za 5kw stridac je u axpertu fajn.
Na victronu neni nic slozityho. kabelaze no problem, u asistentu maji nastaveni ke konktretni aku primo na strankach. Asi to tak dopadne.

[rokytna]

PIP 5048 MK který mi přišel v únoru od MPP, má v sobě verzi U1 71.80.
Poslal jsem email na MPP s dotazem, kde vzít nový FW.
Napsali mi až dnes (druhého března), že to je nejnovější FW.
Takže buď v tom sami mají zmatek, nebo ...

Dovolím si proto dotaz. Kde vzít 71.86 nebo novější verzi, o které se tady diskutuje.
Doufal jsem v oficiální zdroj od MPP, ale nějak se nepovedlo.
FVE-MP to má na webu, ale jak mám vědět že je to ta správná binárka.

Nemáte někdo link na ofiko nejnovější FW pro MK ?

[rokytna]

Řešil jsem úplně stejný problém. Chyba je v manuálu, řešil jsem to s Youdou a mám to nastavené takto:
05-USE
12-45,5
13-48
26-53,2
27-53,2
29-45

Jak je možné nastavit položku 12 s krokem 0.5V ? to je ta 3 kW verze ?

V návodu (a i v realitě) pro PIP 5048 MK:
5 KW : model setting range is from 44.0V to 57.0V and increment of each click is 1.0V

Pro 5048 MK tam tedy předpokládám nezbývá než dát 45.0V...

[youda]

Rokytna,

mnou doporučené hodnoty vycházejí z toho, co se dá nastavit na InfiniSolaru 5K a tam jdou u všech položek dát i desetiny. U Axpertů je to jak píšeš: 48V verze mívají u cut-off voltage granularitu nastavení 1V. Verze na 24V mají granularitu 0.5V. Takže pro Axperty holt skutečně nastavit cut-off na 45V (45V/15S = 3V per LFP cell).

Reálně všechny měniče měří napětí dost blbje, takže pro cut-off bych stejně použil nějakou externí logiku, která to bude přepínat podle SOC vypočteného na základě sledování odebraných ampérhodin. Takže třeba Victron BMV700, PLC s bočníkem, nebo něco na ten způsob.

PS: Když jsem to připojení Pylonů k měniči tenkrát řešil s Taranem, tak on používal měnič InfiniSolar 5.5, tudíž to asi mohl také nastavit takto jemně. Má ještě měnič PIP-GK, tak snad nám dá vědět, jak přesně to má nastaveno na tom PIP-GK.

[josse]

PIP 5048 MK který mi přišel v únoru od MPP, má v sobě verzi U1 71.80.
Poslal jsem email na MPP s dotazem, kde vzít nový FW.
Napsali mi až dnes (druhého března), že to je nejnovější FW.
Takže buď v tom sami mají zmatek, nebo ...

Dovolím si proto dotaz. Kde vzít 71.86 nebo novější verzi, o které se tady diskutuje.
Doufal jsem v oficiální zdroj od MPP, ale nějak se nepovedlo.
FVE-MP to má na webu, ale jak mám vědět že je to ta správná binárka.

Nemáte někdo link na ofiko nejnovější FW pro MK ?

Vyšší první dvě číslice nemusí znamenat novější.

Oni jaksi kvůli chybám a funkcím mají jak to říct česky, řady?

Detailní vysvětlení třeba hledat na aeva fóru... Píšu to sem nějak často...

První zajímavá info: {Coloumb}
Patched firmware 74.40e is now in early alpha testing (eyeballing the code). Depending on my time, it should be available for beta testing in the next week or so.

Vysvětlení k verzím {Coloumb opět}:
A higher major version number (say 74 in your example) is not necessarily later or better than one with a lower major version number (72 in your example). But yes, it's possible, e.g. you can update your 72.70 machine to 73.00e (not factory 73.00 because of the error 90 problem). In this case, you don't want to do that, since 72.70 is the best one for paralleling with a PF1.0 machine.

Viz také:
http://forums.aeva.asn.au/viewtopic.php ... 6cc#p77349

A měli jsme to dát do jiného vlákna...

[youda]

Já to do jiného vlákna právě dal
viewtopic.php?p=118158#p118158

[rokytna]

Takže pro Axperty holt skutečně nastavit cut-off na 45V (45V/15S = 3V per LFP cell).

Přesně, tohle jsem si chtěl potvrdit. Parádní, děkuji.

[rokytna]

PIP 5048 MK

...firmware 74.40e ... 73.00 ... 72.70

Pro PIP MK (o tom se celou dobu bavím, tj. King) existuje i 72, 73 či 74 ? co procházím internet horem dolem tak tak časově nejposlednější (od výrobce) je 71.86.
Ty patchované FW ale taky tuším (podle toho co tam čtu) nejsou pro typ MK ale pro ty jiné které ti borci mají.

A měli jsme to dát do jiného vlákna...

asi moje chyba, postnul jsem příspěvek do jiného okna, hmm mea culpa.

edit: I když o pár příspěvků výše se právě řeší přesně ty verze... takže trošku souvislost vidím. Ale asi by to bylo lepší ve vláknu k tomu měniči.

[youda]

Rokytna,

downloady jsem ti dal sem, do vlákna "Axpert": viewtopic.php?p=118158#p118158

Pro PIP-MK je zatím poslední verzí skutečně main 71.86 a control panel 2.0. V této verzi se Voltronic pokusil opravit problémy s komunikací s Pylontechem v režimu, kdy je více Axpertů spojených paralelně. Bohužel, ta oprava se povedla jen napůl, ale to už je tak nějak standard.

Patch verze 71.86 pro PIP-MK zatím Coulomb s Weberem neudělali (na AEVA vysvětlují detailně proč). Ve zkratce: jelikož oficiálně verze 71.86 byla zaměřena na uživatele Pylontechu, zatímco jejich patche řeší primárně problémy, které mají Axperty v kombinaci s Olovem. Pro úplnost, nejzajímavější vlastnosti patchovaného firmware jsou tyto:

• SCC premature float bug (Problém byl zejména s Olovem, kde je velký rozdíl napětí mezi Bulkem a Floatem. U lithia není tento bug zas tak nutné řešit, nebo CC a CV napětí jsou tak blízko sebe, že lithium se dobije ikdyž SCC přejde předčasně do CV stage.)
• Kettle compensation (Udrží měnič v chodu, i když dojde vlivem zapnutí rychlovarné konvice k poklesu napětí baterie pod hranici cut-off voltage.)
• Možnost dynamicky měnit nabíjecí proud (Vyžaduje externí automatizaci.)
• Možnost přepínat měniče běžící v paralelním zapojení do úsporného režimu (Vyžaduje externí automatizaci.)