Plky o JMRI

[sidlo]

https://www.youtube.com/watch?v=QFrlOIGhSho&t=2m25s

[belgarat]

No sice uplne nechapu co tim basnik chtel rict ... jestli to, ze cteni "pokud se chybne cteni u mne neprojevi tak je to OK" a je jedno jestli to je nok, knedlik, race nebo dobry kod ... rekl bych ze kazdy sveho stesti strujcem. Prave takhle funguje 'vyvojovy tym': projde to testy, tak je to v poradku.

[sidlo]

Pokud si někdo myslel, že jedl knedlíky a teď zjistil že jsou to noky, tak to má nechat a jít někam jinam.

[belgarat]

Vzhledem k 'vnejsim okolnostem' je mi uplne fuk, jestli je to knedlik nebo nok ... nebo nudlova zavarka, snist se nakonec da vsechno. Ale at je to co je, mohlo by to byt dovarene a bez drcenyho skla.

[belgarat]

Tak ... kratka prace na layoutu v JMRI, tentokrat jsem si znamenal uzivatelske "hovadiny" nalezene po ceste:

https://github.com/JMRI/JMRI/issues/8015
https://github.com/JMRI/JMRI/issues/8016
https://github.com/JMRI/JMRI/issues/8017
https://github.com/JMRI/JMRI/issues/8018
https://github.com/JMRI/JMRI/issues/8019
https://github.com/JMRI/JMRI/issues/8020
https://github.com/JMRI/JMRI/issues/8021
https://github.com/JMRI/JMRI/issues/8022

Clovek by rekl, ze tabulka vyhybek se pouziva dost casto, takze je po 20 letech vyvoje "odladena".

Poznamka: v ceske lokalizaci je "Clear" prelozeno jako "Přejmenovat uživatelský název", jinak by mne asi ani nenapadlo na tu akci klikat

[belgarat]

Jo ! Chybka nalezena.

Kdybyste nahodou v JMRI pouzivali vice pripojeni (mam z historicko-testovacich duvodu), tak si dejte trochu pozor.

Pri odpojeni kolejiste JMRI nenastartuje dokud nezmenite typ pripojeni z realneho na simulator, nasleduje restart (spousta veci "se neumi" bez restartu, nebo zavreni a otevreni blize neurcenych oken). Za odmenu JMRI samo zmeni vychozi pripojeni pro ovladace lokomotiv ... na prvni pripojeni co ma definovane (aspon u mne). Takze kdyz se posleze ZNOVU pripoji kolejiste pomoci pripojeni c.2, kde bylo PUVODNE, muzete si mys na ovladaci usoupat, a ono nic. Pripojeni #1 bylo po celou dobu v simulatorovem rezimu, takze nevim proc se "ono" rozhodlo zmenit nastaven.

Ackoliv akce "XPressNet monitor" je pritomna v obou hlavnich menu moje pripojeni (kazde ma samostatne menu), tak u toho pripojeni #1 zobrazuje ve skutecnosti packety pripojeni #2 ... asi jsem moc zhyckany, ale pak se dost neda prijit na to, ze jdou prikazy do spatneho rozhrani :-/ ani pri vetsi snaze.

Srandovni je, ze treba okno pro defici "OBloku" se otevre tolikrat, kolikrat kliknete na prislusnou akci. Zavreni okna jej jenom schova, nezavre. Skoncil jsem s 8 okny ... a v kazdem byl jiny obsah

----

Update: jako slusne vychovany uzivatel jsem udelal report na Githubu, zaZIPoval konfiguraci, popsal scenar jak reprodukovat. Popsal pricinu.
Odpoved: chova se to spravne

[belgarat]

Aby se mi vyhybky na Layout panelu "hezky" kreslily, tzn. pri prehozeni do odbocky se viditelne prerusila cara koleje primo, chce to obcas zkontrolovat "v praxi". Zvlast pri tlustsich kolejich se obcas stane, ze segment koleje prakticky ihned navazuje a preruseni neni dostatecne nazorne - vyrazne. Takze se klikne na obrazek vyhybky - a ona se prekresli. Podobne hloupe je ono chovani, kdyz si definuji Route nebo LRoute, ktera ovlada serii vyhybek na zhlavi - nastavuje vlakovou cestu na konkretni kolej.

Ma to podstatnou vadu v 'offline' rezimu, kdy je kolejistem tzv simulator. Nevim jak u LocoNetu, ale u XPressNet vyhybky prejdou do stavu "neznamy" pripadne "nekonzistentni". To je samozrejme SPRAVNE, pro naivni programatory a technofundamentalisty - neni pripojene kolejiste, tak fakt neni stav znamy. Ale houby pomuze kreslici, ktery si chce zkontrolovat nazornost nebo spravnost. Holt se vyhybky s XPressNet simulatorem neprehazuji.

Zatim jedina sance jak plnohodnotne kreslit Layout a definovat prvky je tedy s pripojenou prikazovou stanici... Na 99% se jedna o zadouci a spravne chovani.

[belgarat]

Tak pokracuji definovanim internich senzoru (to jsou v "uzivatelskem jazyce" (castecne) tlacitka na panelu) ... nadefinoval jsem jich 6, a chci je pouzit v LRoutes - to jsou cesty, ktere nastavuji vyhybky, navestidla a senzory (v uzivatelskem jazyce "stav tlacitka"). No - at jsem koukal jak jsem koukal, nove senzory jsem v seznamu "Actions (output)" nenasel, abych tem konfliktnim "shodil" stav na vypnuto.

Nastesti jsem pouceny uzivatel ! Kdyz nekde neco chybi nebo je stare, je treba vsechno ulozit a restartovat ! Ale nez mi doslo ze nedelam chybu, nekoukam spatne (treba je to jen jinak setridene) - dalsich ztracenych 5 minut. Ale asi je to tak spravne, to by tak bylo, aby vyberovy seznam reagoval na zmeny v "cizim" okne.

[belgarat]

Tak se dnes pri jezdeni s detmi dela takova zvlastni vec. Konfigurace:

- DR5000 centrala
- Roco MultiMaus ve funkci ovladace lokomotivy. Jedna.
- NTB s bezicim JMRI via XpressNet/LAN k DR5000
- Chromebook s browserem na http://jmri:12080/frame/Planek, zobrazujici layout kolejiste s ovladacimi prvky - 1 ks.

Detem se na chromebooku v nestrezenem okamziku "menilo postaveni vyhybek" ... vzdy za par vterin (pocitam s nejakym dalsim prekreslenim) se vsak zmenilo zpet - a na vlastni bulvy jsem videl, ze v tu dobu se chromebooku nikdo ani nedotkl. Kdyz uz se to stalo ponekolikate, koukal jsem zaroven na obrazovku NTB, kterou by (teoreticky) mel ten Web zrcadlit - on to dela i prakticky, kdyz se prepnu do edit rezimu, tak se i na webu ukaze mrizka, totez kdyz odscrolluji okno nebo jej zazoomuji na PC.

Ale na obrazovce NTB k zadnym zmenam nedochazelo, zobrazenu bylo stabilni. Nebyt toho, podezrivam DR5000, ze posle obcas nejakou "blbost" v pseudoohlasu. Pro klid duse si jeste v klidu (= bez drobotiny) overim XpressNet monitorem, ze neprichazeji "divne" feedback broadcast zpravy...

Jo, aby nebyla mylka -- na notebooku do layoutu take nikdo neklikal.

[belgarat]

Puvodne jsem mel o prikladu viewtopic.php?f=26&t=8153&start=210#p268027 napsany saaaaahodlouhy elaborat s postupem, ktery funguje v drtive vetsine pripadu, a nezhorsi funkci v tech patologickych. Ale doslo mi ze je vlastne k nicemu. Kdo se podiva na to cemu teoreticky priklad odpovida, tomu dojde, ze se potencialni konflikt tyka minimalniho poctu pripadu. A taky ze pokud SW neprijme dve zmeny tehoz vice-adresoveho navestidla "v kratke dobe po sobe", muze klidne vypocitat zpetne hodnotu navesti podle posledniho odposlechnuteho prikazu. Ve zbytku (= rychle po sobe) je slusnost aspon vyhlasit chybu, nebo stav "nekonzistence".

Ale pokud panuje skalopevna vira, ze kvuli 5% (sic !) potencialne zmatecnych pripadu radeji zvolime 100% nefuncknost (nekonzistenci s kolejistem), a ze je to tak pro uzivatele dobre - nema smysl osoupavat klavesnici. Kazdopadne, "defekt je autorsky zamer" zde plati stejne jako s mnohym dalsim v JMRI.

Edit: Train Controller zjevne v 'nepatologickem' (typickem) pripade funguje bez potizi, a k 4znakemu navestidlu "dopocita" stav podle konfiguracni tabulky ... a rekl bych ze tu "patologickou" cast Freiwald vyhodnotil jako tak nepravdepodobnou, ze s ni uzivatele ani nechce obtezovat (vyzkouseno "nazivo" na kolejisti - TC + Roco MultiMaus)

[sidlo]

Ani nepočítám, kolikrát se již opakuji.
Navrhuji opustit patologický, technofundamentalistický, nestabilní, defektní, (další vlastnosti doplnit dle vlastního uvážení), ... a začít konečně naostro v provozu používat Train Controller který zjevně v typickém případě funguje bez potíží.

[Trixt]

Sidlo: Člověk si musí postěžovat, aby se z toho nezbláznil.

[belgarat]

A po mocte pisu, ze tyto PLKY poslouzi tem, kteri zvazuji JMRI, aby mohli zhodnotit zda pres vsechno co v tomto tematu je, investovali svuj cas. Ve Tvych navodech se nepise nic o tom, ze JMRI selhava, ma chyby, spatne vyhodnocuje stavy, pada, dela nahdone chyby.

Pisu, na co jsem narazil, co stoji cas a nervy - a kazdy si udela obrazek o tom zda uz je to dost, aby zaplatil Freiwaldovi, nebo pouzil napriklad RocRail.

Jinak: to, ze se na zjevnou chybu odpovida "kdyz to nechces pouzivat, jdi jinam" je pro JMRI komunitu typicke. I proto ten sw vypada, jak vypada. JMRI je jedna velka prehlidka promarnenych prilezitosti, kde by se malym usilim dosahlo velkeho efektu. Ale cele to stoji na hlinenych nohou a naprosto spatnych "architektonickych" rozhodnutich. Ve SVE DOBE mozna nebyla az tak spatna, ale mezi lety 1998 a 2020 udelal svet ponekud pokrok, ktery JMRI ignorovalo protoze "tady bylo driv".

[sidlo]

Informovat o možných problémech své kolegy je správná a záslužná věc.

Pokračovat na projektu, který stojí spoustu peněz a času, a to nejenom jedné osoby, ale celého týmu, za podmínek:

JMRI je jedna velka prehlidka promarnenych prilezitosti, kde by se malym usilim dosahlo velkeho efektu. Ale cele to stoji na hlinenych nohou a naprosto spatnych "architektonickych" rozhodnutich.

Je pro mě nelogické. Je to hazard s penězi a časem lidí, kteří jsou do projektu nějak zapojeni.

PS:

Ve SVE DOBE mozna nebyla az tak spatna, ale mezi lety 1998 a 2020 udelal svet ponekud pokrok, ktery JMRI ignorovalo protoze "tady bylo driv".

Train Controller je o několik let starší.

[belgarat]

JMRI je jedna velka prehlidka promarnenych prilezitosti, kde by se malym usilim dosahlo velkeho efektu. Ale cele to stoji na hlinenych nohou a naprosto spatnych "architektonickych" rozhodnutich.

Je pro mě nelogické. Je to hazard s penězi a časem lidí, kteří jsou do projektu nějak zapojeni.

To jak delat treba i radikalni zmeny se zachovanim zpetne datove a pripadne binarni kompatibility je uplne jine tema, a zcela mimo tve moznosti, sorry.

Ve SVE DOBE mozna nebyla az tak spatna, ale mezi lety 1998 a 2020 udelal svet ponekud pokrok, ktery JMRI ignorovalo protoze "tady bylo driv".

To jenom znamena, ze Freiwald je mnohem mnohem chytrejsi, nez "jen" nejaky obchodnik, ze ?