Studer informacie

[marsal64]

Ahoj, hledám možnost, jak komunikovat se Studerem co "nejrychleji" pomocí PLC.
Moc tomu nerozumím, ale RS-232, Modbus i CAN mi zatím vycházejí nastejno, s "doporučenými" časy na odezvu 1s (CAN) resp. 2s (RS-232). Z tohoto pohledu je snad jedno, jestli se používá třeba RS-232 a baudrate 38400 nebo 115200?

[mypower.cz]

Ahoj, hledám možnost, jak komunikovat se Studerem co "nejrychleji" pomocí PLC.
Moc tomu nerozumím, ale RS-232, Modbus i CAN mi zatím vycházejí nastejno, s "doporučenými" časy na odezvu 1s (CAN) resp. 2s (RS-232). Z tohoto pohledu je snad jedno, jestli se používá třeba RS-232 a baudrate 38400 nebo 115200?

Jaky je vlastne duvod s tim komunikovat co nejrychleji? Jako dotazovat se na stav treba jednou za pul sekundy, nebo jeste min? Jaky je ucel?

[marsal64]

Jaky je vlastne duvod s tim komunikovat co nejrychleji? Jako dotazovat se na stav treba jednou za pul sekundy, nebo jeste min? Jaky je ucel?

Z mého pohledu co nejrychlejší provedení změny některých parametrů od inicializace této změny (například změna nabíjecího produ baterií), pokud takových parametrů bude více v jedné dávce ("přeprogramování Studeru").

[mypower.cz]

si myslim ze 1s az 2s jsou naprosto v klidu, zbyle stavy si resi menic interne, pokud ne, neni schopen je vykomunikovat po techhle rozhranich. Na takove rychle veci by bylo asi nutne volat INT (interrupt) nejakeho externiho zarizeni, ale to asi rychleji zareaguje analogove cildlo, treba proudove, ktere posle hodnotu vysokeho proudu do rpi nebo arduina (atmelu) a ten v radu milisekund vypne rele, trebas. Otazkou je porad ten ucel. Rychla reakce, ale ceho konkretne... v realne situaci.. Treba nahodme nejakou konretni modelovou situaci...

[marsal64]

Otazkou je porad ten ucel. Rychla reakce, ale ceho konkretne... v realne situaci.. Treba nahodme nejakou konretni modelovou situaci...

OK, nemám to ještě úplně promyšlené, ale uvažuji, že pokud třeba zjistím vyčtením z BMS, že se mi rozhazuje "nahoře" napětí baterek, tak snížím napětí absorbce a současně omezím nabíjecí proud.
Ale smyslem dotazu je nyní zjistit, jestli nějaká varianta je výrazně komunikačně rychlejší, nebo je to v zásadě jedno.

[mypower.cz]

Jasny. Myslim si ze 1-2s reakce bude postacovat cteni z menice / bms nebo z neceho jineho, a na rychlejsi reakce bude potreba nejaky ten atmel a analogove cidlo. Pak to bude jistota mnohem rychlesi reakce. Pokud tedy totez nezajisti jine zarizeni samo o sobe (bms / menic)

[mobilik]

Je zbytočné riešiť externé zariadenia prúdové snímače, analógové atď... Keď studer vie na všetko zareagovať príkazom.
Je to určite jednoduchšie a rozumnejšie.

[mypower.cz]

Jen abych tím bodíkem nenasral admina

Proc jako? Nejake bodiky boha jeho. Snazim se odpovedet a podelit se o know how.

[marsal64]

Jen abych tím bodíkem nenasral admina

Proc jako? Nejake bodiky boha jeho. Snazim se odpovedet a podelit se o know how.

Já vím


Edit:
A už se těším, jak bude to stromečkování, protože tady zapadnul můj původní dotaz na rychlost komunikace se Studerem...

[DanoP]

Ahoj, hledám možnost, jak komunikovat se Studerem co "nejrychleji" pomocí PLC.
Moc tomu nerozumím, ale RS-232, Modbus i CAN mi zatím vycházejí nastejno, s "doporučenými" časy na odezvu 1s (CAN) resp. 2s (RS-232). Z tohoto pohledu je snad jedno, jestli se používá třeba RS-232 a baudrate 38400 nebo 115200?

rychlost odozvy zavisi aj na tom z akej skupiny je dotazpvany parameter. Z testov RS232 cez XCom mam poznatok, ze odpoved na dotazy zo skupiny info (podla popisu RS232 komunikacie) je okamzita, t.j. hned po odoslani dotazu pride odpoved. Horsie je to s dotazmy z inych skupin, co som skusal tak moze oneskorenie byt aj 1s, stava sa ze korektna odpoved je az na druhy dotaz.
Co sa tyka riadenia nabijacieho prudu - myslim ze na tie ucely to plne dostacuje, na riadenie by malo uplne stacit znizit nabijacie napatie a prud klesne akutomaticky - len treba regulacnu slucku navrhnut tak, aby sa nerozkmitala.

[marsal64]

Z testov RS232 cez XCom mam poznatok, ze odpoved na dotazy zo skupiny info (podla popisu RS232 komunikacie) je okamzita

Díky, začínám tedy tušit, že jít třeba do CAN asi nedává smysl.

[Torgeir]

CAN, RS232, RS485 ...

asi by sa v tom mohol spraviť trochu prehľad. Snáď sa moc nepomýlim ak uvediem nasledovné riadky

Úvaha nad modelom OSI
=====================

podľa
https://sk.wikipedia.org/wiki/Model_OSI

sa sieťové protokoly rozdeľujú do siedmich vrstiev. V mnohých prípadoch nemusia byť všetky vrstvy zmysluplné, no pre základné rozdelenie vyššie uvedených komunikačných liniek budem z tohto modelu vychádzať.

najnižšie leží fyzická vrstva. Tá definuje, akým fyzikálnym spôsobom sa prenáša základné kvantum informácie (v našom prípade to bude jeden bit). Od fyzickej vrstvy závisia vlastnosti ako minimálne garantovaný dosah prenosu a tiež odolnosť proti rušeniu.

Sem patria rozhrania s OC (otvorený kolektor - LIN, I2C, SPI, ...), s využívaním diferenciálnych párov (RS485, RS422, ...) , ale tiež RF, IR, ...

V tejto vrstve nie je definovaný protokol. To znamená, že zatiaľ iba viem, ako čo hardvérovo pozapájať aby sa minimálne dve strany mohli vedieť dohodnúť, no neviem, čo mám cez fyzické rozhranie posielať. Obe strany, ktoré chcú komunikovať musia mať rovnako dohodnuté všetky využívané vrstvy z modelu OSI

Linková vrstva definuje, ako budú údaje balíčkované na najnižšej úrovni. Zároveň linková vrstva definuje, či sa bude jednať o:

- synchrónnu komunikáciu (I2C, SPI, ...), kde prenosová rýchlosť je určená riadiacou stanicou a môže kolísať podľa jej aktuálnych potrieb. Kvôli tomu je potrebné na fyzickej vrstve prenášať aj signál CLK, ktorý definuje, kedy nastala/má nastať zmena na dátových signáloch. Prenos dát je synchronizovaný riadiacou stanicou.

- asynchrónnu komunikáciu (UART), kde musí byť prenosová rýchlosť dohodnutá vopred. Keďže prenos nie je synchronizovaný, na začiatku každého balíčka dát (napríklad bajt) musí byť vysielaná synchronizačná značka začiatku (bit) a na konci balíčka je synchronizačná značka konca balíčka. Komuikujúce zariadenia musia byť dohodnuté na prenosovej rýchlosti a tiež na štruktúre základného balíčka údajov ako je počet bitov v baličku (napr. 5,6,7,8, ..., 11,...), ochrana balíčku paritou (O,E,N) a štruktúre stop sekvencie ( 1 - 2 bity)

Napríklad väčšina zariadení s linkovou vrstvou I2C (jedná sa o synchrónnu komunikáciu obdobne ako SPI ktorá často využíva fyzickú vrstvu typu OC) očakáva, že na začiatku je definovaná START sekvencia a po ňom bude nasledovať bajt (8 bitov) za ktorým ešte bude bit ACK. Na konci všetkých bajtov bude nasledovať STOP sekvencia.

Pre zariadenia s UART-om (v PC často označovaný ako COM) platí, že sa jedná o asynchrónnu komunikáciu a bity sú balíčkované do slov zvyčajne pozostávajúcich s 5,6,7,8 alebo viac bitov (CAN zbernica). Na začiatku každého slova sa vysiela jeden START bit a na konci slova sa vyšle jeden až dva stop bity.


Vrstvy sieťová a transportná pridávajú k prenášaným užitočným dátam smerovosť (napríklad adresu zariadenia) a (ďalší) stupeň odolnosti voči rušeniu pridaním nejakého nástroja pre detekciu chýb vložených počas prenosu. Inak tieto nástroje môžu slúžiť buď iba na čo najkvalitnejšiu detekciu chyby (CHS, CRC), alebo aj na určitú samoopravu prijatej správy (Hammingove kódy).

Z uvedeného vyplýva, že úplne bez problémov môžem prenášať údaje cez SPI linku prostredníctvom fyzickej vrstvy štyroch krútených párov s rozhraním RS485. Získam tým
predĺženie dosahu rádovo na stovky metrov až kilometre a zvýšim odolnosť voči rušeniu. A tiež to, že údaje protokolu MODBUS nemusím prenášať výhradne cez RS485, ale môžem ich prenášať i cez infračervené vlny.


Keď mám dohodnutú fyzickú, linkovú, sieťovú a transportnú vrstvu, bolo by ešte vhodné vedieť, akým protokolom budem komunikovať. Teda aký bude význam jednotlivých dátových balíčkov (zvyčajne bajtov) na tom ktorom mieste v správe.

Pre protokol MODBUS je to veľmi pekne popísané v dokumente:

http://home.zcu.cz/~ronesova/bastl/files/modbus.pdf

A naviac, ešte ani vedieť presný protokol mi celkom nestačí. Lebo ešte musím vedieť, z akého dátového miesta si mám údaje vypýtať a čo konkrétne znamenajú a na aké konkrétne miesto mám čo zapísať, aby mi napríklad zoplo relé. Až potom budem môcť komunikovať medzi dvoma zariadeniami. Bez ohľadu na to, akú fyzickú či linkovú vrstvu použijem.

Takže je dobré rozlišovať medzi fyickou vrstvou a ostatnými vrstvami.



Úvaha k fyzickým vrstvám
========================
RS232 - full duplex zbernica v zásade určená pre prenos údajov tak do 25m. Málo odolná voči rušeniu, pre voľakedajšiu implementáciu do PC stále veľmi často používaná

RS485 - half duplex diferenciálna zbenica určená i do silne zarušeného prostredia. veľmi odolná a určená pre prenos rýchlosťou od 115kb/s na niekoľko km (minimálne 1,2km) do 10Mb/s do pár desiatok-stoviek metrov. Existuje veľké množstvo prevodníkov RS232/RS485 i s galvanickým oddelením

CAN - half duplex diferenciálna zbenica obdovná ako RS485 s tým, že prenos log.1 je mäkký, lebo musí byť prebitý log.0 vysielanou iným zariadením. Z toho dôvodu je o niečo menej odolná ako RS485. So zariadeniami, ktoré používajú CAN protokol sa nedá bežne priamo použiť UART za pomoci nejakého jednoduchého prevodníka/budiča RS232/CAN. Existujú také prevodníky, no z princípu sa jedná už o veľmi komplexné komunikačné riešenia.
CAN má zmysel použiť v prípadoch, keď navzájom komunikuje viac ako dve zariadenia a majú/musia mať možnosť "skákať si do reči". Ink to zmysel nemá, lebo komunikačná rýchlosť je pri väčších vzdialenostiach obmedzená časom šírenia sa vlny vo vodiči. Strana ktorá vysiela musí mať možnosť bezpečne zistiť, že jej niekto "skočil do reči" prebitím jej log.1 vysielaním log.0.

LIN - half duplex jednovodičová zbernica typu OC pre krátke vzdialenosti, napríklad v rámci automobilu. Jedná sa o jednoduchú primerane odolnú zbernicu na menšie vzdialenosti i do priemyslu, ak o nič veľmi nejde s lepšími vlastnosťami ako RS232. V protokoloch využívajúcich LIN sa často vysiela špeciaálny bajt pre zosynchronizovanie komunikačných rýchlostí, keďže sa predpokladá, že nejaký aktuátor bude tak lacný, že pobeží s presnosťou interného RC oscilátora. Takúto synchronizáciu je možné samozrejme využiť i pri iných rozhraniach.

I2C, SPI - relatívne rýchle synchrónne sériové rozhrania určené pre použitie v ráci jedného zariadenia využívajúce fyzickú vrstvu typu OC.


Úvaha nad rýchlosťou
====================
Spoľahlivá ľahko dosiahnuteľná komunikačná rýchlosť (dá sa očakávať malý vplyv rušenia) je napríklad 19200Bd. To znamená, že za jednu sekundu môžem pri prenose 8E2 (štart bit, 8bitov, parita, dva stop bity) teoreticky preniesť 1745 bajtov.

Budem vychádzať z osvedčeného protokolu MODBUS RTU, kde pri požiadavke o načítanie vstupných registrov musím k výzve pridať 8B (1B adesa, 1B, kód funkcie, 2B subadresa, 2B počet registrov, 2B CRC) a samotná odpoveď bude obsahovať naviac 5B. Indikácia ukončenia každej správy je realizovaná prestávkou vo vysielaní v dĺžke minimálne 3,5 bajtu (3,5 x 11bitov). Budem uvažovať s prestávkou o dĺžke štyroch bajtov.

Ak budem načítavať dvadsať 16bitových čísel, potom sa dostanem na maximálny prenosový tok
1745/ ((8 + 4) + (5 + 40 + 4)) = 1745/ 61 = 28,6 správ za sekundu.

To znamená, že teoretický čas odozvy pri požiadavke na 20 čísel je samotným prenosom údajov pri 19200Bd obmedzený na 35ms.

To znamená, že z dôvodu protokolu a komunikačnej rýchlosti neexistuje dôvod, prečo by požadované údaje nemali prísť do 35ms.

Ak prídu neskôr, potom je to už vec samotného zariadenia, ktoré potrebuje viac času na prípravu odpovede. Tam sa môže jednať o časy medzi 1ms a až niekoľko sekúnd.
Ak je odpoveď systému do 1sekundy pri prenose 20 čísel, tam už žiadne zvyšovanie prenosovej rýchlosti nad 19200Bd nemá ako zmysluplne pomôcť.

Osobne by som na tento prenos obdobných požiadaviek použil rozhranie RS485.

[redcrown]

budu zapínat XTM ze secondsol. Co je potřeba udělat za reset. Vybrat reset z menu, nebo je potřeba i Installer reset 1287? Rád bych, aby tam nezůstalo žádné nastavení z předchozí instalace.
díky

[milhaus]

Ano , je dobré provést reset 1287.

[DanoP]

Predpokladam ze nemas installer heslo, takze cez RCC to nepojde, ale ide to cez XCom232i co byva pribalene k menicu zo secondsol. Treba si stiahnut zo studeru technicku specifikaciu k seriovemu protokolu a v ramci nej je aj command line utilita scom.exe (pre windowsy) a pomocou nej to ide. Tu je priklad, ked XCom232i je pripojene na port COM4:

scom.exe --port=COM4 --verbose=3 write_property src_addr=1 dst_addr=101 object_type=2 object_id=1287 property_id=5 format=INT32 value=1

Moze sa stat za na prve odoslanie to nepojde, tak treba zopakovat. Default je menic a XCom nakonfigurovane tak, ze ak do 1 minuty nepride dalsi prikaz tak sa resetne spojenie XCom - pocitac, vtedy dalsi prikaz neprejde, ale zopakovany uz ano. To ze reset bol aktivovany bude aj pocut - v ramci resetu sa preklikaju rele a atd...

[redcrown]

No nějaké installer heslo mám, ale jestli funguje zatím nevím. Jak jste to dělali vy ostatní?

[marko250]

jen info: 460081
user: 943274
expert: 426468

[Lui]

Zdravím.
Mám takú hlúpu,ale fakt hlúpu otázku:
V parametroch nemožem prepísať ani jednu hodnotu,na mnou požadovanú.
Konkrétne prah podpetia potrebujem znížiť na nejakých 39V ale nedovolí mi to ani o jednu desatinu znížiť voči povodnému nastaveniu (tuším je tam 42,6V) nieto ešte o cca 3 volty
Už som prehodil aj parameter basic na expert,ale ani tak to nedovolí prepísať.

Nevie mi náhodou niekto povedať v čom može byť zádrhel? už sa s tým babrem od rána,a došly mi nápady

[DanoP]

Ktory parameter presne myslis, napatie naprazdno {1108} alebo pri zatazi {1109}?

To pri zatazi nemoze byt vyssie ako to naprazdno. Prosim pouzivaj cisla parametrov, tie preklady nazvov parametrov su casto zmatocne, cislo je jasne.

[dano]

Nemozes prepisat ani jednu polozku, alebo ti nefunguje iba ta jedna, teda znizenie tej jednej polozky ? Kamarat ma Studer a mal presne tento problem, ze mu to neslo viac znizit napatie baterie, nakoniec som zistil, ze to bolo blokovane nejakou inou hodnotou, ale kedze menu nepoznam, teraz ti nepoviem akou.