Plky o JMRI

[Brejla]

Co by na tuto zapeklitou situaci poradil odborník Brejla?

Souhlasí s tvou do nekonečna opakovanou radou. Poslat to někam hodně hluboko a použít něco fungující

[belgarat]

Od Brejly to beru jako doporuceni jak byt efektivni. Znovu opakuji, ze kratkodobe bohuzel potrebuji dosahnout "ovladatelneho kolejiste" bez Freiwaldovych nakladu propaleny cas beru jako studijni. Idiotske GUI mne sice irituje, ale nakonec "nejak" funguje, a koncoveho uzivatele (decko v krouzku) od toho odstinim - s chybama je to horsi.

Zatimco kdyz uz se tu hovori o podpasovkach, neustale @sidlovy poukazy "kdyz se ti nelibi, ze software ma bugy, nema logiku, pouzij TC" spis vyzniva jako "zavri usta, to ze JMRI ve skutecnosti moc nefunguje nemusime rikat moc nahlas".

Mam duvody proc se pokusit JMRI nasadit aspon v omezene mire; pokud vyctem toho, na co narazi "bezny jezdic" odradi nejake potencialni obeti tohoto "produkcniho software", tak je tenhle PLK-blog prospesny.

Ne, nemyslim si ze JMRI je - pro bezneho uzivatele - vhodne, vyjma MOZNA zalohovani nastaveni CV (DecoderPro). Ano, je to antireklama - pokud nekdo dalsi nastoupi do JMRI vlaku, napriklad pod dojmem prezentace na jmri.org, nebo jinde byl varovan. A ano, trochu si tim ulevim protoze mnozstvi chyb v BEZNEM pouziti je vetsi nez male.

[belgarat]

Tak podle nocniho testovani je chybkou zasazeny Logix (mam L-Route, povesenou na interni senzor - nastavi 4 vyhybky). Kdyz se uzivatel uklikne a namisto kliku provede na ikonku seznoru mysi dvojklik (coz tak akorat stihne po deaktivaci prvniho stisku), je uspesnost navozeni time-outu tak 80%.

U obycejnych (ne L-) cest problem nenastava, maji interni priznak, ze se provadeji, a dvojklik na ne neni ucinny. Pomoci Logixy se mi povedlo system dovest k chybe i kdyz jsem klikal zhruba co 2-3 sekundy, vypada to, ze kdyz ma clovek stesti, tak dva kliky "ne moc dlouho po sobe" uplne staci; proc, zatim nevim.

debug vypisy musim teprve projit, ale vypada to, ze prehazovana vyhybka se mylne sparuje Feedback broadcast, a svuj vlastni pak uz neoznaci jako "solicited" a tudiz se na odpoved ceka ...

Ten problem je dvojity: jednak pri vicenasobnem pouziti vyhybky (i prepnuti do stejneho smeru !) muze dojit k tomu, ze se z "inconsistent" -> rovne/odbocka prepne driv, ackoliv dalsi vyhybkovy prikaz jeste ani nebyl vyslan (ale uz je ve fronte). Tim se ztrati informace, ze vyhybka ocekava nejakou odpoved.

Druhy problem je (IMHO) v tom, ze vrstva co ma zpracovavat XPressNet timhle zpusobem prenasi zodpovednost na vyssi vrstvy: pro informaci, zda je prikaz potvrzen a ukoncen se vyuziva pomerne rozbitny stav vyssich vrstev (vyhybek), do ktereho navic jeste muze hrabat uzivatel (odeslat dalsi prikaz) ... Vypada to pak jako brecka "vsechno souvisi se vsim" kam obvykle zajde Zdeno namisto klasickeho 'rozdel a panuj', kde maji chyby jen omezenou moznost se sirit.

[belgarat]

Update k "nahodnemu samovolnemu prepinani" v zobrazeni web/frame: opravdu se jedna o nejakou vnitrni chybu prekreslovani, nebo JMRI jako takoveho: behem provozu nebyla na XPressNet zadna komunikace, ale na chromebooku pripojenemu k webserveru se "samy prehazovaly" vyhybky. Centrala DR5000 je v tom, zda se, nevinne.

[sidlo]

Pro sidla: to je ukazkova vec, proc je muj vztah k JMRI tak "emotivni". Uzivatel musi studovat manual, ke kazde obrazovce zvlast. Ktera kombinace hodnot a prvku je povolen, ktera zakazana, a v jakem poradi je lze pouzit. A ani potom, bez znalosti detailniho prubehu akce obcas nema sanci. Pritom je "tak jednoduche" nevhodne kombinace ... proste nepovolit. Uzivatele navest. Tady zamrzlo JMRI nekdy v roce 1985, kdy bylo podobne chovani pomerne bezne.

Pro ty, co zajimaji detaily log:

Kód: Vybrat vše

19:55:49.417: [packet:52 0C 8C D2]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Zap.
19:55:49.538: [42 0C 35 7B]   Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 51 Stav: Výhybka vlevo; Výhybka: 52 Stav: Výhybka vlevo
19:55:49.545: [packet:52 0C 8D D3]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 1 Zap.
19:55:49.570: [42 0C 36 78]   Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 51 Stav: Výhybka vpravo; Výhybka: 52 Stav: Výhybka vlevo

2020-02-05 19:55:54,545 jmrix.AbstractMRTrafficController     WARN  - Timeout on reply to message: 52 0C 8D D3 consecutive timeouts = 0 in lenz.XNetPacketizer [lenz.XNetPacketizer Transmit thread]

19:55:54.553: [packet:52 0C 8A D4]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 50 (adresa základní 12, podadresa 1) přepnout výstup 0 Zap.
19:55:54.577: [42 0C 25 6B]   Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 49 Stav: Výhybka vlevo; Výhybka: 50 Stav: Výhybka vlevo
19:55:54.585: [packet:52 0C 8C D2]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Zap.
19:55:54.609: [42 0C 35 7B]   Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 51 Stav: Výhybka vlevo; Výhybka: 52 Stav: Výhybka vlevo

2020-02-05 19:55:59,585 jmrix.AbstractMRTrafficController     WARN  - Timeout on reply to message: 52 0C 8C D2 consecutive timeouts = 0 in lenz.XNetPacketizer [lenz.XNetPacketizer Transmit thread]

19:55:59.693: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:55:59.871: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:55:59.985: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:00.016: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.125: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:00.160: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.269: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:00.304: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.413: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:00.543: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.653: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:00.676: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.788: [packet:52 0C 82 DC]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 50 (adresa základní 12, podadresa 1) přepnout výstup 0 Vyp.
19:56:00.815: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:00.921: [packet:52 0C 82 DC]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 50 (adresa základní 12, podadresa 1) přepnout výstup 0 Vyp.
19:56:00.959: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:01.069: [packet:52 0C 82 DC]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 50 (adresa základní 12, podadresa 1) přepnout výstup 0 Vyp.
19:56:01.231: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:01.341: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:01.375: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:01.485: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:01.519: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu
19:56:01.629: [packet:52 0C 84 DA]   Požadavek na provoz dekodér příslušenství: Adresa výhybky 51 (adresa základní 12, podadresa 2) přepnout výstup 0 Vyp.
19:56:01.647: [01 04 05]   Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu


Je to "stabilni, produkcni verze 4.18", presto vidime nektere zajimavosti:

* 2x timeout. OIdpovedni zprava na udajne nepotvrzeny packet je v obou pripadech v monitoru jiz vypsana.
* 6x zopakovani vypnuti vystupu 51/0. Proc ? (ze by cekani na feedback - neco mirne divneho v nanox ?)
* 3x zopakovani vypnuti vystupu 50/0. Proc ?
Navic mam pocit, ze jak si s tim hraju, pocet vypinacich packetu se postupem casu zvetsuje; ale overovat se mi to nechce.

Pro sidla: opet adrenalin - funkce, ktera dela "divne veci", veci navic, veci v nahodnem poradi, hlasi timeouty ackoliv nema proc (a samozrejme pusobi prodlevy v "mezistavu" prestavovani) ... kazdemu z kolegu by to bylo aspon trochu podezrely a sel by po tom, hned pri pocatecni implementaci. Ale nasel jsem JMRI z roku 2015, a je to uplne stejny ... takze asi cajk. A celkem si myslim ze XPressnet je docela pouzivane rozhrani

Co to je za centrálu? Z příspěvku to není zřejmé.

[belgarat]

Je to pouha NanoX, ale urcitou roli zde hraje i GEN-LI, puvodne pouzity je samodomo a la DccKoleje, ale take GEN-LI z dilny DIGI-CZ. DR-5000 pouziva jiny zpusob potvrzovani, ale davam tak 80% sance tomu, ze ten zamotany kod nebude fungovat poradne ani pro ni.

Pricinu toho uzasneho chovani je znamy, a (pravdepodobne) stejny jako u Tveho problemu s navestidly; akorat ze zde uplne postaci 2 vyhybky na adresach po sobe jdoucich, nebo rychle vydane 2 prikazy pro tutez vyhybku.

Porad rikam ze je JMRI super operacni system. Vyhnout se tomu, nebo 'spravne oskriptovat' to jde

[belgarat]

Ona je to u XPressNet + GEN-LI trochu potiz:
kdyz se na vyhybce zavola rekneme

Kód: Vybrat vše

setCommandedState(Turnout.CLOSED);


tak (XPressnet) vyhybka hned prejde (interne) do stavu COMMANDSENT ... avsak (logicky) zprava do centraly se preda "az nekdy". Je mozne ze pred ni je treba odvysilat nejake dalsi, tak proste casem. Pokud do doby, nez JMRI skutecne odesle pozadavek a prijme relevantni potvrzeni od centraly dojde nejaky dalsi SW prikaz pro vyhybku ... tak ze znovu prejde do stavu COMMANDSENT ... vlastne neprejde, protoze uz tam je; informace o tom, ze je DALSI prikaz se proste ztrati (ve vystupni fronte vsak prikaz k odeslani je a casem odejde).

Typicky takovy ukaz muze nastat, kdyz se ovlada lokomotiva, protoze to se JMRI zive a opakovane zajima o stav lokomotivy jak jej zna centrala, aby mohlo spravne zobrazovat rychlost, smer, funkce. Takze posila spoustu dotazu, jinak to ani nejde. Nebo kdyz nekdo nedopatrenim, nebo netrpelivosti dvojklikne na "senzor" (uzivatelsky: tlacitko), ktere stavi cestu.

A tu mame jadro pudla: na ceste jsou 2 povely (nekde ve fronte v PC), ke kazdemu z nich se opravnene ceka na potvrzeni. Zda je packet Z CENTRALY potvrzeni ci "nevyzadana zmena" (proste nekdo precvakl neco na pultu) rozhoduje vyhybka.
A ta uz davno "nevi", ze odeslala 2 pozadavky, protoze je ve stavu "poslala jsem prikaz, cekam". Zane pocitadlo, mozna protoze "se s tim tak nema pracovat, precti si manual". Pri prvni takove odpovedi se vyhybka prejde zpet do stavu OFFSENT a nasledne IDLE (prikaz je radne vyrizen)... a protoze druhe potvrzeni uz nerozpozna jako ocekavane, tak nizsi vrstva ceka ... a ceka ... a ceka na ono potvrzeni. A servo prestavnik vrci... a vrci .... a vrci, protoze kdyz vyhybka nezjisti ze se jeji prikaz prijal, tak take neposle "vypnout vystup".

S XPressNetem je jeste vetsi sranda, protoze je "potvrzeni" ve forme zpravy o zmene 2 "feedbacku" pro 2 vyhybky a jednotlive vyhybky se snazi "vyzobnout" tu svou zmenu. Kod je ale bohuzel napsany tak, ze pokud se prehazuji nahodou OBE (tzn. DCC adresa 2*X a 2*X+1), tak to vypada ze "vyhraje" vzdy licha vyhybka - a to ackoliv "jeji" command se jeste stale ve skutecnosti flaka nekde v odesilaci fronte (ale ona sama je COMMANDSENT). A v dobre vire se ji nacte spatny stav z ohlasu cizi operace. Nanestesti, 2 vyhybky s cisly po sobe co se prehazuji spolecne je dost typicky pripad na zhlavi. Situace se ale sama spravi, protoze ten flakajici se prikaz se nakonec take provede. Ale moc korektni ten program neni.

Priznam se ze opravdu nerozumim tomu, jak nekoho muze vubec napadnout se na tyhle nekonzistence vybodnout "protoze to nakonec NAHODOU dobre dopadne".... a prsit se jak to skvele 20 let funguje. Vymlouvat ze to progrmauji vlackari a ne programatori je tak trochu jako zduvodnovat fazi na kostre tim, ze to prece nezapojoval elektrikar, ale programator.

S DR5000 to podle testu vypada lepe, ale v podstate jen omylem. DR5000 obratem odpovi ACK (coz zpracuje vzdy spravna vyhybka, nebot se paruje s iniciatorem odchoziho prikazu) a prechazi do predpokladaneho ciloveho stavu; nasledny feedback broadcast je shodny s predpokladanym stavem a tudiz se dalsi zmeny nedeji. Nicmene stale plati, ze vyhybka prejde do stavu OFFSENT a nasledne IDLE ackoliv je "ve fronte" dalsi pozadavek na vyhybku; do COMMANDSENT uz nikdy neprijde. Neprijde mi, ze to je korektne modelovane, ac to MOZNA za urcitych podminek a na urcitych centralach nahodou funguje.

Tak ... dalsi krok bude zrejme napsat nejaky unit test se simulatorem XPressNet (ne tim co je v JMRI jako XPressNet simuator - to je spatny vtip, ale skutecnym simulatorem, ktery odpovida na prikazy) kde se ta uzasna implementace dovede ke konfliktu. Vyvojovy tym JMRI totiz funguje podobne jako Zdeno; specifikace jazyka, knihoven, protokolu neni dulezita, "mne to funguje, tak tam zadna chyba prece nemuze byt".

[sidlo]

Jak jsi daleko s implementací TrainController™ Gold?

[belgarat]

mno ... zajimalo by mne jak implementace TrainControlleru pomuze tomu aby JMRI korektne fungovalo pro XpressNet/GEN-LI rozhrani. Nebo aby existovala relativne slusna "free" alternativa k nechutne predrazenemu sw. Mozna po 20 letech co (normalni) uzivatele s hruzou utikaji od uzasneho komunitniho projektu by to chtelo trochu zmenit strategii.

[sidlo]

Máš pravdu. Proto je v našich zemích JMRI tak rozšířen. Kdo chce použít nějaký sw pro řízení většího projektu brzy dojde k přesvědčení, že použitelná alternativa k JMRI není.

[HonzaM]

Co je míněno větším projektem? Pokud jde o cenu TrainControlleru, je o něco vyšsí než cena jedné ozvučené lokomotivy. Zaplatil jsem ji jednou před deseti lety, od té doby jsem koupil několik ozvučených lokomotiv a řadu vozů a souprav, výhybek, přestavníků, a v celkové částce kterou jsem do kolejiště a vlaků vložil je cena za TC nevýznamná. Srovnání obou sw je obtížné, asi nebude mnoho lidí kteří by měli praktické dlouhodobé zkušenosti s oběma softwary. Já řadu let používám TC k řízení domácího kolejiště a JMRI pro programování lokomotivních dekodérů, DecoderPro. Zkusil jsem PanelPro, ale jevil se mi jako méně “user friendly”, obtížně jsem se prokousávat k tomu co je v TC jednoduché. Zdá se mi, že výhodou JMRI je větší možnost aby si uživatel sw přizpůsobil, TC je v podstatě uzavřený systém. Automatický provoz je u TC poměrně jednoduše programovatelný, u JMRI je to sice možné, ale složitější na naprogramování, na druhé straně je jednodušší například naprogramování úplné rychlostní návěstní soustavy ČD/ČSD. U TC to sice možné je, ale je potřeba dost přemýšlet jak to udělat a je nutné doplnění pro řízení návěstidel třeba ND4.

[HonzaM]

Máš pravdu. Proto je v našich zemích JMRI tak rozšířen. Kdo chce použít nějaký sw pro řízení většího projektu brzy dojde k přesvědčení, že použitelná alternativa k JMRI není.

Stálo by za úvahu udělat tady anketu kdo používá k řízení kolejiště JMRI, kdo TrainController a kdo RocRail, případně třeba kdo iTrain. Mezi uživatele JMRI nezapočítávat ty, kdo v JMRI používají jen DecoderPro! Anketa by měla vyjadřovat dnešní stav, ten se mohl změnit ve prospěch JMRI díky práci Petra Šídla, který hodně udělal svou činností pro překlady softwaru a české návody.

[belgarat]

1/ JMRI je sada nastroju; jeden z nich je DecoderPro, ktery ma se zbytkem JMRI spolecne JEN vzhled casti hlavniho menu, a vrstvu pro komunikaci s centralami. Neznam adekvatni byt placenou alternativu k DecoderPro; extremne cenna je databaze definici dekoderu, ktera CV dava 'lidsky vyznam'. Do urcite miry se JMRI pri rizeni provozu dokaze ale ridit kalibracnimi daty lokomotivy ukladanymi do "rosteru".

Odvozovat z popularity DecoderPro to, ze JMRI jako celek je super je dost zavadejici (ale je to cast retoriky vyvojoveho tymu), protoze zatimco DecoderPro konkurenci moc nema, "ridici" casti JMRI jsou - z uzivatelskeho pohledu - sracka a (placene) alternativy maji.

Takze pokud chcete delat anketu, radim zvlast sledovat DecoderPro a zvlast zbytek JMRI; jedna se o temer nezavisle aplikace.

2/ JMRI pro rizeni ma nekolik potizi. Jedna z nich je spatna integrace nastroju. Pri svych (kratkych) experimentech jsem musel napriklad bloky definovat asi 3x (Bloky, OBloky, Sections a "neco podobneho" ve Warrants).Duvod ? Asi to, ze kazdy kus psal nekdo jiny - a samozrejme nejlip a po svem.

Vezmeme Section, ktera je aspon trochu jina. Mame nakresleno kolejove schema v Layout Editoru, prirazene bloky jednotlivym usekum a vyhybkam. Presto musim vytvorit Section, a opet rucne definovat "okolni" bloky a smer, kterym se do nich jede (vpred, vzad). Pritom JMRI pro TYPICKY pripad jiz informace ma v Layout Editoru. Jenze - existuji i okrajove pripady, no a proto "nema smysl" v typickem pripade vyjit uzivateli vstric a na jeden klik v Layoutu "Vytvor pro tuhle caru Section" ji udelat. Samozrejme, konzistence mezi Section, Layoutem, Bloky a OBloky se nijak nekontroluje - kdyz neco zmenite, musite si sami dohledat v ostatnich nastrojich co a jak se musi opravit.

Dalsi z potizi je nesmyslna koncepce vychazejici z tvrzeni, ze ovladani JMRI ma simulovat rizeni tovarny, rizeni vyroby jak je provadene "ve skutecnosti". Simulovat "skutecny svet" maji (mozna) ale az "vyrobky" JMRI pro koncoveho uzivatele - dispecera/masinfiru/hradlare - panely, ovladaci prvky, indikatory. Ne nutne ovladani _vystavby_ panelu; v tom je rozdil. Pomijim zcela nezanedbatelnou cast uzivatelu, kteri kaslou na vernou releovku, a chteji jen "automatizovat jezdeni".

Tim padem i "bezne" funkce jako Otevrit, Ulozit, Zavrit okno funguji zcela jinak nez jak je PC uzivatel zvykly (Otevrit ve skutecnosti pridava panely, vyhybky, ... na spolecnuo hromadu; Ulozit ulozi celou hromadu do jedineho souboru nezavisle na tom ve kterem souboru puvodne prvek byl. Zcela se tak zlikviduje moznost oddelit casti definic do samostatnych souboru). Prikladu, kde JMRI koncepce, ktere se bezne pouzivaji v standardnich "kancelarskych" aplikacich implementuje zcela odlisne je mnoho. napriklad zavreni okna, ktere VSUDE funguje stylem "nechci to videt, schovej to" se uzivatele prekvapive zepta, zda chce zavirana data rovnou smazat.

Zde je take videt nekoncepnost celeho software: zatimco otevreni souboru panelu zpusobi pridani prvku (vyhybky, navestidla, cesty) a otevreni okna, zavreni a 'smazani' sice smaze panel, nikoliv vsak prislusne vyhybky, navestidla, ... Okno tak nelze chapat jako samostatny dokument (zavru / smazu - jako bych to nikdy neotevrel) ani jako pohled (zavru - zmizi, data zustavaji). Jako bonus, pokud si otevrete "starsi panel", jeho definice vyhybek (napr. nazvy, timeouty) prepisi ty jiz otevrene. Bez varovani
Jasne ze udelat to "ciste" tak, aby se funkce logicky doplnovaly, jde - jen to da podstatne vic prace, a kdo by se s tim matlal, kdyz "to tak staci".

Samostatna kapitola jsou legracni varovani "Nezapomente si ulozit data", ktera se zobrazi ve chvili zavreni programu (zavreni hlavniho okna). Ne "nemate ulozena data, chcete je ulozit ?". Vzapeti totiz JMRI skonci a vy o vase nastaveni prijdete -- ale vite, ze az je PRISTE znovu nastavite, musite je ulozit HNED.

Pro zanedbatelnou cast uzivatelu je takova "simulace ridiciho pultu tovarny" mozna pritazliva, nebo pripomina nejake pracovni prostredi, na ktere jsou zvykli; realne vsak v prostredi PC natolik cizoroda, ze drtivou vetsinu uzivatelu proste odradi - at uz od JMRI, nebo od rizeni pomoci PC obecne. Pohled vyvojoveho tymu je neuveritelne pokriveny neznalosti ani zakladnich "pravidel", pro uzivatelska rozhrani, ktera pouzivaji softwary pocinaje Wordem, a konce takovymi vecmi jako je Eagle.

Update: to, ze nefunguje klavesove ovladani (enter, cancel) ve vsudypritomnych vyskakovacich oknech; ze nektera okna se uzavrou, nektera ne (ac vzhledove vypadaji stejne); ze nekde se nazvy / identifikatoru vybiraji, jinde musi vypisovat, jinde se vybiraji pretazenim z dalsiho vyskakovaciho okna .... hodne toho je radne zdokumentovano, ale ovladani je natolik nesourode, ze je nutne se naucit co kde presne jak funguje.

Z uzivatelskeho pohledu je nezbytne dodrzet princip, "drzet se presne postupu v manualu" i kdyz ovladaci prvky umoznuji i jine, treba i zdanlive vhodnejsi kombinace. Ty, co nejsou vyslovne popsane totiz typicky totiz nefunguji, nebo vedou k chybovym stavum.

[belgarat]

@HonzaM: vysledky predchozi ankety, ktere rozdeluji DecoderPro od PanelPro&c jsou k videni zde:

https://docs.google.com/forms/d/e/1FAIp ... wanalytics - sekce "Software". Pri vzorku pouhych 73 odpovedi se ale neodvazim nic dovozovat z vysledku.

[HonzaM]

@HonzaM: vysledky predchozi ankety, ktere rozdeluji DecoderPro od PanelPro&c jsou k videni zde:

https://docs.google.com/forms/d/e/1FAIp ... wanalytics - sekce "Software". Pri vzorku pouhych 73 odpovedi se ale neodvazim nic dovozovat z vysledku.

Diky za odkaz. Jak je ta anketa stará? Nenašel jsem tam datum ani jak byli vybíráni účastníci, což mohlo výsledky ovlivnit. Nicméně je anketa zajímavá a přínosná.