Studer informacie

[beethowen]

Jasně, Batrium má relátka s programovatelným nastavením. Jedna z funkcí je Discharge OFF. Proč myslíš, že by bylo potřeba zpozdit signál? Stačilo by externě z relé BMS ovládat transfér relé v XTM.
Hledám cestu, jak to udělat bez externího drátování.

Já jsem to pochopil tak, že ti data z batria po CANu vypnula měnič dřive než by se připnulo transfer relé. Proto jsem myslel zpozdit ten CAN příkaz. Mezitím přepnout remote vstup.
Byla to jenom idea, nedíval jsem se do manuálu, jak se dají zpracovat data z CANu, takže třeba to jde i nějak bez dalších drátů.
Jestli jsem to pochopil správně, tak kvůli nízkému napětí na některém z článků došlo k zásahu BMS dříve než bylo dosaženo nízkého SOC, kterým by se připlo transfer relé?

[mgx]

u mna sa dialo nieco podobne, ale nie Battery STOP na undervoltage ale overvoltage. Ked som dokupil 4ks pylontechu 3.6kw. Interny balancing nejak fungoval, ale tak nejak "cinsky". Pomohli 2 veci:
1) docasne som prepol riadenie z BMS active na BMS observe -> zmena pin-u v XCOM-CAN. Napatove urovnia z CAN-u boli IMHO trosku "agresivne"
2) pripojil som druhu "hlupu" bateriu zo zvysneho LIfeYpo 16s packu s kapacitou 4.8kWh, ktora sluzi ako "buffer". To umoznilo prepnut pylon naspat do rezimu ACTIVE a v pripade, ze nastane battery stop na pylontechuv (z akychkolvek pricin) tak to mam naprogramovane tak, ze povolujem parameter 1128=1 a posielam alert obsluhe. Za posledny rok sa to ale nestalo. S mode CAN-observe som tiez bezal 1/2 roka BEZ problemov. teraz mam napr. riadenie CAN observe/passive.

[redcrown]

Jestli jsem to pochopil správně, tak kvůli nízkému napětí na některém z článků došlo k zásahu BMS dříve než bylo dosaženo nízkého SOC, kterým by se připlo transfer relé?

Chápeš to naprosto přesně. Jak ze strany BMS, tak ze strany Studer správný postup. Studer tak je naprogramovaný, tak proto píšu správně, ale rád bych to jinak, jen řeším jak.

[redcrown]

u mna sa dialo nieco podobne, ale nie Battery STOP na undervoltage ale overvoltage. Ked som dokupil 4ks pylontechu 3.6kw. Interny balancing nejak fungoval, ale tak nejak "cinsky". Pomohli 2 veci:
1) docasne som prepol riadenie z BMS active na BMS observe -> zmena pin-u v XCOM-CAN. Napatove urovnia z CAN-u boli IMHO trosku "agresivne"
2) pripojil som druhu "hlupu" bateriu zo zvysneho LIfeYpo 16s packu s kapacitou 4.8kWh, ktora sluzi ako "buffer". To umoznilo prepnut pylon naspat do rezimu ACTIVE a v pripade, ze nastane battery stop na pylontechuv (z akychkolvek pricin) tak to mam naprogramovane tak, ze povolujem parameter 1128=1 a posielam alert obsluhe. Za posledny rok sa to ale nestalo. S mode CAN-observe som tiez bezal 1/2 roka BEZ problemov. teraz mam napr. riadenie CAN observe/passive.

BMS děla přesně to, jak je nastavená. I to nastavení je podle mě správně. Spoustu parametrů můžu přenastavit, v tom asi není problém. Jen je potřeba Studeru vysvětlit, že má při "discharge stop" přepnout transfér relé a pak vypnout inverter. Zatím vidím jen problém v logice Studer, nikoli v BMS.
Pro normální provoz by se to dalo poladit, aby míra SOC vs. spodní napětí vycházela. Je to spíš o delším provozu, kdy se rozejde měření SOC - typicky zima, nebo příliš měkká baterka vůči výkonu měniče nebo nabíječe.

[mgx]

nie. Na to sluzi battery warning. rovnako ako orandzova na semafore. Battery stop je jednostranne rozhodnutie baterky, s tym uz zial invertor vela nenarobi.

[redcrown]

no já mám v BMS možnost "discharge stop", což znamená jasně ukončit vybíjení. Pak je tam ještě "critical battery", což je krizový stav a může např. odpínat baterii nebo volat hasiče. Ještě tam je "limited discharge", což asi umožňuje je v omezeném vybíjení. Tu funkci jsem zatím s XTM nezkoušel a nevím, jak by na ni reagoval. To ani nevím, kde to dohledat. Dokonce ani nevím, jak bych to vysvětlil Studerovi. Zkusím ověřit, jak už psal beethowen, jestli když se do remote entry pošle z BMSky signál, jestli se provede nejdřív připnutí transfér, a pak až vypnutí invertoru. Na měniči blikal Autorestart do doby, než BMS přešla do normální režimu a pak se provedl autorestart a nabíjení z VT normále jelo. Takže podle mě v podstatě všechno správně, až na možnosti logiky v XTM, protože tam prostě chybí události z BMS.
EDIT:
ještě v BMSce možnost nastavit Remote Discharge Target, což fungovalo výborně v přifázovaném režimu. Prostě snižuje proud vybíjení tak, aby bylo dosaženo cílové napětí. To ale stejně neřeší tu situaci s jednotlivými články.

[redcrown]

nie. Na to sluzi battery warning. rovnako ako orandzova na semafore. Battery stop je jednostranne rozhodnutie baterky, s tym uz zial invertor vela nenarobi.

S tím bych moc nesouhlasil, warning bych bral něco jako "už se blíží stav....". Ale ani varováním z BMS ten logic controloer asi moc neumí, ne? V BMS jasně nastavené, že se má vypnout nabíjení. To se taky stalo. Já to vidím na omezené možnosti logiky. Nu což, zkusíme to nějak obejít....

[redcrown]

a v pripade, ze nastane battery stop na pylontechuv (z akychkolvek pricin) tak to mam naprogramovane tak, ze povolujem parameter 1128=1 a posielam alert obsluhe.

Jak máš prosím tě nastavené, že na reakci Battery stop takhle zareaguje? díky

[beethowen]

no já mám v BMS možnost "discharge stop", což znamená jasně ukončit vybíjení. Pak je tam ještě "critical battery", což je krizový stav a může např. odpínat baterii nebo volat hasiče. Ještě tam je "limited discharge", což asi umožňuje je v omezeném vybíjení. Tu funkci jsem zatím s XTM nezkoušel a nevím, jak by na ni reagoval. To ani nevím, kde to dohledat. Dokonce ani nevím, jak bych to vysvětlil Studerovi. Zkusím ověřit, jak už psal beethowen, jestli když se do remote entry pošle z BMSky signál, jestli se provede nejdřív připnutí transfér, a pak až vypnutí invertoru. Na měniči blikal Autorestart do doby, než BMS přešla do normální režimu a pak se provedl autorestart a nabíjení z VT normále jelo. Takže podle mě v podstatě všechno správně, až na možnosti logiky v XTM, protože tam prostě chybí události z BMS.
EDIT:
ještě v BMSce možnost nastavit Remote Discharge Target, což fungovalo výborně v přifázovaném režimu. Prostě snižuje proud vybíjení tak, aby bylo dosaženo cílové napětí. To ale stejně neřeší tu situaci s jednotlivými články.

Musí být potom samozřejmě správně nastaveny parametry 1545 a 1538. Jenom nevím jestli prvně zareaguje ovládání po remote nebo příkaz po CANu. Proto jsem mluvil o zpoždění toho příkazu po CAN, ale nevím jaké jsou možnosti Batria a XCOM-CAN.

[redcrown]

S takovou technikou si člověk nemusí dělat starost o to, co bude dělat o víkendu:) Jinak jsem kolem nějakého nastavení XCOM-CAN a Batria a CAN protokolu nic nenašel. Zatím jsem řešil elementárnější věci.

[mgx]

na studer portali som mal nastavenu notifikaciu, ze akonahle pride warning, posle email s presne danym parametrom.

email dorazi na moj mail server, kde po sparsovani zavolam scomwebapi

a povolim parameter 1128= 1

tu je k tomu nejaka trapna stranka

https://portal.studer-innotec.com/scomw ... eParameter

rychlejsie samozrejme mat vlastny scom server interny a po zisteni notifikacie natvrdo povolit 1128=1. da sa to aj inak, mne sa s tym velmi nechcelo srat

[kodl69]

To jako fakt? když bms zahlásí že "batery low" tak projde komunikace přes půl světa, aby došlo k přepnutí na síť? neuvěřitelný. Mě k tomu stačí relátko a metr drátu.

[mgx]

mal= minuly cas. ale funguje to BEZ relatka . teraz mam scom, kde to bezi po lokalnej sieti (co ale kazdy nema).
PS: pri riadeni BMS observe tento stav nenastal nikdy . Ja tym BMS made in china velmi neverim...

vyhoda programoveho riadenia oproti relatku je, ze relatkom nemas sance ovplyvnit vsetko. mozes ovladat maximalne nejake 2 stavy (AUX1,AUX2) a v podstate si skoncil. vyhoda je ze netreba na to ziadne extra programovanie, jednoducha elektirkarina. Ale kazdy ma to svoje, niekto rad koduje v C++ a stykace mu nevonaju, niekto opacne.

[marsal64]

Jojo, já věděl, že se mi to PLC i k Studeru bude hodit..., cooo, redcrown?

[marsal64]

Mám dva identické stringy, každý na jeden Variotrack. Stringy téměř čistě na západ a východ, sklon 16 stupňů, bez zastínění, takže rozdíl ve výkonu, viz obr., mi nedává smysl a působí to na mne buď HW problémem nebo že jsou VT nastaveny každý jinak.

Než vytáhnu scom.exe a začnu zkoumat pojistky, dráty, atd., zeptám se z lenosti tady, jestli se s tímto někdo zkušenější nepotkal resp. jestli to nejde ověřit jednodušeji: když nastavím jánevím 10005 pomoci remote console na portálu, tak to zapíše pro oba Variotracky, které by měly být pak sesynchronizované, ne?

A přečíst hodnoty z jednotlivých Variotracků pomocí remote control na portálu tedy jde nebo to můžu jen pomocí scom ev. PLC apod. posazeného na XCOM nebo přes backup?

Měl jsem původně nabíjení sesynchronizované s XTM, pak jsem to rozpojoval (10037) - nemohlo by to souviset?

[kybos]

Tipnul bych to na nedostatečnou spotřebu. VT2 má měření napětí nakalibrováno o trochu jinak než VT1 a když je na sběrnici dostatečné napětí od VT1, tak se už VT2 nemá o co snažit. Vypadá to, že SW řešení není tak dokonalé, aby se mohly oba rozdělit o výstupní výkon spravedlivě na půl.

[jahodovák]

Pokud jsou identické a kabeláž to dovolí,stačí přehodit vstupy od panelů a uvidíš

[Kobra23]

Já bych viděl problém v těch různých délkách kabelů z VT na Busbar. Měly by být stejně dlouhé (myslím + i -) jinak to prý zlobí.

[marsal64]

Tak to by bylo zajímavé, odhaduji rozdíl tak 20 cm na + (35 mm2) a 20 cm na - (250mm2). Zatím bych řekl, že hřebíček na hlavičku trefuje kybos.

kabelyvt.jpg (55.85 KiB) Zobrazeno 620 x

Edit - nepomlouvejte mne, fotka je před vyvazováním a rovnáním kabeláže

[vlkazajac]

Veď je to jasné, kybos má pravdu. Špičky zo zeleného grafu sú akoby odčítané do čierneho grafu. Nie je to jednoducho kam dať a ten zelený treba "priškrtiť". Vlastne je otázka, či to má brať marshalovi spánok. Asi nie. On sa v tandeme vždy niekto fláka....