Plky o JMRI

[belgarat]

Ano, ja Te chapu. Stejne jako chapu cloveka, ktery na C++ na PCcku pouziva Emacs a ladi v GDB v dobe kdy existuji IDE ... ale na nazoru na JMRI a kvalitu kodu a provedeni to nic nemeni. Emacs totiz, na rozdil, od JMRI nema ty skolacke a zbytecne chyby

[belgarat]

Mimochodem - vcera jsem v Layout Editoru "neco pokazil", a dnes rano uz se mi Layout do JMRI nenacetl s nejakou chybou, ze XML panelu neodpovida schematu. Finito, tecka. Cela prace "byla v troube".

XML bylo vymyslene prave proto, aby se z podobnych volovin dalo zotavit ... napriklad preskocenim 'vadneho' elementu. Ale zrejme je pro bezneho uzivatele-modelare vhodne editovat mnohakilovy soubor XML plny znacek, ktere nikde nejsou zdokumentovane (nebo se naucit kde najit patricna XSD a jejich jazyk), nalezt to spravne misto ktere se ma vymazat. Proc mu zjednodusovat zivot tim, ze by to program udelal za nej, ackoliv "vi" uplne presne ktery element a jak porusuje schema, tudiz kde zasahnout ...

[sidlo]

Nikdo by neměl používat software který mu nevyhovuje. Doporučuji přejít na SW bez školáckých a zbytečných chyb.

Pokud se jedná o ztrátu souboru s panely, potom doporučuji se podívat do adresáře profile:backupPanels/ a vybrat poslední použitelnou zálohu. Zálohy jsou označeny časovou známkou.

[belgarat]

Ano a to je presne ten duvod proc JMRI je a bude v takovem loji ... jak jsem hovoril vyse. Protoze dokud se bude panum pochlebovat (nebo taktne mlcet) o vybornych funkcich, jakoze treba v dialogu kde je "OK" a "Cancel" nefunguje ENTER jako "ok" (a nekdy ani ESC jako Cancel), tak si budou stale myslet jak to delaji uplne skvele. Pripadne se jeden dozvi, ze vlastne takovou blbost zadny skutecny uzivatel JMRI nechce

Samozrejme mas pravdu, JE to masochismus - ale je to tak rikajic kalkulovany masochismus: Cenu TC neobhajim, a z pocatecnich pokusu deti o kresleni layoutu v RocRail si myslim, ze si az tak moc nepomuzeme.

[radeksindy]

tak to někteří považují za chybu JMRI.

Z principu to ale chyba JMRI být nemůže JMRI je zařízení, které se řídí definicemi v protokolech sběrnic, přes které komunikuje. To by muselo být definováno v protokolu DCC, LocoNetu nebo jiných. Ale ty jsou pstaveny tak, že stav zná pouze zařízení, které jej detekuje a napožádaní předá. Stejně jako uchovávání stavu funkcí F13 až F28 dekodérem je definováno v DCC normách, muselo by uchování stavu výhybky mimo její dekodér někde uvedeno a tomu podřízeno. Ale kdyby to tak někdo udělal, bylo by to hodně hloupé.

@radeksindy resim to, jak (zda) se muze SW dozvedet neco o polohach vyhybek a znacich navestidel

Z toho co jsem napsal výše je jasné, že se to musí umět dozvědět (v LocoNetu 0xBC, v DCC některé broadcat pakety atd.). Jenomže on se může dozvědět stav vstupu, nikoli výstupu. Nemá smysl se ptát na stav výstupu dekodéru světelného návěstidla. Jeho stav musí umět zařízení vypočítat nebo dovodit ze známých stavů (výhybky, úseky a požadavek řízení). Pokud se někdo dostal do stavu, že by chtěl zjišťovat stav výstupu, tak je chyba v uvažování. Taky se neptáte jaký poslední příkaz byl poslán výhybce, ale v jakém je stavu. U mechanického návěstidla by mohlo být ekvivalentemto, že je nějaký spínač fyzocky závislý na poloze ramene. U světelného návěstila by mělo smysl se ptát, zda je obvod žárovky uzvařený a jestli svítí, nebo není a žárovka praskla. Ale to není totéž jako ptát se jestli tam někdo poslal návěst volno nebo stůj. Za to může být zodpovědný jeden prvek a tento dopočítává a ví a nic nemusí zjišťovat.

[belgarat]

@radeksindy: fakt jsem nad Tvym postem premyslel ... tak prosim mej trpelivost, kdybych se nekde zatocil v kruhu a pomoz mi jej rozseknout. Nejak mi ale prijde, ze "do uvahy" zanasis jeste dalsi vrstvu (dekoder_vystup -> navestidlo), kterou jsem se snazil v predchozim naopak (pro jednoduchost) odparat.

Zavadet do uvah realny feedback, "stav vystupu dekoderu" je IMHO sporny a nadbytecny prvek - ackoliv jeho pouziti Ti umozni zneplatnit celou uvedenou uvahu ... ale ja o takove veci nikdy nehovoril. Osobne si dovolim pochybovat ze vubec nekdy nekdo byt uvazoval o zrizeni realneho feedbacku navestidla, tzn. signalizaci stavu jednotlivych svetel.

Domnivam se, ze pro SW je podstatny fakt "muzu se zjistit stav" / "nemuzu zjistit". A "stav" rozhodne na tehle vrstve neznamena "stav vystupu dekoderu". U prestavniku to SHODOU OKOLNOSTI vypada stejne. Ale ja tam "vystup dekoderu" nemam. Opravnene predpokladam, ze je vice ovladacu (vcetne SW JMRI/TC - je to sbernice, takze vice ovladacu se predpoklada), a KAZDY se muze (v urcitych limitech) zeptat centraly na stav toho, co nastavily "na vstupy prislusenstvi" (tvou terminologii) PRES CENTRALU jine ovladace. To je ale dost jina situace, nez vyzadovani realneho feedbacku z jednotlivych svetel.

Minimalne s NanoX dostane SW urcite broadcast, kdyz jiny ovladac vyda pokyn dekoderu navestidla, a OBCAS(adresa <= 256) se i muze sam doptat na posledni znamou (centale) hodnotu "vstupu". Dal to pak neni zadny problem hw, centraly, dekoderu, ale jenom a jenom SW. At uz nedodelaneho nebo spatne navrzeneho.

K tomu cos psal: JMRI dokaze podle pozadovaneho znaku navestidla (= urcita kombinace stavu accessory adres - podle Tebe vstupu) vyhodnotit a provest ("nastavit vstupy") prestaveni vyhybek, a dokaze ovladat ono navestidlo (skrzeva "vstupy" jeho dekoderu). Stejne tak, kdyz nekdo jiny "nastavi vstupy" navestidla, JMRI velice dobre muze zjistit jakemu znaku dana kombinace "vstupu" odpovida - a nepotrebuje k tomu zadny HW, ma to ve sve vlastni SW konfiguraci.

[belgarat]

FWIW, udelal jsem podobny monitorovaci pokus JMRI + DR5000 / XpressNet-LAN ... podobne chovani; pokyn ovladace po XPressNet vyvola zpravu pro JMRI accessory info; je mozne se ptat na vyhybky 1-255, command station odpovi posledni znamy stav ("vstupu" dekoderu podle terminologie vyse)

Zajimavy je, ze pri jakekoliv akci rocomysi k lokomotive DR5000 proaktivne posila PCcku "locomotive being operated by another device" ... to NanoX nedelala

[radeksindy]

Předesílám, že podobné úvahy moc s realizací nesouvisí.

Opravnene predpokladam, ze je vice ovladacu (vcetne SW JMRI/TC - je to sbernice, takze vice ovladacu se predpoklada), a KAZDY se muze (v urcitych limitech) zeptat centraly na stav toho, co nastavily "na vstupy prislusenstvi" (tvou terminologii) PRES CENTRALU jine ovladace.

Ne, na to se skutečně nikdo zeptat nemůže, protože takovou informaci nikdo nedrží, ani ji nemá povinnost držet. Ani není jasné k čemu by byla. Většina takových informací jen protéká od zdroje do cíle. Pokud budou dva ovladače a jeden přehodí výhybku, tak druhý bez čtení a analýzy toho o paketu nezjistí stav výstupu, který ovládá výhybku, ani kdo to udělal. Lze se pouze zeptat, v jakém je stavu vstup, který o poloze referuje.

Nevím co je NanoX, ale obecně v centrálách Lenz, Digitrax (obecně LocoNet) nic takového není. Vlastně ani nemůže, protože třeba v LocoNetu se systém netuší co se přestavuje daný příkaz. Analýzou paketu sice můžeš, že se mění výstup č. X na hodnotu Y, ale systém neví na úrovni centrály, co to znamená. Spadne návěstidlo? Přehodí se výhybka? Rozsvítí se dioda na pultu? Buď to ví člověk, který klape na ovladači změnu hodnoty a v jeho hlavě je to rozsvícení světla nebo je to něco inteligentního jako JMRI, a to může mít na určité urovni vyšší znalost, tj. ví že to je návěstidlo. Jedině, že by si centrála tupě pamatovala X posledních příkazů odeslaných někam a na vyžádání je vydala. Ale k čemu je to dobré moc nevím.

JMRI dokaze podle pozadovaneho znaku navestidla (= urcita kombinace stavu accessory adres - podle Tebe vstupu) vyhodnotit a provest ("nastavit vstupy") prestaveni vyhybek, a dokaze ovladat ono navestidlo (skrzeva "vstupy" jeho dekoderu). Stejne tak, kdyz nekdo jiny "nastavi vstupy" navestidla, JMRI velice dobre muze zjistit jakemu znaku dana kombinace "vstupu" odpovida - a nepotrebuje k tomu zadny HW, ma to ve sve vlastni SW konfiguraci.

Ano, má v sobě model celého světa kolem a analýzou si to zjistí. Ale k tomu je nutné trvale sledovat provoz na síti paket za paketem. Pokud by někdo chtě v každém okamžiku vědět, jaký je stav výstupu a kdo jej naposledy nastavil, musí si vybudovat svoji diganostiku.

[belgarat]

@radeksindy: reknu mozna neco spatne, ale prijde mi ze motas jabka a hrusky. Volne se zamenuji fyzicke vystupy (ktere lezou z dekoderu ven) s logickymi (ty jim rikas obcas "vstupy"), ktere se ovladaji pres DCC (a v mem pripade pres XPressNet).

Kdyz nikdo dany stav nedrzi - jak je tedy mozne, ze vidim na XPressNet monitoru, ze se JMRI zeptalo centraly DR5000 "jaky stav ma accessory xxy" a dostalo validni odpoved (tzn. bit z accessory commandu, co predtim JINY ovladac poslal) ? Zkousel jsem to i tak, ze jsem s vypnutym JMRI provedl par zmen, nastartoval JMRI ... a hle, "vyhybky" mely stav takovy, jak je v nepritomnosti JMRI cizi ovladac nastavil. Ano, nejedna se o stav VYSTUPU dekoderu, ale o pouhou informaci jaky stav byl naposledy skrz centralu dekoderu narizen.

Verim, ze zadna NMRA specifikace nepozaduje, aby centrala drzela prislusne informace. Na druhou stranu ... Nano-X, DR5000 a (podle Fuldy, ja ji nemam) i centraly Lenze toto delaji, minimalne komunikujic s PC pomoci XPressNet.

MMch nikde jsm nerikal, ze "centrala zna navestidlo" - projdi si prispevky, hovoril jsem doufam vzdy o prislusenstvi: na tehle vrstve navestidla "neexistuji". jsou jenom DCC adresy se 2 vystupy, resp. nastavitelnou hodnotou vystupu. Take jsem nikde nerikal, ze je zajimave "kdo vystup naposledy nastavil". SW staci, ze se dozvi ze "byl nastaven" - a obvykle je SW tak chytry, ze "vi" ze to byl nekdo jiny (napr. proto, ze narizeny stav je jiny, nez model sveta v SW); kdo je puvodce, OBVYKLE neni az tak podstatne. Otazku "kdo" sis pridal Ty - a na ni odpovedet nelze.

[radeksindy]

@radeksindy: reknu mozna neco spatne, ale prijde mi ze motas jabka a hrusky. Volne se zamenuji fyzicke vystupy (ktere lezou z dekoderu ven) s logickymi (ty jim rikas obcas "vstupy"), ktere se ovladaji pres DCC (a v mem pripade pres XPressNet).

Bavím se jen o vstupech nebo výstupech. Jde o směr, jestli je logický, silový nebo jablečný je jedno.

Kdyz nikdo dany stav nedrzi - jak je tedy mozne, ze vidim na XPressNet monitoru, ze se JMRI zeptalo centraly DR5000 "jaky stav ma accessory xxy" a dostalo validni odpoved (tzn. bit z accessory commandu, co predtim JINY ovladac poslal)

Už jsem psal. Nevím co dělají ostatní centrály, ani nevím co znamená zeptat "jaky stav ma accessory xxy". Jaký konkrétní paket je to v tomto případě? V jakém systému leží ten dekodér ? DCC? Poslal se paket s hlavičkou 0x42 (v XpressNetu)? "Accessory decoder request"?

[belgarat]

Už jsem psal. Nevím co dělají ostatní centrály, ani nevím co znamená zeptat "jaky stav ma accessory xxy". Jaký konkrétní paket je to v tomto případě? Poslal se paket s hlavičkou 0x42 (v XpressNetu)? "Accessory decoder request"?

Kód: Vybrat vše

[packet:42 01 80 C3]   Accessory Decoder/Feedback Encoder Status Request: Base Address 1,Lower Nibble.
[42 01 09 4A]   Feedback Response: Turnout without Feedback Turnout: 5 State: Thrown Left; Turnout: 6 State: Thrown Right


Omlouvam se ze jsem si dovolil prelozit "Accessory decoder/feedback encoder status request" (v XpressNet specifikaci "Accessory Decoder information request
") na "jaky stav ma accessory".

V jakém systému leží ten dekodér ? DCC?

Ano, jednalo BY SE o DCC dekoder. Akorat ze jak jsem zapojoval pro pokusy, tak k centrale nemam pripojeno VUBEC NIC. Ani koleje, ani dekodery.

[radeksindy]

Omlouvam se ze jsem si dovolil prelozit "Accessory decoder/feedback encoder status request" (v XpressNet specifikaci "Accessory Decoder information request ") na "jaky stav ma accessory".

Nic se neděje, ale máš špatnou interpretaci toho co ta funkce dělá. Ona skutečně poptává dekodér. Tzn. že centrála na základě paketu odešle dotaz přes DCC a dekodér zpátky odpoví. Ona ti nevrací nic, co předtím někdo poslal a už vůbec se ta informace neuchovala v centrále. Toto je přesně paket, který jsem zmiňoval dříve. Nikdo si nic nemusí pamatovat, když se to dá zjistit - v XpressNetu přes tuto funkci.

tak k centrale nemam pripojeno VUBEC NIC. Ani koleje, ani dekodery.

A proto ti nic nepřišlo zpátky Nebo si sem odpověď nekopíroval?

[belgarat]

A proto ti nic nepřišlo zpátky Nebo si sem odpověď nekopíroval?

Znovu kopiruji totez:

Kód: Vybrat vše

[packet:42 01 80 C3]   Accessory Decoder/Feedback Encoder Status Request: Base Address 1,Lower Nibble.
[42 01 09 4A]   Feedback Response: Turnout without Feedback Turnout: 5 State: Thrown Left; Turnout: 6 State: Thrown Right


Prvni radek: zadost o informace, PC > centrala.
Druihy radek: odpoved, centrala > PC.

Pricitam to pozdni nocni hodine, ale i predtim jsem VYSLOVNE psal, ze do JMRI dochazi korektni odpovedi (tedy takove, ktere odpovidaji predchozim commandum z MultiMaus). Mimochodem - DCC dekodery, ktere pouzivam NEMOHOU odpovidat zpatky; nemaji totiz ACK obvody ani Railcom. Navic KDYBY byly pripojene (taky jsem psal, ze mam centralu, na ktere neni NIC, ani koleje, ani dekodery).

[zdeno]

ono by asi chtelo zadefinovat, co od toho ocekavate a potom bude mozne hledat zpusoby, jak toho dosahnout ?
---
Ono uz na toto tema kdysi probehla debata a to, ze zakladni stav je vsechno na "STUJ".
Teda kazda cesta se stavi jedinecne a vlatne nikoho nezajima, jak je co nastavene.
A to plati aj pro automatiku, proste se neda spolehat na to, ze minuly stav byl a je spravny.

[radeksindy]

belgrat: Omlouvám se, přehlídl jsem, že to je jen z komunikace mezi centrálou a počítačem a že k tomu dekodéry nejsou. Na paket, který si poslal by se měl vrátit skutečně status dekodéru, tj. poslední co do dekodéru dorazilo, zpětná vzaba, nebo něco podobné podle typu. Co by ale vrátila centrála, kdybys poptal dekodér, který si dlouho nebo nikdy neobsluhoval? Hlavně je divné, že to vůbec něco vrací. Představ si následující situaci. Pošleš příkaz výhybce, ale kvůli poruše nedorazí. Na dotaz o stavu dekodéru by ti centrála v případě nedostupnosti odpověděla nečím co má v paměti (co ale nedorazilo), ale to přeci není totéž, co je tam ve skutečnosti. Přinejmenším by měl systém pro uživatele rozlišit, kde to vzal. Pro mě je tedy na místě spíše studovat, proč centrála vrátila uvedené hodnoty, zda je vrátí vždy stejné. Jestli je rozdíl při změnách adresy, poptávání nikdy nedefinovaných adres apodobné případy. A jaký je rozdíl proti chování v situaci, když tam dekodér je.