RailCom

[jamik22]

To Trixt:

Lokomotivu ručně odpojím a pomocí multimouse (ručně aniž bych sahal do programu) s ní přejedu do bloku B.

Martin je TC purista a ovládání mobilem nemá rád To co popsal je samozřejmě OK, ale k odjetí do bloku B použil libovolnou funkci TC. Když odjedeš mobilem, tak ikona loko zůstane v bloku A a ten nebude obsazený, ale stále zarezervovaný. Tady plánem nebo Autotrainem do něj nevjedeš. Obsazený bude blok B, ale bez ikony. /srovná se to přetažením ikony myší v TC/ Zde by nejspíš Railcom pomohl tomu kdo chce jezdit tímto kombinovaným způsobem. Vyzkoušet to nemohu, protože mám centrálu a booster LENZ.
to HonzaM:

Celý postup je na stránkách 333 - 336 manuálu. TC umožňuje současné používání až 12 digitálních systémů, lze tedy použit RailCom dekodéry i na kolejišti provozovaném třeba s komponentami Lenz.

Bohužel ne s LENZ centrálou. LRC120 od Lenz je jen blbý displej, který do centrály nic neposílá. TC to ví a v Setup digi sytému možnost aktivace Railcom pro Lenz správně ani nenabídne ma rozdíl třeba od centrály LDT nebo jiných. Takže jsem si rozšířil obzory a tím to pro mne končí. Centrálu měnit neplánuji

[HonzaM]

LRC120 od Lenz je jen blbý displej, který do centrály nic neposílá. TC to ví a v Setup digi sytému možnost aktivace Railcom pro Lenz správně ani nenabídne ma rozdíl třeba od centrály LDT nebo jiných. Takže jsem si rozšířil obzory a tím to pro mne končí. Centrálu měnit neplánuji

A existují i jiné LENZ centrály? Nebo jsou snad všechny Lenz cenrály "jen blbý displej"?

[sidlo]

Honzo, špatně jsi to pochopil. Centrály od Lenz jsou kvalitní, proto je jamik22 nechce měnit.
Lenz LRC120 není centrála. Je přídavné zařízení pro čtení RailCom. Umí zobrazit adresu dekodéru v úseku, ale neumí ji poslat do počítače.

[Trixt]

Když odjedeš mobilem, tak ikona loko zůstane v bloku A a ten nebude obsazený, ale stále zarezervovaný. Tady plánem nebo Autotrainem do něj nevjedeš. Obsazený bude blok B, ale bez ikony.

Díky moc za upřesnění. Popravdě jsem moc nechápal, jak to TC dokázal.

[HonzaM]

Honzo, špatně jsi to pochopil. Centrály od Lenz jsou kvalitní, proto je jamik22 nechce měnit.
Lenz LRC120 není centrála. Je přídavné zařízení pro čtení RailCom. Umí zobrazit adresu dekodéru v úseku, ale neumí ji poslat do počítače.

Díky za upřesnění. Uvítal bych, kdyby někdo s kolejištěm s centrálou Lenz a řízeným TrainControllerem vyzkoušel možnost doplnění RailCom dekodérem. Mohu k tomu zapůjčit a následně v případě zájmu za výhodnou cenu nabídnout dekodér DR5088RC a centrálu DR5000.

[zdeno]

Mohu k tomu zapůjčit a následně v případě zájmu za výhodnou cenu nabídnout dekodér DR5088RC a centrálu DR5000.

puvodne bylo toto vlakno vytvorene proto, aby se zjistilo, jak RailCom funguje.
Pokud nekdo vi, jak to funguje, tak bych poprosil o informace ??
---
Urcite jsem nechtel, aby se to zvrhlo na prezentaci vyrobku !!

[Pater]

puvodne bylo toto vlakno vytvorene proto, aby se zjistilo, jak RailCom funguje.
Pokud nekdo vi, jak to funguje, tak bych poprosil o informace ??

Vím jen to, co si lze přečíst zde:https://dccwiki.com/Term:RailCom
Takže stručně asi tento překlad:
Detektor - výřezové zařízení, které odpojuje DCC signál od koleje. Tento výřez trvá 488 mikrosekund (0,488 milisekundy). Tento výřez je tak krátký, že nezpůsobuje problémy s multifunkčními dekodéry.
Aby přenos dat fungoval, musí systém přerušit napájení trati mezi pakety DCC . Tato doba odpojení se nazývá výřez . Interval přenosu je rozdělen na dva kanály. Každý kanál lze použít samostatně.
Během „výřezu“ je generován signál +/− 30 mA skládající se ze dvou nebo čtyř bajtů. Proud 10 mA je považován za „nulu“ a proud menší než 6 mA za 1.
Detektor má velmi nízkou vstupní impedanci (téměř zkrat), jakékoli jiné impedance v obvodu budou mít malý vliv na výsledný proudový signál.
Bezprostředně před provedením výřezu vysílá příkazová stanice kompatibilní s RailCom Idle Packet. To signalizuje multifunkčnímu dekodéru umožňujícímu RailCom, že bude následovat výřez.
RailCom používá dva kanály nebo sloty. Multifunkční dekodér s podporou RailCom nebude vysílat během výřezové periody, pokud nebyl adresován bezprostředně před výřezem. Tyto dva kanály umožňují reakci ze dvou multifunkčních dekodérů ve stejné energetické oblasti. K těmto přenosům dochází současně. Pokud nebyly adresovány multifunkční dekodéry, nebudou reagovat.
Pomocí funkce Address Broadcast budou multifunkční dekodéry vysílat své adresy, ale pouze pomocí slotu jedna. Pokud je v prvním slotu aktivních více multifunkčních dekodérů, výsledkem je smetí. Veškerá data ve druhém slotu budou čitelná a budou přenášena multifunkčním dekodérem, který byl adresován. Pokud neznámá lokomotiva vjede do napájené oblasti, může vyslat svou adresu a zaregistrovat svou přítomnost.

[mpinta]

Omlouvám se, moje blbost. TC rozhodně degradovat nechci, z hlediska přijemnosti pro uživatele je to podle mne nejlepší systém. JMRI sice umožňuje možná něco navíc, ale naprogramování je náročnější. Beru Martinovu připomínku a napříště si budu vše nejprve prakticky ověřovat.

Omluva přijata.

[Raww]

No, jestli tedy chápu vše správně, tak mi to potvrzuje to, co jsem si nastudoval a to proč to chci - systém řízení provozu (TC) si zcela sám zdetekuje všechny loko, které jsou kompatibilní s RailComem a softwarově si je "umístí" do kolejiště. Tudíž pokud například ručně kamkoli nasadím loko, tak systému nemusím nic říkat, protože ji zkomunikuje a přiřadí si ji na kolejiště. Stejně tak, když budu jezdit ručně na MM bez TrainControlleru a vlaky rozestrkám kamkoli a následně spustím TC, tak ten bude schopen se sám sesynchronizovat.
Dle info dřívě je tedy např. TrainController schopen přesně detekovat i více lokomotiv v jednom úseku.
Bez této detekce musím systému lokomotivu v obsazeném úseku označit a on si ji pak hlídá pouze softwarově podle toho, který úsek se nově obsadí/uvolní.
Je to tak?

[sidlo]

systém řízení provozu (TC) si zcela sám zdetekuje všechny loko, které jsou kompatibilní s RailComem a softwarově si je "umístí" do kolejiště. Tudíž pokud například ručně kamkoli nasadím loko, tak systému nemusím nic říkat

To platí pouze v případě, že úplně všechny úseky na kolejišti mají detekci RailCom. Poznámka - detekce obsazení stojí asi 50 Kč na jeden úsek, detekce s RailCom stojí asi 6,25 € na jeden úsek, tedy 3× více.

Dle info dřívě je tedy např. TrainController schopen přesně detekovat i více lokomotiv v jednom úseku.

Jak bylo řečeno, TC není schopen přesně detekovat více lokomotiv v jednom úseku. Je toho schopen pouze v případech kdy byly splněny přesně stanovené podmínky.

[zdeno]

Proud 10 mA je považován za „nulu“ a proud menší než 6 mA za 1.

Predpokladam, ze proud na tyto impulsy dodava motorcek, ktery teda musi byt v chodu.
Jak vysila stojici loko ??

[HonzaM]

systém řízení provozu (TC) si zcela sám zdetekuje všechny loko, které jsou kompatibilní s RailComem a softwarově si je "umístí" do kolejiště. Tudíž pokud například ručně kamkoli nasadím loko, tak systému nemusím nic říkat

To platí pouze v případě, že úplně všechny úseky na kolejišti mají detekci RailCom. Poznámka - detekce obsazení stojí asi 50 Kč na jeden úsek, detekce s RailCom stojí asi 6,25 € na jeden úsek, tedy 3× více.

Dle info dřívě je tedy např. TrainController schopen přesně detekovat i více lokomotiv v jednom úseku.

Jak bylo řečeno, TC není schopen přesně detekovat více lokomotiv v jednom úseku. Je toho schopen pouze v případech kdy byly splněny přesně stanovené podmínky.

Jaký je vztah JMRI - RailCom? A umožňuje v jednom úseku detekovat více lokomotiv?
Pokud jde o cenu detekce, záleží na tom, jaký dekodér budu používat. Při použití S88/DR4088 to na jeden úsek bude 70 Kč, při DR4088LN (LocoNet) 87 Kč, při DR4088RB (R-bus) 82 Kč, při DR5088RC (RailCom) 123 Kč. Jako propastný rozdíl mi to nepřipadá.

[sidlo]

Jaký je vztah JMRI - RailCom?

JMRI na rozdíl od jiných systémů přistupuje ke sledování stavu kolejiště mnohem komplexněji než např. TrainController.
V JMRI se čtení z kolejiště nazývá Reporter. Reporter je zvláštní objekt, na rozdíl of TC kde je to pouze atribut bloku. Podobně jako snímač je v JMRI samostatný objekt a v TC je to atribut bloku. Mít snímače a RailCom jako atributy bloku je pro začátečníky jednodušší na pochopení, ale zároveň je to limitující pro jiné než výrobcem zamýšlené použití.
Reporter mimo RailCom podporuje též systémy Digitrax Transponders a různé typy RFID.
K jednomu bloku lze přímo připojit jeden Reporter, ale pomocí Logix nebo Jython se to dá předělat k obrazu svému.
Na rozdíl od jiných systémů má Reporter více stavů. Reporter umí hlásit tento objekt vidím, tento objekt nevidím, tento objekt jsem viděl, tento objekt jsem neviděl. To dává zkušenému uživateli mnohem více možností než jiné jednodušší systémy.

[mpinta]

Jaký je vztah JMRI - RailCom?

JMRI na rozdíl od jiných systémů přistupuje ke sledování stavu kolejiště mnohem komplexněji než např. TrainController.
V JMRI se čtení z kolejiště nazývá Reporter. Reporter je zvláštní objekt, na rozdíl of TC kde je to pouze atribut bloku. Podobně jako snímač je v JMRI samostatný objekt a v TC je to atribut bloku. Mít snímače a RailCom jako atributy bloku je pro začátečníky jednodušší na pochopení, ale zároveň je to limitující pro jiné než výrobcem zamýšlené použití.
Reporter mimo RailCom podporuje též systémy Digitrax Transponders a různé typy RFID.
K jednomu bloku lze přímo připojit jeden Reporter, ale pomocí Logix nebo Jython se to dá předělat k obrazu svému.
Na rozdíl od jiných systémů má Reporter více stavů. Reporter umí hlásit tento objekt vidím, tento objekt nevidím, tento objekt jsem viděl, tento objekt jsem neviděl. To dává zkušenému uživateli mnohem více možností než jiné jednodušší systémy.

Už mě nebaví pořád vyvracet nesmysly o TrainControlleru těm, kteří ho prostě neznají. Petře, moc tě prosím, drž se JMRI a nech TC na pokoji. To, co tady o TC uvádíš, jsou zcela chybné informace.

[sidlo]

Uveď informace správné.