Komunikace Logo! 0BA7

[pezizka]

Prosil bych o radu. Už jsu toho fakt na prášky Provozuji 5ks Logo! 0BA7 na síti a řídím s tím kde co. Komunikují všechny mezi sebou a to systémem 1 - server pro 2,3,4,5, 2 - server pro 3,4,5 atd. Využívám markery pro přenos stavové informace. Přenáší se mezi nimi navzájem téměř všechny. A tady narážím na problém Někdy se změna stavu přenese prakticky okamžitě, jindy to trvá i 10s. Doslova podle nálady. Zajímavé, že u analogových hodnot tento problém není. Tak nevím jestli po tomto zařízení chci moc nebo já už fakt nevím co Byl bych moc vděčný za nějakou radu, prozatím jsem si poradil s barsjakým úskalím, ale s tímto už nevím co bych Díky.

[dracekvo]

V práci používáme S-300 a S-1500 ale na podobnej problém jsme nenarazili.
Používáš live bit?

[pezizka]

Díky, ale má to jeden háček Na mně se musí polopatě. Vše jsem se naučil sám systémem pokus omyl. Takže nevím o čem je řeč Šlo by to jednodušeji ?

[dracekvo]

live bit. Prostě jeden bit tiká třeba frekvencí 1hz. Tiká jím jak slave, tak master a pokud na jednom zařízení ten bit přestane tikat, tak se ví, že vypadla komunikace. Třeba by si tím odchytnul, proč ti v některých případech ta komunikace vypadává.
Na dospělých plc, používáme knihovny put a get, které se o to starají tak nějak samy a mají i výstup pro poruchu. Jaké možnosti má logo netuším.

[pezizka]

Díky za osvětlení, patrně jsem pochopil. Toto přímo ale Logo nezná, něco obdobného ale taky používám pro ověření spojení. Dospělejší PLC se fakt učit nemíním, vyjdu s tím co mám a basta Získal jsem kontakt na technickou podporu Siemens, a velmi ochotný pán prozradil tajemství mého problému Bohužel mne to moc nepotěšilo, ale sedí to k mým zkušenostem a k tomu co jsem stihl vyzkoušet a to, že kladu na toto zařízení až tak vysoké nároky, že přestává stíhat Budu muset zjednodušit komunikaci a vzdát se některých nepodstatných položek. Naštěstí v tomto směru toho mohu podniknout docela dost. Každopádně díky

[dracekvo]

Na začátku si psal, že si předáváš téměř všechny merkry. Nad tím bych se zmyslel, zda je to opravdu potřeba.
Nevím co tím vše řídíš, ale třeba to nepotřebuješ přenášet neustále a stačilo by si to poslat jednou za nějakou časovou jednotku. Prostě té komunikaci odlehčit.
Opět nevím jestli to má logo, ale velké plc mají chybový registr, kde je výpis chyb (správně by měl být prázdný), dále se pak dá zjistit obsazení paměťí a průměrná/maximální délka smyčky programu. Z toho se pak dá taky odvodit jak si na tom se zátěží.
Případně tam můžeš mít nějaké jiné školácké chyby, kdy zbytečně vytěžuješ procesor.
Ona na to nejlepší škola byly staré MCU s pár kB pamětí a pár bajty ram.. Ty člověka naučili co je to optimalizace

[gupa]

http://docs-europe.electrocomponents.co ... fa0ff5.pdf

kapitola 2.1 a dále, i tom chybovým registru tam cosi je...

[pezizka]

Díky. Tu komunikaci není problém očesat. Mám tam opravdu hromadu zbytečností, myslím že to půjde bez větších omezení ořezat to tak na 25% Jen jsem netušil, že bude povoleno tolik možnosti přenosu, že ji to začne vlastně hlušit Optimalizace, no, první to dotáhnu do konce a potom mám naplánováno zaměřit se postupně na jednotlivé funkce a zjednodušit je při zachování funkčnosti, což je asi ono a mám tam pro toto taky dost prostoru
Gupo dík za odkaz, ale tady je maximální rozšiřitelnost základního přístroje, nikoliv komunikace mezi nimi. Všude je uváděno co to max. zvládne, ale důsledky už ne A navíc moje znalost jazyků končí u hovězích, uzených Ani ruštinu mi do lebky nenatloukli

[pezizka]

Už je to nějaký pátek co jsem se potýkal s výše zmíněným problémem. Dnes již vím v čem byl problém tak to chci hodit do placu, pokud někdo tyto zařízení využijete v takovém rozsahu jako já patrně narazíte do stejné zdi Dokud jsem provozoval na síti 3ks tyto problémy nebyly, přišly po rozšíření na 5 základních modulů.
Jako první jsem vyměnil switch TP link za průmyslový siemens, toto však k ničemu nevedlo, ale aspoň jsem získal jistotu, že odsud vítr nefouká. Po dalších laboracích s vedením, taženo dočasně naprosto mimo silové vedení a maximální možná ochrana před rušením apod. jsem došel k názoru, že problém je v samotných programech či komunikaci. Proto jsem stvořil testovací programy jež vytěžovaly komunikaci mezi moduly ještě víc, ale samy o sobě byly velmi jednoduché. Pokud to provozní podmínky dovolily, nahradil jsem pracovní programy testovacími a zkoušel.... Složitost programu neměla naprosto žádný vliv a problémy přetrvávaly Potom jsem začal postupně omezovat množství hodnot a stavů přenášených mezi moduly, ale ani toto k mému podivu nemělo prakticky žádný vliv a potíže stále přetrvávaly Jako polední varianta mi zbylo množství spojení mezi moduly. Jak jsem psal výše, chtěl jsem aby měl spojení každý s každým a zvolil systém 1 - server pro klienty 2,3,4,5, 2 - server pro klienty 3,4,5 atd. a to i přes to, že některé ze spojení nebyly využívány, jen nachystáno pro jakýkoliv myslitelný přenos. Začal jsem počet spojení omezovat a světe div se začaly postupně mizet problémy. Jak se mi ulevilo asi nemusím nikomu vysvětlovat. Minimalizoval jsem počet spojení a jen pro zajímavost je vytížil co se dalo a i tak se problém neobjevil. Postupně jsem optimalizoval počet spojení i za tu cenu, že některé moduly dělají prostředníka. Tímto se vše vyřešilo a přenos probíhá prakticky okamžitě, nezaznamenal jsem přenos se zpožděním větším jak 0,2s.
Třeba to někomu někdy pomůže, já jsem z toho byl celkem ale nakonec jsem to urápil já, nikoliv naopak