JMRI

[Mafo]

Podrobný výpis z monitoru .

Centrála IntelliBox Basic

Připojení interface LocoBuffer. Parametry připojení: Digitrax - LocoNet LocoBuffer - Intellibox-II
Vyčtení CV8 = 145

Kód: Vybrat vše

16:20:17.457: [E5 07 01 49 42 41 56]  Uhlenbrock IB-COM / Intellibox II Start Programming Track.
16:20:17.458: [82 7D]  Set Global (Track) Power to 'OFF'.
16:20:17.496: [ED 1F 01 49 42 71 72 08 00 00 70 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C]  Read CV in Direct Byte Mode from PT for Uhlenbrock IB-COM / Intellibox - CV: 8.
[b]16:20:17.517: [B4 6D 01 27]  Long_ACK: Uhlenbrock IB-COM / Intellibox II CV programming request was accepted.[/b]
16:20:20.320: [E7 0E 7C 00 00 00 72 06 02 00 11 00 00 0D]  Programming Response: Uhlenbrock IB-COM / Intellibox II Programming Read Was Successful: CV1 value 145 (0x91, 10010001b).


Připojení USB kabel. Parametry připojení: Uhlenbrock - Intellibox-II (USB) - Intellibox-II
Vyčtení CV8 = 145

Kód: Vybrat vše

18:06:01.441: [E5 07 01 49 42 41 56]  Uhlenbrock IB-COM / Intellibox II Start Programming Track.
18:06:01.441: [82 7D]  Set Global (Track) Power to 'OFF'.
18:06:01.459: [ED 1F 01 49 42 71 72 08 00 00 70 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C]  Read CV in Direct Byte Mode from PT for Uhlenbrock IB-COM / Intellibox - CV: 8.
18:06:01.459: [B4 6D 01 27]  Long_ACK: Uhlenbrock IB-COM / Intellibox II CV programming request was accepted.
18:06:04.288: [E7 0E 7C 00 00 00 72 06 02 00 11 00 00 0D]  Programming Response: Uhlenbrock IB-COM / Intellibox II Programming Read Was Successful: CV1 value 145 (0x91, 10010001b).


16:20:17.517: [B4 6D 01 27] Long_ACK: Uhlenbrock IB-COM / Intellibox II CV programming request was accepted.

Problem asi je, ze Daisy II neposiela Long ACK !!!
Bez noveho firmware pre Daisy II to nepojde.
Alebo JMRI musi pridat novy typ centraly "Daisy II", spravit vynimku (necakat na ACK) pre tento typ paketu: 0xED, 0x1F.

[sidlo]

Problem asi je, ze Daisy II neposiela Long ACK !!!
Bez noveho firmware pre Daisy II to nepojde.
Alebo JMRI musi pridat novy typ centraly "Daisy II", spravit vynimku (necakat na ACK) pre tento typ paketu: 0xED, 0x1F.

Něco na tom bude, viz https://www.ngaugeforum.co.uk/SMFN/index.php?PHPSESSID=2dd59393hjrihp3rji5vulgrk2&topic=32391.msg371895#msg371895

I might have to do (or arrange) some code development to make the Uhlenbrock computer interface talk to JMRI. It is fine to control a layout (drive locos, operate turnouts) using a Digitrax PR3 or an RR Cirkits LocoBuffer to the Daisy system, but can't access programming loco features that way (something missing in a JMRI preference/configuration). Should be fixable if I spend enough time on it, or arm-twist the right person to help me.

Nebo tady https://www.rmweb.co.uk/community/index.php?/topic/114994-looking-for-non-digitrax-loconet-throttles/&tab=comments#comment-2436039

Only significant limitation is that I don't think you can do any programming of a loco on a Digitrax system from a Daisy-2 handset, and that would include setting CV19 to form consists. If CV19 were set on another handset, then the Daisy can then control the consisted loco. I doubt Daisy can access the command station consists within the Digitrax system either.

[belgarat]

Mam dotaz.

Jde nejak "lidsky" jednoduse vysvetlit rozdil funkci mezi Warrants a Dispatcherem ?
* Pro Dispatcher musim zridit Sekce a Tranzity.
* Pro Warrants musim udelat OBloky (v podstate znovu nadefinovat Bloky, co uz mam), Portaly, Cesty (asi jine nez Routes ?).

Oboji zrejme "nejak" ridi automatickou jizdu vlaku -- ale nevyznam se v rozdilech, tedy ani nevim kterou cestou se dat. S tim, ze se stejna vec zapisuje 2-3x (LRoute je jen rozsireni Route, u mne je nastaveni stejne, jen se musi udelat znova) bych se smiril.

[zdeno]

[ED 1F 01 49 42 71 72 08 00 00 70 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C] Read CV in Direct Byte Mode from PT for Uhlenbrock IB-COM / Intellibox - CV: 8.

on je asi problem v tom, ze Uhlenbrock ignoruje normy Digitrax-u a pouziva neschvaleny paket s opcode ED.
Podle mne je v normach pouzivany slot 124 a opcode EF, proto centrala neumi odpovedet LACK na nezname opcode ED.
Jinak opcode B4 (LACK) slouzi na potvrzeni, ze centrala prijmula prikaz a odpoved nasleduje v paketu E7.
Je tam vice variant, treba OPS (PoM) programovani.

[zdeno]

spravna komunikace Loconet vypada takto :
[EF 0E 7C 2B 00 00 00 00 00 02 00 7F 7F 4B] Byte Read in Direct Mode on Service Track: CV3.
[B4 7F 01 35] Unable to parse LocoNet message.
[E7 0E 7C 2B 04 00 00 07 00 02 00 7F 7F 40] Programming Response: Read Byte in Direct Mode on Service Track Failed, Read Compare Acknowledge not detected: CV3 value 0 (0x00, 00000000b).
---
Program JMRI tam ma chybu, protoze LACK je spravne, presne podle normy.
Odpoved je failed, protoze jsem nemel pripojenou kolej.

[Mafo]

[ED 1F 01 49 42 71 72 08 00 00 70 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6C] Read CV in Direct Byte Mode from PT for Uhlenbrock IB-COM / Intellibox - CV: 8.

on je asi problem v tom, ze Uhlenbrock ignoruje normy Digitrax-u a pouziva neschvaleny paket s opcode ED.
Podle mne je v normach pouzivany slot 124 a opcode BF, proto centrala neumi odpovedet LACK na nezname opcode ED.
Jinak opcode B4 (LACK) slouzi na potvrzeni, ze centrala prijmula prikaz a odpoved nasleduje v paketu E7.
Je tam vice variant, treba OPS (PoM) programovani.

Problem nie je v centrale ako takej. Ovladac Daisy2 si musi rozumient s centralou Daisy2, inak by to nedavalo zmysel...
Citranie CV funguje dobre, aj ked si "nepotrebuju" posielat medzi sebou LACK (ignoruju normy)...
Problem je, ze toto "neposielanie" nie je podporene v JMRI.....

[Mafo]

spravna komunikace Loconet vypada takto :
[EF 0E 7C 2B 00 00 00 00 00 02 00 7F 7F 4B] Byte Read in Direct Mode on Service Track: CV3.
[B4 7F 01 35] Unable to parse LocoNet message.
[E7 0E 7C 2B 04 00 00 07 00 02 00 7F 7F 40] Programming Response: Read Byte in Direct Mode on Service Track Failed, Read Compare Acknowledge not detected: CV3 value 0 (0x00, 00000000b).
---
Program JMRI tam ma chybu, protoze LACK je spravne, presne podle normy.
Odpoved je failed, protoze jsem nemel pripojenou kolej.

Neviem, ci ma JMRI chybu, ale aj norma si protireci, lebo pre LACK by malo byt pre message 0xEF odpoved 0x6F (nie 0x7F), ale je tam "vynimka" pre message 0xEF, kde sa ocakava odpovet 0x7F.......
A co potom "vynimky" pre message 0xED (mozno Daisy2 nepotrebuje LACK.....)
A ak chce JMRI fungovat spravne so vsetkymi HW, musi mat "pochopenie" pre tieto vynimky....

[zdeno]

odpoved LACK neni chybova sprava, kde se rusi 7 bit v odpovedi
Toto je odpoved centraly na znak prijmu paketu pro programovani CV.
This OPC leads to immediate LACK codes:
<B4>,<7F>,<7F>,<chk> Function NOT implemented, no reply. chyba
<B4>,<7F>,<0>,<chk> Programmer BUSY , task aborted, no reply. chyba
<B4>,<7F>,<1>,<chk> Task accepted , <E7> reply at completion. toto je oznameni, ze bude nasledovat E7
<B4>,<7F>,<0x40>,<chk> Task accepted blind NO <E7> reply at completion. toto je oznameni, ze je to OPS programovani a nebude E7 vysilane
---
jeste mne zaujmula hlaska Direct Byte Mode from PT for Uhlenbrock IB-COM
toto nepoznam a nevidel jsem to nikde zverejnene, to bude zase interni zhovadilost od Uhlenbrock nebo od Tillig.

[sidlo]

1. Uhlenbrock nekomunikuje s JMRI
2. Někdo si dal tu práci a Reverse engineering udělal podporu pro IntelliBox
3. Uhlenbrock změnil způsob komunikace na Daisy II

Je to chyba JMRI?

Např. chování Digikeijs je úplně jiné. Zřejmě u Digikeijs stojí o uživatele JMRI.

[belgarat]

Sidlo: ano, je "chyba" JMRI, ze se neadaptovalo. https://www.jmri.org/help/en/html/hardware/index.shtml rika, ze Uhlenbrock resp. IntelliBox patri mezi podporovany HW. Tak pokud Uhlenbrock zmenil chovani, zadejte issue, protoze projekt JMRI o te zmene mozna jeste nevi ... Ve vysledku je sumak kdo komu bori babovicky, pocita se vysledek (= nefunkcni rizeni).

V realnem svete je bezne, ze 3rd party uzite (integrovane) projekty delaji nekompatibilni zmeny, a jsou tak nanejvys napsane nekde v README, pokud vubec; patri k dobremu tonu SW se prizpusobit, pokud rikam (dokumentuji) ze projekt (hardware) podporuji. Vyrobce HW (nebo Microsoft, Oracle, SAP) ke slusnosti neprinutis.

[sidlo]

Sidlo: ano, je "chyba" JMRI, ze se neadaptovalo. https://www.jmri.org/help/en/html/hardware/index.shtml rika, ze Uhlenbrock resp. IntelliBox patri mezi podporovany HW.

Na té stránce je podpora pouze cetrál IntelliBox.

JMRI nená povinnost se na nikoho adaptovat. Je věcí Uhlenbrock jaké zákazníky chce a jaké nechce.

Kolegovi nefunguje Daisy II. A zřejmě se nenašel žádný uživatel Daisy II, který by podporu dodělal. A proč by se s tím trápil, když stejně na něj bude Uhlenbrock kašlat.

Jen tak mimochodem. Ještě nedávno byla na groups.yahoo.com diskusní skupina IBX o centrálách Uhlenbrox. Skupina neměla nic společného s JMRI. Skupina byla zrušena. V posledním roce skomírajícího provozu zůstaly všechny zde podané dotazy bez odpovědi. To jenom na dokreslení toho jak se Uhlenbrock o své skutečné zákazníky stará.

<jízlivost stav="neber to vážně" podpora_Uhlenbrock="žádná"> Nabídni se nešťastnému kolegovi, že to naprogramuješ. </jízlivost>

[belgarat]

Nerikam povinnost ... proste "byva zvykem", ze kdyz uz je neco zdokumentovane, ze to funguje, tak se o to (obvykle) "nekdo" stara, a hodit issue na github je rozumny zpusob jak ho probudit - pokud se jeste stara. Tak to funguje i u jinych projektu; proto jsem taky psal "chyba" v uvozovkach - jen malokdo sleduje vystrelky a nove firmware, pokud treba sam neupgraduje.

O zajem Unhlenbrocku o uzivatele, nedej Boze projekty, ze kterych jim nekouka zisk se nehadam, ale o to tu nejde. Jen rikam, ze je _bezne_ ze se software rozbiji, prave na tech integracnich rozhranich. A to prosim i neumyslne.

ad jizlivost: nabidnout nemuzu, protoze (a) nemam patricny HW, (b) kdybych MEL cas, tak je kosile blizsi nez kabat, a opravuju ty nejvetsi blbosti co reportuji na githubu. A bohuzel (c) JMRI je tak "zachybovane" nedodrzovanim specifikaci,postupu jazyka a prostredi ve kterem se SAMI rozhodli ten software psat, ze je v podstate neopravitelne.

P.S.: v noci jsem se snazil "nejak" nadefinovat Warrant, a mam zase 6-8 bug reportu ... tu vybehne chyba (chybne, zadna chyba neni), tu se najednou edit box v tabulce presune uplne do jineho radku (kdo by cekal, ze TAB preusporada tabulku, ale vyber zustane na stejnem x,y - takze opravovany radek ujede kamsi dopryc...). Legrace: dokonce mi pri mereni rychlosti "throttle" pro lokomotivu nejak zahadne neovladalo NIC ani neposilalo packety na zadnem ze spojeni (v monitoru prazdno)... po nekolika restartech "to" zahadne zmizelo, takze ani zadny bug report, proste jen ztraceny cas.

[Mafo]

odpoved LACK neni chybova sprava, kde se rusi 7 bit v odpovedi
Toto je odpoved centraly na znak prijmu paketu pro programovani CV.
This OPC leads to immediate LACK codes:
<B4>,<7F>,<7F>,<chk> Function NOT implemented, no reply. chyba
<B4>,<7F>,<0>,<chk> Programmer BUSY , task aborted, no reply. chyba
<B4>,<7F>,<1>,<chk> Task accepted , <E7> reply at completion. toto je oznameni, ze bude nasledovat E7
<B4>,<7F>,<0x40>,<chk> Task accepted blind NO <E7> reply at completion. toto je oznameni, ze je to OPS programovani a nebude E7 vysilane
---
jeste mne zaujmula hlaska Direct Byte Mode from PT for Uhlenbrock IB-COM
toto nepoznam a nevidel jsem to nikde zverejnene, to bude zase interni zhovadilost od Uhlenbrock nebo od Tillig.

Aha. Takze ked si presne definujem message 0xB4 ako:
<0xB4>,<LOPC>,<ACK1>,<CHK> Long acknowledge
<LOPC> is COPY of OPCODE responding to (msb=0).
.....

a potom (o cca 4 strany dalej v spec.) si spravim "vynimku" s 0x7F, tak je to uplne v poriadku.....


PT je asi "Programming Track" a je to to iste ako "Service Track", len v ruzovom....

[zdeno]

to nejde, tak to nefunguje
paket s opcode B4 pouze oznamuje, ze centrala prevzala paket EF a bude s nim pracovat. To muze trvat podle zpusobu vycteni nebo zapisu aj nekolik desitek vterin a proto je zadouci, aby se vedelo, ze se s tim pracuje.
Teda ACK1 tam nema co delat, musi tam byt "1", pokud chces odpoved E7 !!
---
Je vubec nekde zdokumentovany paket s opcode 0xED a delkou 0x1F ??

[belgarat]

Mam dotaz k JMRI. Podle navodu https://sites.google.com/site/sidloweb/ ... web-server jsem si nastavil web server; zatim mam jen Layout (ne Panel). Decka maji k dispozici sve dotykace a jeden krouzkovy tablet. Minimalne tablet ma jinou velikost obrazovky nez ty dotykace. Dotykace namirim na web stranky /frames.

Zjistil jsem, ze upravou Zoom faktoru na PC se mi zvetsi i display na dotykacich. Da se nejak zaridit, aby se u pristupu na web rozsiril obrazek "podle formatu okna" (obrazovky), nebo se ma na kazdem zarizeni "zoomovat" podle potreby ?

Jaky rezim vykreslovani pro "bezne jezdeni" doporucujes: pomoci /frames, nebo pomoci panelu ?