Plky o JMRI

[Kajinek11]

Omlouvám se že reaguji až teď, ale mohl jsem to vyzkoušet až dnes. To co jsi psal Sidlo, bylo samozřejmě v pořádku. Rozhraní centrály pro DR5000 komunikuje normálně a může číst a zapisovat CV normánlě. To je ale k ničemu. Potřebuji Decodert Pro.
No nicméně jsem pokročil, ale....

přepnutím v připojení Loconetu "Comand Station type" na "Stand alone - Loconet" jsem přemluvil Decoder Pro k načítání CV, ale neumí Decoder Pro načítat celá pole (sheety) pro nastavení konkrétního decodéru.. Netušíte?

To tlačítko pro načítání hodnot pro tyto sheety je šedivé.

Co má vůbec být v poli: "Comand Station type" nastaveno správně za hodnotu, pokud používám:
DR5000 + přes USB připojený PC s Decoderem Pro.
k ovládání 2x drátové MM připojeny do centrály
příslušenství je analog

Víc zatím nepotřebuji.. Díky za pomoc..

[sidlo]

1) Serial port -- písmo port COMn musí být černé. Pokud je červené COM8, potom to znamená že je daný port obsazen jiným programem, např. DR5000 Configuration, fotoaparát, navigace, ... O port se přetahují dvě aplikace. Problém se musí napřed vyřešit.

2) Command station type: DCS100 (Chief)

[Kajinek11]

Tak se mi to podařilo po různých kombinací nastaveních připojení a nastavení Decoder Pro rozchodit, ale když už jsem se v tom vrtal změnil jsem si úložiště souborů a všechny mé uložené Decodery mi zmizely. Zkoušel jsem je nějak pomocí návodu nahodit zpět, ale nepovedlo se mi to. Je fakt , že to není moc uživatelsky přívětivé.. Víc asi vysvětlí screeny:

ScreenHunter_628 Dec. 17 10.53.jpg

ScreenHunter_629 Dec. 17 10.54.jpg

ScreenHunter_630 Dec. 17 10.59.jpg

[sidlo]

1. je nutné mít zálohu adresáře nastavení JMRI, např. C:\Users\uživatel\JMRI
2. adresář Umístění uživatelských souborů/User Files Location neměnit (má to smysl měnit pouze v případě, že budete mít uložené nastavení někde v cloudu), ukazuje na kořen adresáře s profilem, ponechat C:\Users\uživatel\JMRI\názevProfilu.jmri
3. do adresáře C:\Users\uživatel\JMRI\názevProfilu.jmri\roster nakopírovat adresář roster ze zálohy, zde jsou uloženy nastavení CV jednotlivých dekodérů
4. do adresáře C:\Users\uživatel\JMRI\názevProfilu.jmri nakopírovat roster.xml, zde je seznam dekodérů a odkazy na soubory z adresáře roster

obnova je hotová, nastartovat DecoderPro

[belgarat]

Je fajn, ze jste z "plku" (odpadkoveho kose) udelali smysluplne vlakno ... ale prosim, pro dalsi generace ctenaru, abyste zvazili presun poslednich nekolika uzitecnych prispevku (nebo pokracovani diskuse) do zvlastniho vlakna, aby se informacni hodnota nekazila predchozimy plky, kvuli kterym bylo vlakno zalozene - diky

[Kajinek11]

1. je nutné mít zálohu adresáře nastavení JMRI, např. C:\Users\uživatel\JMRI
2. adresář Umístění uživatelských souborů/User Files Location neměnit (má to smysl měnit pouze v případě, že budete mít uložené nastavení někde v cloudu), ukazuje na kořen adresáře s profilem, ponechat C:\Users\uživatel\JMRI\názevProfilu.jmri
3. do adresáře C:\Users\uživatel\JMRI\názevProfilu.jmri\roster nakopírovat adresář roster ze zálohy, zde jsou uloženy nastavení CV jednotlivých dekodérů
4. do adresáře C:\Users\uživatel\JMRI\názevProfilu.jmri nakopírovat roster.xml, zde je seznam dekodérů a odkazy na soubory z adresáře roster

obnova je hotová, nastartovat DecoderPro

Hura pomohlo, dekuji...

[sidlo]

Mozna si to teda predstavuji podle popisu spatne,
Ad cykleni:
Jestlize je navestidlo rizene vyhybkami, tak kombinace navestidlo + vyhybka musi mit nutne "rovnovazny" stav. Prehodim vyhybku -> udalost -> implikuje navest -> udalost ... a ZDE by _teoreticky_ mel byt pozadovany stav vyhybky totozny s aktualnim, takze se nemelo jiz nic prehazovat. Samozrejme pokud je software dostatecne tupy a na udalost reaguje nepodminene ... mas pravdu.

Update: rozesilani udalosti v udalostmi rizene siti objektu se tradicne resi budto tak, ze system ma rovnovazne stavy (viz vyse), nebo tak, ze system "vi", ze ON zpusobil onu udalost, a tudiz dalsi implikovane akce jiz neprovede / ignoruje.

Taky se domnivam, ze nezavisle na cemkoliv by ovladaci soft mel indikovat skutecny stav navestidla, pokud jej dokaze zjistit; a to nezavisle na tom jak funguje pri ovladani z PC. Pokud dojde 'rucnim zasahem' ke stavu mimo normalni pravidla (napr. rucne nastavene VOLNO pri konfliktnim stavu vyhybek), tak je na miste ne to zatlouci, ale naopak omlatit uzvateli panelu o hlavu nejakym varovnym indikatorem.

Opusťme teoretický ideální systém a vraťme se do reality. Obecně je k centrále připojeno několik ovladačů. Obecně centrála nemá nařízeno v jakém pořadí bude řešit požadavky. Dekodér má nějaký čas na to, aby příkaz zpracoval a vykonal. Dekodér má právo příkaz přeslechnout. Z normy má centrála nařízeno každý příkaz několikrát opakovat. Mezi opakované příkazy vkládá jiné příkazy aby řeč nestála.

Bylo by hezké mít zpětný ohlas od návěstidla v jakém je stavu podobně jako u výhybek. U výhybky je to jednoduché, má pouze dva stavy (mimochodem všem doporučuji mít tento ohlas připojený https://sites.google.com/site/sidloweb/jmri/13-ohlas-vyhybek). Obecně návěstidlo má stavů více. Neznám zpětný ohlas, který by řešil více stavů. Pro inovátory je zde pole neorané.

[belgarat]

Hm; zpetny ohlas jak ho definujes ty nepouzivam.

Ale opet teoreticky ... navestidlo znamena tradicne dekoder obsazujici nekolik DCC adres prislusenstvi, a tudiz "pseudoohlas" ve forme toho co si centrala mysli (podle posledniho povelu pro zmenu vystupu prislusenstvi dane adresy, ne NUTNE jak je vyhybka nastavena) vetsinou existuje. Prave takhle treba dostava TrainController informaci kdyz rucne prestavim vyhybku, domnivam se: zadny fyzicky ohlas totiz zapojeny k prestavnikum nemam.

Funguje to take u JMRI (vyhybek) ? Pokud ano, proc to nemuze fungovat u navestidel (prislusenstvi na X DCC adresach) ?

[sidlo]

Hm; zpetny ohlas jak ho definujes ty nepouzivam.

Děláš chybu. Moje zkušenost z praxe je jiná. Viz odkaz na článek. Pseudohlas se může použít také. Ale ve skutečné provozu z toho mohou být maléry. Proto doporučuji skutečný ohlas na základě polohy přestavníku. Ale pokud jsi přesvědčen že to nepotřebuješ tak je to tvoje volba.

Ale opet teoreticky ... navestidlo znamena tradicne dekoder obsazujici nekolik DCC adres prislusenstvi...

Parafráze

A neni to trochu 'pres ruku', podobne jako vetsina veci v SW xyz ?

Řízení návěstidel více adresami používají ti jejichž SW + centrála + dekodér neumí řídit návěstidlo jednou DCC adresou paketem pro návěstidla dle normy NMRA.

[belgarat]

ad delam chybu: mozna nevyhod jsem si (teoreticky) vedom ... no, jestli delam dobre nebo ne se uvidi, a je to muj boj, nema vliv na to, o cem se bavime. JMRI ma tolik chyb, ze "nerealny ohlas" je vicemene zanedbatelna zalezitost. Dulezite je, ze MUZE ohlas ziskat; kvalita ohlasu je zavisla na implementaci v kolejisti, a o tom se ted nebavime.

Ad "pres ruku" u navestidel, ktere nepouzivaji extended accessory packety: ano, mas pravdu. Spravne je vyuzivat moznosti normy. Ale jsou dekodery ktere to neumeji; a domnivam se, ze jsme se prave o takovych dekoderech puvodne bavili - viz:

To iste som spravil pre 2 vchodove 5 znakove navestidla s adresami 301+302 a 303+304

i ja mam tech tupych dekoderu vetsinu - zatim ve forme tiskaku plus soucastek, ale i tak se budu snazit vyuzit zasoby.

[sidlo]

Bavili jsme se o tom, zdali je správný typ komunikace

A) ovladač - dekodér - SW
nebo
B) SW - dekodér
s možností
ovladač jiná adresa - SW - dekodér

a já tvrdím, že při současné definici prostředí je varianta A v praxi nerealizovatelná.

[belgarat]

a já tvrdím, že při současné definici prostředí je varianta A v praxi nerealizovatelná.

To je mozne. Muzu se tedy zeptat co, podle Tebe, brani tomu aby to bylo mozne ? Spatny (nedostatecny) prenos informaci kolejiste > SW, nebo nedostatecne (zvrtane) zpracovani v JMRI ?

[sidlo]

definice komunikace centrála - dekodér
ta je dnes jednostranná s výjimkou RailCom

definice komunikace centrála - ovladač
tady si každý dělá co chce

až uděláš normy které budou fungovat
a až tyto normy přijmou výrobci
teprve potom můžeš od řídícího SW něco požadovat

[belgarat]

eee - moment, nekde tam mas, myslim, chybu. Nebo si nerozumime.

"prime" ovladani prislusenstvi z ovladace (napr. RocoMys, nebo fyzicky tlacitkovy pult) jde prece
Ovladac -> CENTRALA -> dekoder

Souhlasim, ze kdyz si neco vymysli dekoder sam od sebe, nebo provedes tlacitkem na nem, tak centrala nema nejmensi sanci zjistit ze se neco stalo (vyjma railcom, ktery zas neni navrzeny na stacionarni dekodery). Ale kdyz PRES CENTRALU das povel dekoderu ... tak centrala prece "vi", co pres ni proslo ?

Nebo mozna uvazuju spatne, kdyz si myslim, ze je mozne si z centraly vyzadat "pseudostav" prislusenstvi, nebo ze centrala dokonce rozesila broadcast o zmene "pseudostavu" prislusenstvi ? Nemam ted kapacitu na to, abych si to overil, ale jedno z toho (podle mne) MUSI fungovat, kdyz TrainController umi zjistit, ze jsem pohnul vyhybkou. Aspon SI MYSLIM ze jsem videl na obrazovce, ze si zmenil polohu kdyz jsem rocomysi prepl. Znalci TC prosim opravte ... BTW - tohle platilo pro samodomo NanoX; je mozne, ze se DR5000 chova jinak, i na XPressNet rozhrani. Nemam odzkouseno.

[sidlo]

máš pravdu, myslel jsem to tak jak píšeš
ovladač - centrála - dekodér

vraťme se do reality
lokomotivy - povoleno více než 10000 - reálně si pamatuje 100? - když je dobrá centrála
příslušenství - povoleno více než 2000 - reálně si pamatuje 8? - když je dobrá centrála
zpětný ohlas - jak který systém, některé více než 32000 - reálně si pamatuje 10? - když je dobrá centrála

Teoreticky máš pravdu. Prakticky toho centrála moc neví.