Plky o JMRI

[belgarat]

Tak schvalne: mam tadyhle log z JMRI:

https://www.dropbox.com/s/nj18om2aviwe0 ... g.txt?dl=0 -- ladici log z konzole
https://www.dropbox.com/s/k4jeffie7oj0t ... t.txt?dl=0 -- zaznam xpressnet zprav

Tyto 2 jsou zachycene soucasne, jeden z terminalu, druhy z okna "XpressNet Monitor". At se snazim jak se snazim, na kazdy XPressNet pozadavek je v logu zaznamenana zachycena odpoved od centraly. Prehledneji jsem je vykousl zde (je to jen vyfiltrovane send+reply): https://www.dropbox.com/s/dynm9nsp9ysaa ... e.txt?dl=0

Podle mne na KAZDY pozadavek centrala odpovedela podle specifikace. Avsak JMRI loguje varovani o timeoutu - nepotvrzene zprave 52 05 8C DB. Avsak autor kodu pro XPressNet tvrdi, ze:
- timeout se reportuje JEN tehdy, kdyz nejaka zprava centrale neni (centralou) potvrzena
- je timeout reportovany spravne

Pomozte mi, prosim, v logu najit NEPOTVRZENOU zpravu odvysilanou do XPressNet. Je totiz mozne ze delam nejakou brutalni chybu, spatne neco interpretuju atd. V opacnem pripade totiz potrebuji pana presvedcit, ze co si mysli je blbe, aby byl VUBEC ochotny akceptovat myslenku ze se v jeho kodu muze nejaka chyba vyskytovat.

Update: proc mi to vadi -- protoze diky tomu blbemu timeoutu mi vrci 5 sekund servo na dorazu, protoze JMRI neposle "vypnout".
Update2: aby bylo jasno, je mi jedno ze nekdo ten kod napsal spatne. Chybu opravit umim, ale jaksi bez pochopeni ze chyba vubec existuje tezko dostanu relevnantni info k tomu, abych ji opravil spravne - s ohledem na vsechny podporovane centraly. Prozatim jsme v rezimu "tak se to ma chovat, protoze to jinak nejde. Dej si tam nejaky cekani".

[belgarat]

Haleluja.

Po 5 dnech vysvetlovani a posilani logu konecne jadro zpravy prorazilo nanosy ... no nevim ceho, a dorazilo do mozku autora.
... doufam ze se mi povede brzo udelat test-case z komunikace s DR5000 - protoze na "na oko" funguje lepe, ale vypada to, ze v detailu se mohou spatne parovat zpravy; specialne pokud se prehazuji vyhybky na ceste, a jsou cislovane tesne za sebou.

On clovek nepozna kdyz vyhybka vyhlasi rychle po sobe "jsem rovne", "jsem do odbocky", je to moc rychle. Ale jak jsou na tom povesene dalsi skripty, ktere hlidaji stav ... zareaguji

[belgarat]

Test s DR5000 je semi-pozitivni: na jednu stranu se mi NEpovedlo dovest rucnim ovladanim nebo skriptem "system" do stavu timeoutu nebo jine vetsi smrti, jako s NanoX.

Na druhou stranu je z logu jasne, ze JMRI nespravne paruje pozadavek-odpoved na XPressNet, takze kdyz mate stesti (muj Python script jej ma vzdy), tak odpoved se stavem _predchozi_ prehozene vyhybky pripise _nasledujici_ vyhybce ... a protoze zprava prece jen tak nejak obsahuje cisla vyhybek, dojde jen k tomu, ze stav inkriminovane vyhybky preskoci na "rovne" a nasledne (cca 30-50ms) zpatky "do odbocky". Jelikoz na udalosti zmeny 'commandedState' nebo 'knownState' radi sedavaji dalsi skripty, muze to nadelat docela bordel Skutecnou odopoved (pro Sidla: pseudo-) ohlasu centraly pak JMRI povazuje za neocekavanou zmenu, ac ji samo vyvolalo.

[belgarat]

Jupiii .... je pry opraveno.
Na mailing list jsem teda psal, ze ta oprava je nedostatecna, ze se resi A a neresi se B a C... tak jsem snad blby ja. Prece jen cist rozdily a z nich usuzovat na funkci je ... nachylne k chybam: tak uvidime.

commit 10ae83f71a11a2547fc98206980c0ff065dabc91 (HEAD -> master, upstream/master, origin/master, origin/HEAD)
Merge: df57734753 270775af57
Author: Paul Bender <paul.bender@acm.org>
Date: Sun Mar 15 23:38:58 2020 -0400

Merge pull request #8246 from pabender/development

Improvements to XpressNet turnouts. Apply immediatePipedOutputStream anywhere applicable

.... za 20 minut - poustim testy:

ant -f /space/src/jmri/fixes/JMRI/nbproject/nbjdk.xml -Dtest.includes=jmri.jmrix.lenz.XNetTurnoutMonitoringTest debug-test-single.nb
...
Failures (1):
JUnit Vintage:XNetTurnoutMonitoringTest:testGenLiSwitchTimeout
MethodSource [className = 'jmri.jmrix.lenz.XNetTurnoutMonitoringTest', methodName = 'testGenLiSwitchTimeout', methodParameterTypes = '']
=> java.lang.AssertionError: Timeout must not occur

BLEEEE !
Asi mne ceka dalsich 5 dni vysvetlovani .... ten test je samozrejme tentyz na kterem jsem reprodukoval prislusnou chybu pred 2 tydny.

[belgarat]

Kdyz uz to tu mam jako blog ... tenhle prispevek jen pro programujici v Jave (nebo pribuznych jazycich), ostatni prosim prominou za off-topic

https://github.com/JMRI/JMRI/blob/66a84 ... .java#L564

I don’t believe the call to jmri.util.ThreadingUtil.runOnLayoutDelayed gives up the synchronization lock, so the second off message won’t be queued until after the first message is put into the queue.

"Nemyslim si, ze volani jmri.util.ThreadingUtil.runOnLayoutDelayed uvolni zamek synchronizace, takze druha 'off' zprava (dalsi vyvolani metody) se nezaradi do fronty drive, nez se do fronty dostane prvni zprava

Pan ma skoro pravdu... az na to, ze ono volani runOnLayoutDelayed skonci jakmile naplanuje zaslani te zpravy za 30ms a nepocka az se skutecne uloha provede:
https://github.com/JMRI/JMRI/blob/66a84 ... .java#L208

Jak vidno, metoda zmeni stav, skonci ... takze pripadne dalsi volani skrz metodu uz nebude neco poustet odlozene. A to nemluvim o tom, ze se panovi povedlo skrz retezec volani a PropertyChangeListeneru zavolat tu metodu rekurzivne podruhe, takze kdyz centrala posle odpoved, JMRI vychrli hned nekolik 'off' zprav. Hlavne ze v diskusi pripomina, ze je xpressnet vuci pocitaci pomaly

Prace s timhle dubovym materialem je podstatne pomalejsi nez samotna oprava Ted se mi ho podarilo zrejme hodne urazit, protoze jsem poslal log, kde jsou tyhle "sofistikovane designy' (nejedna se zdaleka o jedinou blbost) videt :-/

Then XpressNet monitor shows one outgoing, and 2 incoming messages:
22:44:18.683: [packet:52 02 8E DE] Accessory Decoder Operations Request: Turnout Address 12(Base Address 2,Sub Address 3) Turn Output 0 On.
22:44:18.692: [packet:01 04 05, unsolicited: false] Command Successfully Sent/Normal Operations Resumed after timeout
22:44:18.705: [packet:42 02 16 56, unsolicited: true] Feedback Response: Turnout without Feedback Turnout: 11 State: Thrown Right; Turnout: 12 State: Thrown Left

Jeden prikaz do centraly - dve odpovedi

And I can confirm that it does. It's intersting, but last night I tried connecting to the LZV200 with The LI101F [....] Strange how I never noticed that before

A ja to mohu potvrdit. Je to zajimave, ale vcera v noci jsem se zkousel spojit s LZV200 pomoci LI101F ..... Divne je, ze jsem si toho nikdy predtim nevsiml.

Pan vyviji Lenz/Xpressnet podporu vice nez 10 let - doufam ze jsem skocil na sarkasmus a budu za debila - neudrzel jsem se blbych poznamek.

Sidlo gratuluji ke stastne ruce, ze sis pro ovladani kolejiste zvolil LocoNet podporu. Preju Ti, at ji vyviji nekdo jiny.

[sidlo]

Nemohu se zbavit dojmu, že tu někomu ležím v žaludku.

[belgarat]

Nemohu se zbavit dojmu, že tu někomu ležím v žaludku.

Eeee - vubec ne. Ta gratulace byla myslena smrtelne vazne - teda aspon doufam, ze LocoNet v JMRI pise nekdo chytrejsi (stacilo by peclivejsi) nez je mistr XPressnetu. Ja na domacim kolejisti LocoNet nechci (viz vyhrady jinde) a jsem proste liny a 2 sbernice se poradne ucit nehodlam - ac umi DR5000 obe a tudiz jde zvolit to lepe popdorovane.
Jasne za potize si muzu sam.

[sidlo]

Ta gratulace byla myslena smrtelne vazne

V tom případě sám sebe považuješ za jasnovidce a víš co používám.

[belgarat]

V tom případě sám sebe považuješ za jasnovidce a víš co používám.

Za jasnovidce urcite ne -- ale jsem si skoro jisty, ze implementace komunikacni vrstvy konfiguravana zde (mysleno obrazovky JMRI): https://sites.google.com/site/sidloweb/jmri/dr5000 nema s kodem kolem XPressNetu moc spolecneho. Nebo ano ?

[sidlo]

Považovat internetovou stránku kterou jsem napsal za důkaz toho co používám je hodně zkratkovité.
Na druhou stranu existence tohoto vlákna a především jeho obsahu hodně vypovídá o způsobu myšlení jeho autora.

[Brejla]

Autor vlákna se snaží poukázat (podle mě marně) na lemplovství komunity vytvářející JMRI. A lemplové z bandy JMRI se cítí dotčeni, že se někdo z normálních smrtelníků odvážil na ten bordel poukázat a zkouší ho napravit.

[belgarat]

Jo, Sidlo ma pravdu: kdyz je v jeho navodu na prvnim miste setup DR5000 pomoci LocoBuffer, nejak jsem predpokladal, ze to v konfiguraci, kterou radi ostatnim uzivatelum i pouziva. Ted koukam ze i v dalsich clancich jsou "systemova jmena" LTxx ... no, tak fajn - je tam Loconet, ale ve skutecnosti se vlasnte pouziva neco jineho. Tak jsem si spatne spojil Sidlovy posty zde na foru, webstranky se soucasnou situaci - ja delam chyby a neurazim se proto, ze mi to nekdo rekne.

Urcite to jde ale i bez jizlivosti. Na druhou stranu, je lepsi vedet na cem clovek je, nez kdyz se ma prokousavat nejakym politicky-korektnim newspeakem zaimco na nej ma zdanlivy kolega ve skutecnosti pripravene ostre naboje kdekoliv je to mozne.

Ze prirozena reakce na blbe zpravy je zastrelit posla je jasne, a hlavne to nevyzaduje zadne premysleni. Zvlast kdyz jde o nejakou "posvatnou kravu", zbozstely software nebo (udajne) naprosto neotresitelnou pravdu. V Sidlove pripade mne takovy pristup ... no, predevsim mrzi.

Tedy s dovolenim zmenim gratulaci:
Gratuluji VSEM co pouzivaji JMRI s LocoBufferem, ke stastne ruce pri vyberu. A at jim podporu v JMRI vyviji nekdo chytrejsi/peclivejsi nez tamni pan XPressNet, aby jim ve zdravi a dlouho kolejiste fungovalo.

Edit: naopak tem co pouzivaji Lenz-klony ovladane pomoci LI*, Z21 a tak dale vyjadruji uprimnou soustrast. Nejenom ze jsou v implementaci brutalne vrsene chyby na sebe, takze to vicemene funguje - ale pokud se to spravi, tak budou moct jeste navic nadavat zdejsimu enfant terrible, to jest mne. Muzete si kopnout, panove.

Edit2: Sidlo, kdyz ti do oci nekdo tvrdi blbost jako jsem zde publikoval pro ukazku (nejedna se o prehlednuti ale o vysledek po upozorneni na mozny problem) ... co na to rict: Zaver je jednoznacny: nerozumi kodu ktery pise - at uz z lenosti si precist dokumentaci, probehnout prave napsane debuggerem ... pripadne nebo z hlouposti nebo "nejak mi to funguje, resit to nebudu, neco si vymyslim"; ale to na vysledku nic nemeni.
Ten jizlivy mail na jmri-dev s verejnym poukazem na to, co pan autor v JMRI zkopal jsem poslal po MESICI zbytecnych a nesmyslnych diskusi, a po mesici, co dostal slusne a privatni upozorneni, ze je vhodne se zamerit na urcite casti kodu nebot jsou chybne (plus samozrejme logy). Nestalo se.

[sidlo]

V několika posledních postech jsi mě několikrát zmínil
http://diskuze.modely.biz/viewtopic.php?f=28&t=12257&start=150#p270186
http://diskuze.modely.biz/viewtopic.php?f=28&t=12257&start=150#p272107

Tak jsem napsal co si o tom myslím
http://diskuze.modely.biz/viewtopic.php?f=28&t=12257&start=150#p272112

Urcite to jde ale i bez jizlivosti.

Myslím si to samé.

Jupiii ....
BLEEEE !

[belgarat]

Sidlo, je treba asi trochu rozlisovat.

Na mailing listu JMRI se bavim s clovekem, ktery bud nedokaze korektne precist a vyznamove pochopit 10 radek sveho vlastniho kodu, nebo - pokud to udelal - nedokaze jednoduse rict, "sorry ve skutecnosti to funguje jinak". Jestli to resit nechce, nebo neumi mne nezajima - pocita se vysledek: zatimco jeho vysvetleni (napr.) proc se prikaz musi posilat opozdene dava velky smysl. Provedeni kodu ale dela zcela neco jineho. Rozpor ? Ano. Chyba ? Jasne to se muze stat. Zaver ? "Verim, ze to funguje tak, jak jsem rikal". Vira mozna prenasi hory, ale bity na ni kaslou.

Po mesici casu ztraceneho neustalym vysvetlovanim, ze ano - logy jsou z realneho HW. Ano, simulator je psany podle skutecne zaznamenanych packetu, proto aby pri testovani nemuselo byt kolejiste furt on-line. Ano, dokonce i Lenz stanice se chova jinak, nez pan prezentuje. Coz je obzvlast sokujici, kdyz se jimi zabyva jiz 15 let: namisto zasvecenych informaci cely ten mesic dodaval informacni sum. Duvod ? Mozna ochrana know-how ... ale v otevrenem projektu ?

Edit: pro klid duse - a vylouceni vlastni blbosti - jsem i dopsal logovani, ktere v JMRI chybelo: aby stavy, vztahy mezi zpravami atd byly vyslovne zaznamenane. Kdyz je neco napsane cerne na bilem, snad si nedomyslim tu vec spatne. No - prekvapeni, i 'obohaceny log' ukazuje, ze se pan spletl. Nejde o to "kdo ma pravdu", ale o spravnou funkci. Napriklad, kvuli kombinaci chyb v kodu se prehazovani 6 vyhybek resi 5 sekund. A celych tech 5 sekund centrala vesele opakuje do DCC (protoze ji nikdo nerekl "hrnecku dost") zbytecne packety. Ale funguje to, nakonec - takze cajk nic opravovat nebudeme.

.... a vuci takovemu cloveku, ktery me (neprofesionalnim pristupem) stal mnoho desitek hodin vyvojoveho casu nemam byt jizlivy ?

Tak - a ted si vezmeme nas dva:

Cim Te tak strasne popudilo - nebo ti sebralo 20-50 hodin casu apod - to, ze jsem Ti od srdce pogratuloval za stastny vyber, kterym ses (jsem se domnival) temto problemum "s XPressNetem", ktere si uzivam s DR5000 a Nano-X vyhnul ? Nebo Te popudilo - a mne naveky zatratilo (pro vsechny dalsi dny, ciny, vyroky) to, ze jsem si DOVOLIL znesvetit JMRI podporou pro Fulduv "DIY" (ale bez firmware) dekoder ? Edit: a nebo ze tu plane prskam, placam, ostouzim ... a nic vic ? Ale delam, ale napsat kod poradne TROCHU trva - tady namahy nejak nelituju, delam to i pro sebe. A porad se peru s nedostatkem dat - duvody viz vyse.

[sidlo]

Definice dekodérů od fuldy je roztahaná do dvou složek. Kdo to neví, tak může být překvapen, v horším případě tu definici nenajde. To je dle mého názoru blbě.

V JMRI jsou definice mnoha dekodérů. Bohužel dovozci těchto dekodérů to neví a neumí uživatelům poradit jak s nastavení. To je dle mého názoru blbě.

V Čechách a na Slovensku je poměrně hodně malovýrobců. Mnozí z nich mají registraci u NMRA. Bohužel nikdo z nich si už nedal tu práci aby udělal také definici jejich dekodéru do JMRI. To je dle mého názoru blbě.

V životě se stávají horší věci. Tohle mi žíly netrhá.