Vynucené přepočítávání

neutr · 10. 11. 2017 22:24:07

Záleží na tom, ale je možné postavit mnohem nižší práh. Určitě ale půjde o více milisekund. Netroufám si tvrdit že to bude 10, nebo 20 miliskund. Lze plno věcí přizpůsobit - od ořezání všech zbytečností až po zavedení úkolů na více strojů nebo odklonit na OpenCL (využít paralelizmus) ten by asi mohl pracovat v řádech nižších časů, ale chce to testy a zase testy.

neutr · 11. 11. 2017 17:10:08

Otestujte tohle : 2. verze přepočtu
Testoval jsem to na Windows a Ubuntu - pod Libre Office to chodí. Bohu žel Apache Open Office hází chybu. Pokud vím tak Vy máte Linux takže to nevadí. Ty dva balíky se už dost liší a pokud by to chtěl někdo testovat pod AOO upravím to. Hrál jsem si s opravou pro AOO docela dlouho. Když jsem to opravil nechodilo to pod LO. Takže jsem to vrátil a opravu nedotáhl.

Nyní se musí nejprve otestovat odezvy a průměrná ze 100 případů je nastavena jako minimum + 1 ms. Následuje vygenerování 10.000 hodnot pro výběr s inkrementací + 1ms. Poté vyskočí výzva na výběr hodnoty a teprve následně se znovu stiskne START. Teprve nyní je to v běžném provozu.
Měnit obnovovací interval lze přímo za provozu - bez toho aby se musela udělat dalčí operace. Pouze se vybere jiná hodnota v roletce. Ještě musím upozornit že hodnoty "viditelně" odpovídají přibližně asi od 500 ms a více. Změna sice proběhne prakticky okamžitě, ale mezi tím nežli se ustálí obnovování obrazovky tak to vypadá že je to jakoby mimo nastavenou relaci.
Fakticky se na okamžik dostane generátor mimo synchronizaci a tak se to někdy projeví jako nepravidelnost. Když totiž generátor nevidí na hodnotu jede opravdu na "nulu" což je nebezpečné a může se na chvíli "zakuckat", ale trvá to tak do vteřiny nežli si to "sedne". Když by to dělalo problém lze to odstranit ale myslím že to není velký nedostatek. Také ho nemusíte vůbec zpozorovat.

Je to skutečně podoba s generátorem impulzů a lze tak nastavovat všechny akce dané vzorcem, tedy také DDE (Dynamic Data Echange). Ovšem odezvy takových odkazů budou mnohem delší a já celkem věřím, že by to nemělo padat, ale to se pozná už při testu.
Chci upozornit, že systém není blokovaný proti chybám protože to jednak zpomaluje, ale hlavně systém si umí na chviličku (při testu) poradit aniž by zkolaboval. Takže proto nejsou ošetřeny ani okamžiky při změně zadání intervalu.

Upozorňuji důrazně, že pokud nevíte k čemu je to dobré tak si to otestujte ale raději neexperimentujte. U starších verzí (verze bez čísla a s číslem 1) celkem může dojít k zacyklení a k pádu systému nebo i stroje. Ani tato verze není úplně chráněna.

Není zabudováno protokolování, které by mohlo být vytvořeno. Autor dotazu to zřejmě potřebuje k napojení na technologi napojenou přes rozhraní RS 232, USB a nebo něco podobného. Půjde zřejmě o A/D převodníky (programy pod linuxem) s SW vazbou do Calcu.
Lze to ale použít například k načítání indexů pro burzy a podobné věci. Tam ale musíte testovat asi od konce k začátku.

Pokud tam bude nějaký nedostatek tak se na to podívám, ale jinak se tomu už nebudu věnovat pokud to takto bude autorovi dotazu stačit.

Jaroslav_1 · 11. 11. 2017 20:29:04

Testoval jsem a zjistil, že opravdu ve starších verzích LO jak v Linuxu (mám v Mintu LO 4.2.8), tak ve Windows 7 (měl jsem LO 4.2.x) makra generují chybu. Po aktualizaci (zatím ve W7) na nejnovější verzi vše funguje dle popisu.
Jen jedna zásadní věc. Potřebuji, aby se v jedné buňce měnila hodnota 0/1 dle nastavené periody. Tu bych použil jako zdroj "proměnného kmitočtu". To se zatím neděje. Je pravda, že v buňkách s funkcí SECOND(NOW()) se údaj už mění, nicméně s nejnižším a pevným rozlišením 1s.

Jaroslav_1 · 11. 11. 2017 23:08:52

Podařilo se mi aktualizovat i LO v Mintu. Pokud ještě mohu a bude to možné, poprosím o úpravu dle mého předchozího příspěvku.

neutr · 12. 11. 2017 06:28:41

Ano chápu tedy správně že nejde ani tak o obnovu dat typu podle stisknutí tlačítka F9 (přepočítat) ale opravdu o digitální impulz 0/1 kde se v jediné buňce podle nastavení přepíná jednička s nulou?

Pokud by šlo opravdu jen o to, aby se podle frekvence spínání objevovala jednička jde o mnohem jednodušší případ bez vzorců. Musím dodat, že také mnohem nižší minimální hodnota. Respektive bych se vůbec nezabýval testováním nejnižší hodnoty.
Rozsah by začínal 1 milisekundou a končil by na 10.000 milisekundách. Mašina by se takto neměla zahltit načítáním příkazů z kumulace která by nebyly reálně akceptovatelné (překrývaly by se tak že první příkaz ještě není proveden a až je nastaveno opakování).

Tak jednoduché se mi to ale nezdá. Spíš jsem nesprávně pochopil ten požadavek na buňku s výrazem 0/1. Domníval jsem se, že jde o signalizaci stavu :
1 = generátor v provozu,
0 = generátor mimo provoz.
Proto jsem navrhoval barvu podle které by se to poznalo snadno a pro lidské vnímání mnohem lépe. Vlastní technická obnova přepočtu mi připadala logická z pohledu akzualizace výstupu do Calcu.
Tedy jednosměrné načítání do Calcu - například z loggerů, respektive načítání analogů připojených přes A/D převodníky. Proto jsem zmiňoval "protokolování" které by bylo logické. Jinak to dává smysl jen pro "lidské smysly" - vnímání optické změny současným pozorováním obrazovky a připojené periferie která nějak zobrazuje, nebo alespoň bliká (přes nějaké provizorní řešení pomocí univerzální desky ap).

Současné provedení spočívá v triku který ani ve skutečnosti nic neobnovuje - jen nahrazuje rovnítko za rovnítko. Je to velmi rychlé, ale musí být zapnut automatický přepočet, takže nejde ani o přesnou náhradu za funkci "přepočítat" (F9) jak jste specifikoval.

POZNÁMKA SPÍŠ PRO ZÁJEMCE O PROGRAMOVÁNÍ :
Existuje přímé řešení funkce "přepočítat" - tedy makro které nařídí vlastní přepočet. Ale to jsem testoval proti uvedenému "triku" a "trik" byl rychlejší. Technicky jde o to že přímý přepočet vychází jen z Basicu. Není to tak dlouho - makro sem postnul uživatel "lp.". Měl jsem i verzi z internetu, ale verze od "lp." je zjednodušena, takže raději používám tuto když bych to potřeboval.

Já jsem původně používal nahraný dialog "Najít a nahradit" což je ale verze pomocí UNO které je pomalejší nežli speciálně navržený descriptor. Takže většinou jsem jen nahrál makro a ani rychlou verzi neupravoval (nehledal). Tu používám jenom když na rychlosti záleží. Nahrané UNO používám pro aktivaci vzorců které jsou napsané jako text. Lze tak naprogramovat změny vzorců ve formě programu a postupně například vyhodnocovat různé parametry ve sloupcích. Některé funkce vytvořené jako vzorce lze "naprogramovat" jen obtížně. Stačí to k pokrytí prakticky všech dynamických potřeb - tedy nejen přepsat klasický vzorec, ale za běhu vytvořit napoříklad rozsahy polí, kombinace dotazů a proměnných. Je to postup i mimo běžné možnosti Basicu ".formula", nebo "ArrayFormula".

Původně jsem pro tyto účely používal převod "z" a "do" RTF ale toto se dá aplikovat velmi složitě - jde spíš o manuální postup. Pak jsem našel trik s tím dialogem "Najít a nahradit" který stačí nahrát pro určitý úsek a vzorce v řádech až tisíců naráz aktivovat. Při tom jsem si uvědomil, že dochází také k přepočítání. Náhradou nahraného dialogu za desriptor se dá "přepočítat" (aktualizovat) vše v Calcu.
KONEC POZNÁMKY

Domnívám se správně, že potřebujete jak vstup "přepočtem" tak řízení pro výstup pomocí 1/0, nebo jde jenom o řízení pro IO piny? Tohle byste měl upřesnit. Může to zajímat mnoho lidí například v budoucnu. Proto také dělám poněkud irelevantní popisy a komentáře.

Jaroslav_1 · 12. 11. 2017 07:46:04

"Domnívám se správně, že potřebujete jak vstup "přepočtem" tak řízení pro výstup pomocí 1/0, nebo jde jenom o řízení pro IO piny?"
- ano, ideální by byly oba vstupy. Při čemž vstup "přepočtem" může mít (pokud budou vstupy dva) řádově delší periodu, než změny v buňce 1/0. Změny v buňce 1/0 jsem neuvažoval pro řízení výstupu ale pro simulaci hodinového signálu, který by dokázal iniciovat změny. Tedy jako zdroj události pro řízení makra. Nevěděl jsem, že tyto dva případy lze oddělit, jak píšete výše. Pro přepočet je tedy asi možné použít k tomu určené makro, o kterém píšete? A pro generování změn postup, který popisujete ve 2. a 3. odstavci?

neutr · 12. 11. 2017 08:20:59

Nemohu odpovědět jednoznačně.
- Lze oddělit jak impulz pro hodiny, tak interval pro čtení hodnot ale....
Všechny procesy se odehrávají v sérii takže pokud se oddělí oba procesy, půjde to za předpokladu celočíselné dělitelnosti - respektive nedělitelnosti aby se nepotkaly oba případy ve stejný okamžik. Pak by asi rozhodl stroj co udělá dříve.
Lze to tedy také sjednotit respektive nerozdělovat na vysílač a přijímač. Logicky by mělo dojít ke střídání 1:1 (vyslat signál hodin a načíst hodnoty výstupu). Tím se ale dostaneme k větší minimální hranici o zadání signálu hodin. Není to o moc a zřejmě by si s tím mašina poradila pokud nebude překrytí výrazné.

Je zde druhá stránka věci. Když terminál (v našem případě monitor) nestíhá, jednoduše vynechá obnovení a začne až když je původní obnova uskutečněna. Tento jev se projevuje zejména u těch výstupů cca do 0,5 sekundy. Větší intervaly už stíhá (ale jde o vše možné - rychlost spojení, frekvence monitoru, frekvence grafické karty ap.).
Pouze může dojít k rozházení vlivem přestavby časové konstanty ale to také rychle odezní. Takže na "oči" moc dát nemůžete. Tohle je zralé na protokol který se vytvoří v paměti a nakonec se vypíše nejlépe do externího souboru (report) txt, nebo csv.

To znamené úplně jiný přístup, vypnout zcela obnovování obrazovky, vypnout přepočítávání a vše zadávat jen do reportu. To znamená například standardní počet řádků a tedy konstantní dobu měření i když to lze udělat jako mnoho protokolů za sebou třeba na celý den.
Potom lze dotazem kontrolovat kdy už stroj stíhá zapsat report výstupu a kdy ještě nikoliv. Ale už to nebude vůbec nic k online sledování. Vše se dá následně zpracovat třeba jako graf, nebo tabulka a podobně.

Dalo by se postavit řešení testu a pak zobrazovat i tisknout, ale je to mnohem více operací a výpověď takového protokolu není nic moc vzhledem k účelu.

Jaroslav_1 · 12. 11. 2017 08:40:22

Označím-li si jako pomůcku volitelný interval pro vstup přepočtem x a interval přepočítávání y, lze realizovat:
-uživatelsky nastavitelný interval "x"
-volbu intervalu "y" jako násobek "x"
-přičtení konstanty "k", menší než nejnižší hodnota "x", k intervalu "y" a tím zajištění, že se procesy "nepotkají"?

Jaroslav_1 · 12. 11. 2017 08:42:46

Napsal jsem to špatně, myslel jsem intarval "x" jako interval změn 1/0.

neutr · 12. 11. 2017 08:56:58

Já rozumím. Asi bych to uměl definovat jako nejmenší společný dělitel a tomu se vyhýbat. Ten dělitel by byl násobek nějakého základu milisekund a když by měl nastat nastartuje se cyklus od prvního počítání.
Ale stále je zde problém s délkou odezvy. Impulz hodin zabere konstantně minimum - plácnu 1ms. Potom signál jde přes sběrnice stroje procesor a přes komunuikační linku která bývá násobně pomalejší nežli vše ostatní.
Následuje vnitřní proces obvodů mikroprocesoru (převodníku) a vyslání odezvy tou samou cestou zpět. Tohle nezávisle vyhodnocuje "obnova - přepočítávání". Takže tohle umí jen protokol. Zaznamená čas impulzu hodin a pak odezvu která buď je, nebo není. Když je "čitelná", máme časovou konstantu která se musí testovat tak aby nebyla na hraně. Teprve potom by šlo regulerně protokolovat a automaticky navyšovat čas hodin.
Technicky správně by to měl být opačný postup tedy shora dolů. Při zjištění, že komunikace nestíhá skončit. Také to ale znamená že vše musí proběhnout "bez očí" a pak testovat ještě obnovu obrazovky která i tak vše dodatečně zkreslí.

Jaroslav_1 · 12. 11. 2017 09:14:53

Já mohu jen konstatovat, že se smířím s nejnižším intervalem změn 1/0 v řádu desítek milisekund a nejnižším intervalem přepočítávání (i) o řád vyšším.

neutr · 12. 11. 2017 09:27:00

Celkem by asi pomohlo když byste mohl popsat co opravdu používáte. Podle mne máte napojený nějaký programátor přes USB a potřebujete simulovat krystal. To není tak jednoduché.
Viděl jsem někde na linuxu seriál o programování různých chipů a tam bývá i popis jak si co koupit, nebo ubastlit. Při tom procesor od procesoru používá specializované rozhraní které se programuje podle druhu pomocí C++, basic, assembler a myslím že i Java.
Takže přímo vstup do sešitu Calcu musí udělat nějaký softík pro Linux který buď převede signál sběrnic na text přímo a dá se načíst jako DDE, nebo to uloží v textovém souboru který se musí aktualizovat jako externí soubor.
Možností je celkem dost, ale možná by Vaše řešení zajímalo více lidí. Já jsem už na tyhle věci rezignoval ze zdravotních důvodů i když jsem původně také bastlil a mám doma plno věcí. Ale už mi neslouží tak dobře oči a neudržím hrot pájky na místě. Mám to sice doma ale čekám že snad vnuk jednou bude mít zájem :-)
pro OpenOffice, respektive asi také pro LO existují softy pro automatizaci a jeden (převodník RS 232) je k mání zdarma. Jinak je to placené, ale může existovat už mnoho jiných - nezajímám se už delší dobu :-)

Jaroslav_1 · 12. 11. 2017 09:39:01

Opravdu mi jde pouze o simulaci principu mikrokontroléru nebo počítače obecně. Chci si nasimulovat řadič, sběrnici, registry, paměti a výstupy. Aby to vše ožilo, potřebuji hodinový signál. Na hodinový signál pak chci navázat makra simulující vykonávání instrukcí.

neutr · 12. 11. 2017 09:41:24

K příspěvku #36 : Takže tomu mám rozumět tak že se postaví
krok 1 = impulz hodin (1) - problikne a do 10 ms je jednička viditelná,
krok 2 = následně obnova dat řekněme 100 ms
Tyto dva kroky opakovat za sebou - tedy například 110 miliskund v cyklu? Pak ale musíte upřesnit jestli s protokolem, nebo bez. S obnovou obrazovky je to horší - asi nic moc neuvidíte a bude se Vám zdát že to chvíli jde a pak zase chvíli ne.

Musíme si uvědomit, že největší čas sežere komunikace přes porty a proto bych doporučoval nejprve testovat halp und halp. Například 100 ms jednička a 100ms odezva (při vypnuté jedničce) nastavit čas větší - třeba 300 nebo i víc milisekund a stahovat dolů.
Teprve potom posouvat čas směrem dolů ale jen u jedničky. Tohle opravdu neumím odhadnout. Faktem je že když začneme někde na vysokých hodnotách najdeme nejprve to že nestíhá monitor. Následně zjistíme že neprošla odezva (na to musím upravit makro aby při opakování s tímto výsledkem počítalo a dělalo alespoň prozatímní zápis do sešitu.

PS : je celkem jedno že by šlo o simulaci bez reálného napojení. Princip se musí postavit na obnovu obrazovky a nakecat do komentáře že 150 ms = 1/1000 sec. Navíc když to bude chodit u Vás nemusí to chodit na jiném stroji amusíte udělat nějakou konstantu kterou člověk uvidí. Pochybuji, že byla vidět jednička na 1 ms. Z hlavy to nevím ale myslím že 1/36 sekundy už v mozku vytváří zdání pohybu. Možná je to už při mnohem menším děliteli.

Editoval neutr (12. 11. 2017 09:50:39)

Jaroslav_1 · 12. 11. 2017 10:07:14

Tak, jak tomu rozumím z Vašeho posledního příspěvku, odstavec první, by byla perioda změn 110ms s tím, že impuls pro změnu 1/0 by setrval v úrovni 1 po 10ms ale periodu by měl oněch 110ms?
Potřebuji, aby proběhlo - dle příkladu výše - 5 period s např. 10ms v úrovni 1 a 10ms v úrovni 0 (ale může být i jiný poměr) 10 změn signálu 1/0 na jedno přepočítávání.

neutr · 12. 11. 2017 10:37:28

Dobře to by šlo otestovat, jen si uvědomte, že 10 cyků znamená 10x1 + 10x0 = 200 ms. Pak 1x obnova dat řekněme 200 ms a pak opakovat? - takže cyklus 20 x 10 ms + 200 ms?

PS :
Asi by stačilo jednoduše zadat postup :
1(10ms) + 0(10ms) + načíst(200) + 1(10ms) + 0(10ms) + načíst(200)..............celkem "x" krát, nebo
1(10ms) + [0 = načíst(200ms)] + 1(10ms) + [0 = načíst(200ms)]....celkem "z" krát ap.

Editoval neutr (12. 11. 2017 10:45:40)

Jaroslav_1 · 12. 11. 2017 11:06:35

Obnova dat např. 200ms? To by asi nevadilo. Nelze mít procesy pro změnu 1/0 a obnovu dat spuštěné současně? Zatím by to - jak to chápu - znamenalo, že hodinový signál bude přerušován intervalem obnovy dat. Optimální by byl hodinový signál kontinuální (v rámci spuštění a zastavení prostřednictvím tlačítek).

neutr · 12. 11. 2017 11:33:11

Dobrá tak to může být, ale bude se spouštět obnova na nulu bez ohledu na cokoliv. Může to být i na jedničku. Ale potom jeden údaj pro dva různé stavy, nebo generovat řadu po 2ms aby to bylo dělitené dvěma?
Vždy se stane že musím dát příkaz například "zapni 1" - následně "zapni 0 + obnova", nebo
"zapni 1" - následně "zapni 0" + zapni obnova". Pak potřebuje obnova čas abych dostal start pro jedničku. Když zapnu nulu a hned následně obnovu bude mít obnova s nulou jiný reálný čas provedení nežli jednička.
Právě tohle je ta maličkost kde je zakopaný pes. Příkaz musí jít v sérii za sebou (1,0,obnova) nebo v jiném pořadí. Při tom víme že je problém s časem jak nastavit časy. Všechny časy stejné, nebo rozdělené jinak (podle součtu), a nebo rozpočítaný cyklus podle nejmenšího společného násobku.
Při tom lze garantovat jen tu jedničku a nulu. U aktualizace se to musí otestovat. Když to neotestujeme bude trvat obnova stejně podle svého. Pak se dočkáme známého X,Y a neznámého Z. Takže například X+Y = 20ms ale Z od 100 až do 150 ms. Ve skutečnosti pak nula bude trvat Y+Z ms.
_____________________________________________________
Test spočívá v tom, že se spouštějí procesy bez limitu x krát za sebou a je možné měřit čas mezi nimi. Takže dostaneme
1. [0(=1) + 2(=0) + 56(=obnova)]
2. [57(=1) + 59(=0) + 115(=obnova)]
3. [122(=1) + 132(=0) + 201(=obnova)]
..................
100. [6561(=1) + 6562(=0) + 6564(=obnova)]
--- sečtou se časy pro jedničky samostatně a pro nuly s obnovou také. Dostaneme nějaký průměr. Z toho vyjde například 1 = 1,5 ms dále 0 = 2,01 ms a obnova 61 ms.
Sepnutí na jednotku nikdo neuvidí - nejvýš probliknutí. Nulu uvidíme 63 ms a při tom se stane obnova. Existuje rozumné řešení nastavit časy tak aby 1 = obnova(zdánlivě při nule), nebo vytvořit 3 stavy NIC jako (NULL), (ONE), (ZERO)

Editoval neutr (12. 11. 2017 11:50:56)

Jaroslav_1 · 12. 11. 2017 12:20:40

Ano, s testem je možné se smířit. Děkuji za realizaci.

neutr · 12. 11. 2017 12:40:30

Podívám se na to ale po obědě jedu na návštěvu. Nevím kdy se vrátím. Nemělo by to trvat dlouho. Jenom byste měl upřesnit zda mám generovat možnosti výběru, nebo stačí jen průměr 1 = obnova(v nule), nebo 3 stavy.
Udělám testy a pak se podíváte jak to vypadá u Vás.

Jaroslav_1 · 12. 11. 2017 14:11:36

Zatím asi stačí průměr. Nevím, jak je náročná varianta se třemi stavy a zda by nabízela pro mne opravdu více možností. Nedokážu nyní posoudit.

neutr · 12. 11. 2017 20:45:54

Už na tom chvíli dělám, ale dnes nedodělám. Bude to během dopoledne. Dělám to na protokol se 3-mi hodnotami a vzorce ukážou průměr a maximum. Testoval jsem asi 5x za sebou a docela to vždy vyhodí jiné hodnoty. Test na protokol je rychlejší nežli před tím. Takže ve finále nechávám na uživatelském uvážení a manuálním výberu.
Problém je také v tom, že při nastavených měřených hodnotách opravdu nejsou vidět změny. Testoval jsem i obarvení a tučné písmo ale při 12-ti ms opravdu nic neuvidíte. Nastavil jsem i barvu jedničku jako žlutou a nulu jako modrou a viděl jsem jen flek se zeleným podkladem :-(
Je to celkem složitější a chce to asi testovat co vše bude spuštěno za procesy. Jsou tam vidět někdy i podstatné výkyvy v násobcích průměrné hodnoty. Docela mne zdržuje testování ale nechci to pustit špatně otestované. Pro viditelné simulace asi budete muset nastavovat mnohem větší násobky. Ale při simulacích by to mělo být jedno.
Při řízení skutečné periferie by to pomohlo, ale pak by to chtělo spouštět jako zavřený (hidden) soubor. Má obnovení přepočtu ale nemusí obnovovat obrazovku a šlo by to jistě ještě dolů.

Jaroslav_1 · 12. 11. 2017 20:57:35

Vše se asi odehrává v RAM počítače? Mám tím na mysli rychlé - řádově ms , desítky, stovky ms - zápisy a čtení. Na disk se asi ukládá jen konfigurace?

neutr · 13. 11. 2017 11:04:38

Tady je poslední verze - Generátor impulzů
Udělal jsem k tomu i nějaké nápovědy a podobné věci. Snad to bude k něčemu dobré. Už se k tomu nechci vracet. Myslím že to může někoho motivivat.

Jaroslav_1 · 13. 11. 2017 11:44:33

Skvělá práce. Ještě jednou děkuji za všechny, kterým to pomůže.

OpenOffice.cz - web věnovaný kancelářským balíkům OpenOffice.org

#26 10. 11. 2017 22:24:07

Re: Vynucené přepočítávání

#27 11. 11. 2017 17:10:08

Re: Vynucené přepočítávání

#28 11. 11. 2017 20:29:04

Re: Vynucené přepočítávání

#29 11. 11. 2017 23:08:52

Re: Vynucené přepočítávání

#30 12. 11. 2017 06:28:41

Re: Vynucené přepočítávání

#31 12. 11. 2017 07:46:04

Re: Vynucené přepočítávání

#32 12. 11. 2017 08:20:59

Re: Vynucené přepočítávání

#33 12. 11. 2017 08:40:22

Re: Vynucené přepočítávání

#34 12. 11. 2017 08:42:46

Re: Vynucené přepočítávání

#35 12. 11. 2017 08:56:58

Re: Vynucené přepočítávání

#36 12. 11. 2017 09:14:53

Re: Vynucené přepočítávání

#37 12. 11. 2017 09:27:00

Re: Vynucené přepočítávání

#38 12. 11. 2017 09:39:01

Re: Vynucené přepočítávání

#39 12. 11. 2017 09:41:24

Re: Vynucené přepočítávání

#40 12. 11. 2017 10:07:14

Re: Vynucené přepočítávání

#41 12. 11. 2017 10:37:28

Re: Vynucené přepočítávání

#42 12. 11. 2017 11:06:35

Re: Vynucené přepočítávání

#43 12. 11. 2017 11:33:11

Re: Vynucené přepočítávání

#44 12. 11. 2017 12:20:40

Re: Vynucené přepočítávání

#45 12. 11. 2017 12:40:30

Re: Vynucené přepočítávání

#46 12. 11. 2017 14:11:36

Re: Vynucené přepočítávání

#47 12. 11. 2017 20:45:54

Re: Vynucené přepočítávání

#48 12. 11. 2017 20:57:35

Re: Vynucené přepočítávání

#49 13. 11. 2017 11:04:38

Re: Vynucené přepočítávání

#50 13. 11. 2017 11:44:33

Re: Vynucené přepočítávání

Zápatí