Plky o JMRI

[zdeno]

OT
fakt zajimave:
napriklad 1/4 uzivatelu pouuziva Loconet a pritom v seznamu central je velmi malo Loconet central.
Ze by se pouzivala Z21 na Loconet ?

[MiG]

@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á.

Nevím, jak je anketa přínosná, ale to je jen můj problém.
V každém případě jde o anketu, kterou vytvořil BohusP cca v září 2019 a je tady k ní i vlákno.

[HonzaM]

OT
fakt zajimave:
napriklad 1/4 uzivatelu pouuziva Loconet a pritom v seznamu central je velmi malo Loconet central.
Ze by se pouzivala Z21 na Loconet ?

Centrál s LocoNetem jsem v anketě napočítal sedm, to mi tak málo nepřipadá. DR5000 je hodně rozšířená. Ale například pro MGP žádnou centrálu nepotřebuješ.

[Dandy]

Tak když to tady tak čtu, tak nevím nevím jestli ty svoje návěstidla s JMRI zprovozním...

[belgarat]

Tak když to tady tak čtu, tak nevím nevím jestli ty svoje návěstidla s JMRI zprovozním...

Nenech se zviklat: domnivam se ze vetsina "prusvihu" se tyka vytvareni layoutu a automatizace. Provoz by mel byt uz jednodussi. Za zkousku to stoji, a prezijes-li muzes si na pocest pana Freiwalda koupit 2-3 lokomotivy.

Az na vyjimky ta vec jde se zatatymi zuby pouzivat -- deti v klubu temer nic nepoznaly (az teda na to ze se jim "samy menily" vyhybky - chyba webserveru). Jen se k tomu musi pristupovat tak, ze kdyz to najednou prestane fungovat a nepomuze ani restart, tak se proste neda nic delat ... neni to software ktery by sel kvalitou pomerit s cimkoliv jinym co provozuji (nebo jsem provozoval za poslednich 25 let) na pocitaci.

[sidlo]

Tak když to tady tak čtu, tak nevím nevím jestli ty svoje návěstidla s JMRI zprovozním...

Já věřím, že se to povede Toto vlákno je velmi zajímavé. Mám k němu pár poznámek.

Vlákno má dlouhou historii. Někde v předvláknové prehistorii se tu psalo, že ovládání z tabletu určitě ne, že mechanická tlačítka a přepínače jsou lepší. To je pravda, ale na zde zmiňovaném kolejišti není použit Zhlavík, MGP ani nic podobného.

Kolega zde dlouhou odhaluje nedostatky JMRI. Od několika kolegů zde dostal opakované doporučení přejít na něco jiného. A nabídka je široká, včetně SW zdarma. V rychlosti mě napadá TrainController, modelJOP, iTrain, Koploper, RocRail, ... Přesto za tu dlouhou dobu nenašel odvahu použít něco jiného. Asi k tomu měl nějaký důvod.

Děláme s děckama modulovku již několik let. Asi dvakrát do roka vystavujeme. Na provozu při veřejné produkci se podílí jenom děcka v počtu asi 10 a věkovém rozmezí 5 - 16 let (ti nejmenší ještě neumí číst). Ovládání a organizace provozu musí být natolik jednoduchá a spolehlivá, aby se ti kluci u toho nepobili a zároveň návštěvník viděl nějaký zajímavý provoz. Dá se říct, že život kroužku je dán cyklem od výstavy k výstavě. A teď to nejdůležitější. Na každou výstavu si stanovujeme nějaké cíle. A na každé výstavě řešíme nějaké nové problémy. Všechny problémy co jsem řešil byly vždy mimo JMRI. A některé problémy které jsem vyřešil byly právě s pomocí JMRI.

A teď si to nějak přeber.

[Dandy]

Aha, dostal jsem tip, aby jsem si tohle vlákno přečetl. Ale raději by jsem byl jako čmelák... neřekli mu, že neumí létat . Petře díky za objasnění, ale hlavně díky za návody a podporu. Jako určitě jsem byl rozhodnutý to zkusit, už jsem si něco zkoušel a zatím je to v oblasti mých očekávání.

[MiG]

Ale raději by jsem byl jako čmelák... neřekli mu, že neumí létat .

Ale v tomto vlákně se nic o nemožnosti létat nepíše...

[belgarat]

Kolega ma velice jednoduchy "problem". A uz jsem to rikal mnohokrat.

Je mu jasne, ze pivodnim planum a pozadavkum na automatizaci se blizi TC Gold (bez moznosti prirazovat do promennych = 9Gold zbyva makra rozkopirovavat; textove nejsou a tolika klikani pri udrzbe ... bude na zblazneni) a ma 2 kolejiste (doma v klubu), cimz se Freiwaldovo vypalne jeste nasobi. Rikam "blizi", protoze samozrejme moznosti maker, byt se skoky a promennymi, jsou vzdy omezene -- v tomhle smeru JMRI vede a povede bud stale nebo jeste velmi dlouho: co neni DA se dopsat.

Na druhou stranu je kolegovi jasne, ze nez plany (a hlavne fyzicka realizace kolejiste) dozraji, uplyne velmi mnoho casu behem ktereho stejne pujde spis o to "nejak jezdit" nez mit hyper-automat. A jaka verze TC bude za 4-5 let, a co bude umet - Freiwald vi. A do te doby bude MOZNA JMRI / RocRail pres vsechna omezeni stacit.

No a ten duvod neustaleho bouchani hlavou do zdi je dvoji: Je to typicka "editacne-ridici" aplikace Ia kdyz se podivame na rocrail nebo TC, vidime jak muze celkem prijatelne vypadat). Kdyz mi neco chybi, nebo nefunguje, vylepsit TC nelze. Na RocRail musim oprasit stare znalosti C/C++ a naucit se wxWindows (ktere jsem nikdy neumel). Na JMRI stacim - a co vic, protoze zhruba v prubehu 20 let s prestavkami delam Java/Swingova UI rozhrani, tak i dost tusim jak "se ma spravne" psat to ci ono aby fungovaly ty mile veci ktere tvori "pohodli" a v dusledku vyrazne zefektivnuji cinnost (ne nutne praci) a na ktere JMRI kasle.

Ze stejneho duvodu mne ten software fascinuje, protoze neco takoveho jsem za praxi jeste nevidel: V oblasti softwarovych komponent je projekt takovych "kvalit" a nekoncepci je po takove dobe totiz uz davno prevalcovan jinymi resenimi a zapomenut, protoze se proste vyskytne nekdo (tym, jednotlivec), ktery potrebuje funkcni reseni a nekteri ho daji k dispozici. Zde je ale dodavtelsky "trh" tak maly, a uzivatele (modelari) maji natolik odlisnou praxi nez dodavatele (programatori), ze k prevalcovani a procisteni nedoslo, a mozna ani nedojde.

Tak to zacalo. Bohuzel pozdeji se dostavilo poznani, ze pokus o "spraveni" je v podstate nesmysl. KDOKOLIV kdo se podiva na JMRI a na rocrail, train controller, archicad, KiCad - a ted vubec nehodnotim jake funkce ktery program ma - musi na prvni pohled videt ze s JMRI "je neco jinak". Je to prave konzistence a dodrzovani konvenci, co uzivatelum umoznuje "pohodlne" pracovat - JMRI nejen ze nedodrzuje konvence ani jednoho OS, co podporuje; mozna si panove mysli, ze jejich projekt je dost vyznamny na to, aby si zavedl vlastni konvence, ale to je jen iluze. Kazdy uzivatel cestou ke spusteni JMRI projde jednotky az desitky ukonu pouzivajicich zcela jine paradigma ovladani a zobrazovani; a pokud na PC dela i neco jineho nez jen ovlada kolejiste, je JMRI naprosto z jineho sveta. A to prosim zcela bezduvodne: neni nejmensiho duvodu, proc by nastroj na (priklad) TVORBU releovky mel vypadat jako releovka samotna (zeleznicari prominou) -- jak z minuleho stoleti. Ale JMRI je optimalizovane (zda se) prave na tu niku uzivatelu, co nic jineho neznaji nebo spis nechteji znat ... ovsem jak je videt z Sidlovych tutorialu, i tu releovku si musi uzivatel SAM dodelat.

Vyvojovy tym ma ale takovy zasadni nedostatek za prednost ... zije v bubline ze ktere nevidi, nebo nechce videt, jake jsou moznosti a proto se dale prasi kod tak, neexistuji spolecne koncepce - kazde okno se ovlada jinak, kazdy nastroj funguje zcela nezavisle na ostatnich vyjma naprosteho zakladu (vyhybky, svetla, navestidla. Pro ty, co od JMRI neutekli to mozna vhodne je. Vetsina uz davno utekla jinam. V kodu lze vysledovat, ze behem let "vynalezli" spoustu technik, ktere se realne pouzivaji a pomahaji. Ale vynalezli je "po svem" ... takze uz v dobe zavedeni byly zastarale a zatimco vyvojove tymy je pilovaly smrem ke spolehlivosti, v JMRI zustaly jak za krale Klacka. Nejak to funguje, tak proc to menit. Pro ty co maji cas, najdete si "Technical Debt" googlem; wikipedia: https://en.wikipedia.org/wiki/Technical_debt ... JMRI se nachazi v mnoha vecech v levem dolnim kvadrantu: neznalost dusledku zvoleneho reseni - zpocatku prirozena, po letech a moznosti vyuzit zkusenosti jinych projektu ... nepochopitelna.

Ruku na srdce - kdoz vas 30 (?) kteri mate v ankete zaskrtnuto, ze provozujete JMRI PanelPro jej povazujete za dobry software ? Tim myslim nepada, dela to co ma, pracuje se v nem pohodlne ? Z tech par desitek hlasujicich vim uz ted o 3 "ne".

P.S.: totalni nasrani na "vyvojovy tym" nastalo ve chvili, kdy mi zacal jeden pomerne dulezity clen mimo mailing list "vyhrozovat" porusovanim (sveho) autorskeho prava k definicim dekoderu ... pritom jej licencoval podle GNU GPL a tudiz muzu "jeho dilo" zmenit, distribuovat (volny kod a bezuplatne) a - pokud s tim bude komunita souhlasit - dokonce placnout i do JMRI samotneho. Ale zcela to odpovida jinum intelektualnim vykonum v oblasti software.

[Dandy]

Ano je tak. Pamatuji si jak jsem tento program plny očekávání poprvé spustil. ... A hned zase vypnul. A tak to šlo furt dokola, vždy jsem se posunul o kousek a dál a pak to zas vypnul a nechtěl to nějaký čas vidět. Spíše nikdy. Ale stejně jsem se JMRI pořád vracel a vracím. Ale vždy mě dokáže překvapit nějakou zvláštností. Teď se tomu směji, ale ne vždy je to tak vtipné...

[Trixt]

Já mohu jen přidat postřehy z doby, kdy jsem se rozhodoval mezi JMRI a RocRail. Rozhodoval jsem se totiž v době, kdy Petr Šídlo ještě neprezentoval své podrobné návody, za něž mu patří dík. Informace na netu byly strohé. Tak jsem na to šel jednoduše. Řekl jsem si, že si dám na oba programy vždy pár hodin a uvidím kam se posunu. U JMRI jsem se nemohl hned z počátku rozhodnout, v čem mám vlastně plánek kreslit. Dvě prostředí sice mohou vypadat skvěle, ale ne pro člověka, který s tím začíná a neví, proč jsou dvě. Každé se navíc ovládá mírně odlišně. Prostě za vymezený čas jsem sotva pochopil některá pravidla pro kreslení plánu. U RocRail se mi za stejný čas podařilo přejet na jedné koleji z bloku do bloku. Rozhodnutí pro RocRail bylo tedy logické. Kdyby tenkrát byly k dispozici Petrovi postupy, asi bych skončil u JMRI, neb na RocRail v rámci české komunity moc návodů není. Po vydání cyklu postupů v JMRI Petrem jsem chvíli uvažoval o přechodu od RocRail k JMRI, ale když jsem si vzpomněl, jak jsem bojoval se základními principy ovládání a kolik již toho mám v RocRail nadefinováno, odhodlání mně opustilo. A tak pořád ovládám kolejiště v RocRail.

[belgarat]

Tak jsem si s tim trochu hral .... Simulator jsem doplnil tak, aby odpovidal jako GEN-LI

Kód: Vybrat vše

    @Test
    public void testSwitchTurnout() throws Exception {
        XNetTurnout t2 = new XNetTurnout("XT", 22, lnis);

        t.setCommandedState(Turnout.CLOSED);
        t2.setCommandedState(Turnout.THROWN);
        t.setCommandedState(Turnout.THROWN);
       
        System.err.println("All commands sent");
        Thread.currentThread().sleep(10000);
    }


ten sleep() je tam humpolacky ... musi ale byt (nebo neco podobneho), aby test neskoncil a simulator se neshodil - aby prikazy mely sanci dobehnout, zpracovavaji se v jinych vlaknech. Takovahle jednoducha sekvence sama o sobe dokaze vyvolat "timeout". Tzn. JMRI bude 5 vterin cekat, nez zacne posilat "output off" a mezi tim budou vesele vrcet prestavniky / serva.

A je jedno jestli v testu v Jave, nebo kdyz se pokusi o neco takoveho skript. Abych predesel namitkam, ze "se prece nedela" to, aby se vyhybka nastavila hned tam a hned zpatky ... mohou to byt 2 skripty, ktere reaguji na nejakou podminku; ja na to (omylem) narazil pri dvojkliku nebo prepinani celych vlakovych cest.

<joke>
Vubec neni treba mast software ovladanim z dalsiho ovladace. On se zbori sam jakmile se nedela presne do puntiku to, a ve stejnem poradi, co je napsano v manualu...
</joke>

[JirkaJ]

Děkuji přispěvateli Belgarat.
Svými příspěvky mě přesvědčil JMRI vyzkoušet. Doposud jsem používal ROCRAIL.
Nemám rád SW, který nemá chyby. Každý má chyby, ale u některých SW se o nich nepíše.
Vybaven těmito postřehy a upozorněními na chyby, ale především návody od pana Šídla (děkuji), jsem JMRI zprovoznil.
A představte si ono funguje a zatím bez chyb.
Objevil jsem skripty, pomocí kterých dělám vše (PYTHON používám i jinde a tím pádem znám).
Hodně věcí nemusím hledat, jak se zaklikají, napíšu skript.
Mám nyní DR5000 + 2 x Mutimaus a k ovládání z mobilu používám aplikaci Z21 připojenou k centrále. Tím pádem Web JMRI zatím nepotřebuji.
S JMRI zatím plná spokojenost.

[belgarat]

@JirkaJ: super
rikal jsem ze JMRI je docela dobry operacni system (pro python ) - diky za potvrzeni. Delas si automatizaci - reakce na udalosti z layoutu ?

[belgarat]

Tak ... pohadka uterni noci o vyhybkach, JMRI a XpressNetu.

Takove vyhybka. Ma stavy nejen 'rovne' (closed) a 'odbocka' (thrown), ale i 'inconsistent', 'unknown' ... to je vyborny napad, protoze co s vyhybkou kdyz ji vydate prikaz, a ona jej jeste neposle do centraly, nebo centrala jej jeste neprijme. Super; tady by se mohl TC mozna ucit i kdyz interne to ma mozna take. JMRI ale umi signalizovat i vyhybku v 'podivnem stavu', pouzivame-li feedback 2 senzory.

Navenek tedy vyhybka prechazi mezi stavy UNKNOWN -> CLOSED -> (pozadavek na prepnuti) -> INCONSISTENT -> (odezva z kolejiste nebo potvrzeni) -> THROWN. Logicke, prijemne na pouzivani.

Interne je to trochu slozitejsi. Zatimco pro skript (nebo kliknuti) v JMRI legrace konci vyvolanim setCommandedState, klidne i nekolikrat za sebou sem-tam (to je uplne korektni !), interne se musi (protokol XPressNet)
- pozadavek poslat do centraly
- pockat si na potvrzeni
- poslat pozadavek na vypnuti vyhybky, idealne PRED jakymkoliv dalsim pozadavkem na prehozeni teto (ale klidne prednostne i pred jakymkoliv jinym prehozenim)
- pockat si na potvrzeni

I tady funguje 'stavovy automat': IDLE -> STATUSREQUESTSENT -> IDLE -> COMMANDSENT -> OFFSENT -> IDLE. Takze teoreticky to vypada dobre.

Posledni sekvence je dana specifikaci XPressNet-u a jeho USB / LAN rozhrani smerem k pocitaci. Pro pripad vyhybek by melo platit:

Kód: Vybrat vše

1/  #CMD -> ACK | FEEDBACK;
2/  [FEEDBACK]* ;
3/  #OFF -> ACK
4/  [FEEDBACK]* ;


# oznacuje zpravu poslanou z PC, * pak zadne nebo vice opakovani. Je dulezite uvedomit si, ze po odeslani CMD nemuze prijit nic jineho nez:
a. potvrzeni,
b. feedback o zmene, ktery je nasledkem CMD
c. feedback k necemu uplne jinemu
d. chyba (ale ta muze prijit po kazde zprave)
mezi jednotlivymi sekvencemi pozadavek-potvrzeni pak muze libovolne prichazet feedback. Dulezite je, ze nenastava situace
CMD -> FEEDBACK + ACK
Podle specifikace XPressnet totiz, pokud je "odpovedi" na prikaz broadcast, USB/LAN rozhrani ACK poslat _nema_. Protoze pak muzeme pripad
CMD -> ACK + FEEDBACK (dela DR5000)
prevest na proste potvrzeni prikazu, a nasledna (nevyzadanou) odezvu oznamujici zmenu.

Ovsem to predpoklada, ze se odpovedi musely vzdy spravne "naparuji" k prikazum.

takze praxe:

1/ Po vytvoreni vyhybka hned dotazuje svuj stav z kolejiste. Zajimave je, ze vyhybka zustane ve stavu STATUSREQUESTSENT ... az do prepnuti. V kodu to 'zrovna nevadi' (jsou zdvojene podminky); robustni to ale neni. Stejne tak zustane 'viset' pri explicitnim vyzadani stavu od centraly.

2/ kdyz prijde Feedback ve stavu COMMANDSENT, posle se vypnuti vystupu. Ovsem vypnuti se posle "za chvili" (30ms odlozi).
Ironii je, ze diky serii chybek v kodu se tech OFF prikazu vytvori vice; a zatimco ten prvni se odlozi (cituji) "aby nedoslo k prehlceni centraly", ty dalsi se poslou primo (v mem vypisu 1 odlozeny prikaz, 2 naprimo odvysilane). Vyborna prevence zahlceni centraly.

Druha zabavna vec je, ze tim 'odlozenim o 30ms' bez koordinace s dalsimi povely se muze stat, ze vyhybka nahodou prehozena tam-zpet ve skutecnosti posle do centraly tuto sekvenci:

Kód: Vybrat vše

1. vystup 0 ON
2. vystup 1 ON
3. vystup 0 OFF (odlozeny)
4. vystup 1 OFF (odlozeny)


tzn. formalne budou v urcity okamzik OBA vystupy "on"; to je asi super zejmena pro elmag prestavniky ... tak snad to chyti dekoder spravne.

No a treti zabavna vec, coz vidim i na beznem vypise komunikace XpressNet monitor je, ze ten "high priority" OFF prikaz, se ve skutecnosti vysle, az kdyz neni ve fronte ZADNA "normal priority" zprava:

10:15:00.518: [packet:52 03 88 D9] Požadavek na provoz dekodér příslušenství: Adresa výhybky 13 (adresa základní 3, podadresa 0) přepnout výstup 0 Zap.
10:15:00.524: [42 03 25 64] Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 13 Stav: Výhybka vlevo; Výhybka: 14 Stav: Výhybka vlevo
10:15:00.543: [packet:52 04 8E D8] Požadavek na provoz dekodér příslušenství: Adresa výhybky 20 (adresa základní 4, podadresa 3) přepnout výstup 0 Zap.
10:15:00.567: [42 04 35 73] Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 19 Stav: Výhybka vlevo; Výhybka: 20 Stav: Výhybka vlevo
10:15:00.587: [packet:52 05 8A DD] Požadavek na provoz dekodér příslušenství: Adresa výhybky 22 (adresa základní 5, podadresa 1) přepnout výstup 0 Zap.
10:15:00.615: [42 05 25 62] Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 21 Stav: Výhybka vlevo; Výhybka: 22 Stav: Výhybka vlevo
10:15:00.643: [packet:52 05 8C DB] Požadavek na provoz dekodér příslušenství: Adresa výhybky 23 (adresa základní 5, podadresa 2) přepnout výstup 0 Zap.
10:15:00.663: [42 05 35 72] Odpověď zpětného ohlasu: Výhybka se zpětným ohlasem Výhybka: 23 Stav: Výhybka vlevo; Výhybka: 24 Stav: Výhybka vlevo
10:15:00.791: [packet:52 03 80 D1] Požadavek na provoz dekodér příslušenství: Adresa výhybky 13 (adresa základní 3, podadresa 0) přepnout výstup 0 Vyp.
10:15:00.824: [01 04 05] Příkaz úspěšně odeslán/Normální provoz obnoven po uplynutí časového limitu

Bohuzel kod tomu odpovida; fronta "vysoke priority" se zkouma az pri vyprazdneni bezne fronty odesilajiciho vlakna Z vypisu je take videt, ze v case 10:15:00.524 prisla odpoved (a byla naplanovana OFF zprava, a diky chybam viz vyse vyslany primo dalsi bez zdrzeni), presto prvni OFF zprava odesla az 10:15:00.824, po nejakych 300ms - rozhodne po "normalni" zprave odeslane 10:15:00.643 (tzn. +119ms).

Tak ted je otazka, zda je (dokumentovany) zamer jeste aktualni, nebo ne, jenom nikdo nevyhodil 'stary' kod... K vlastnimu parovani zprav, ve kterem jsou chyby vedouci k timeoutu se dostanu asi v pristim dile pohadky o tom jak se pise spatny software.


P.S. Programatorsky povzdech. Vytvoreni vyhybky vyvola okamzite dotazovani po XPressNet sbernici na stav. Nejde vyhybka zkonstruovat, pak parametrizovat ... a pak 'aktivovat' se vsemi dusledky. Tim padem nejde udelat 'docasny objekt' k editaci v oknech atd ... No a samozrejme se na startu vygeneruje fura zprav a VYZADUJE se funkcni pripojeni ihned na startu aplikace, behem cteni konfiguraku; namisto, aby se kontrolovane "zapnulo" pripojeni k layoutu. To je pitomy napad, protoze jak vime konektory se pripojuji a odpojuji ... V konstruktoru se, proboha, vykonne akce prece neprovadeji...

P.P.S: ono to neni umanutost bazirovani na milisekundach a tak. Kdyz se skutecna implementace rozchazi s 'modelem v hlave' programatora (ne v MOJI hlave - viz pojmenovani v kodu, komentare), jedna se prakticky vzdy o chybu ktera se driv nebo pozdeji vymsti - protoze se s modelem pocita nekde jinde.
Kdyby nebylo onoho "odlozeni" (ktere stejne nefunguje), probehl by interni cyklus vyhybky commandsent - offsent - idle bez preruseni (s vyhradou, ze ten stav se ma zmenit az pri skutecnem vyslani zpravy). A prave tento stav zbytek kodu predpoklada, a proto v urcitych pripadech (dvojklik na tlacitko co aktivuje cestu) blbe funguje.