Proč nemám rád LocoNet

[JenikPluto]

[BC 02 00 41] Request status of switch LT3 ().
[B4 3C 50 27] LONG_ACK: Command station response to switch state request 0x50 (Thrown).
[B0 02 30 7D] Requesting Switch at LT3 to Closed (Output On).

Asi blby dotaz, v Loconetu tak uplne zbehly nejsem, ale co je spatne na nasledujicim prekladu:

[BC 02 00 41] - jakou polohu ma vyhybka, jejiz adresa je 02 (dolni bajt) 00 (horni bajt)
[B4 3C 50 27] - potvrzuji dotaz na stav vyhybky
[B0 02 30 7D] - vyhybka s adresou 02 (dolni bajt) 00 (horni bajt) ma stav closed a je aktivni (prvni ctyri bity SW2 je zbytek adresy, 5. bit stav vyhybky - 0=off, 1=on, 6. bit 1/0 = closed/thrown, cili 0 + 48 (dec) - 30 (hex)).

Sice nevim, kdo se pta, ale vim, stav ceho je reportovany, ne?

Budu rad, kdyz mi nekdo vysvetli, v cem je muj preklad spatne.

Diky.

JP

[fulda]

[BC 02 00 41] Request status of switch LT3 ().
[B4 3C 50 27] LONG_ACK: Command station response to switch state request 0x50 (Thrown).
[B0 02 30 7D] Requesting Switch at LT3 to Closed (Output On).

Asi blby dotaz, v Loconetu tak uplne zbehly nejsem, ale co je spatne na nasledujicim prekladu:

[BC 02 00 41] - jakou polohu ma vyhybka, jejiz adresa je 02 (dolni bajt) 00 (horni bajt)
[B4 3C 50 27] - potvrzuji dotaz na stav vyhybky
[B0 02 30 7D] - vyhybka s adresou 02 (dolni bajt) 00 (horni bajt) ma stav closed a je aktivni (prvni ctyri bity SW2 je zbytek adresy, 5. bit stav vyhybky - 0=off, 1=on, 6. bit 1/0 = closed/thrown, cili 0 + 48 (dec) - 30 (hex)).

Sice nevim, kdo se pta, ale vim, stav ceho je reportovany, ne?

Budu rad, kdyz mi nekdo vysvetli, v cem je muj preklad spatne.

Diky.

JP

Nenech se zmást, dotaz je první řádek a odpověď na něj je druhý řádek (červeně), třetí řádek (modře) je nový příkaz pro výhybku, aby se uvedla do nového stavu, ten mohl vzniknout až mnohem později, když někdo zmáčkl tlačítko na ovladači.

[JenikPluto]

[BC 02 00 41] Request status of switch LT3 ().
[B4 3C 50 27] LONG_ACK: Command station response to switch state request 0x50 (Thrown).
[B0 02 30 7D] Requesting Switch at LT3 to Closed (Output On).

Asi blby dotaz, v Loconetu tak uplne zbehly nejsem, ale co je spatne na nasledujicim prekladu:

[BC 02 00 41] - jakou polohu ma vyhybka, jejiz adresa je 02 (dolni bajt) 00 (horni bajt)
[B4 3C 50 27] - potvrzuji dotaz na stav vyhybky
[B0 02 30 7D] - vyhybka s adresou 02 (dolni bajt) 00 (horni bajt) ma stav closed a je aktivni (prvni ctyri bity SW2 je zbytek adresy, 5. bit stav vyhybky - 0=off, 1=on, 6. bit 1/0 = closed/thrown, cili 0 + 48 (dec) - 30 (hex)).

Sice nevim, kdo se pta, ale vim, stav ceho je reportovany, ne?

Budu rad, kdyz mi nekdo vysvetli, v cem je muj preklad spatne.

Diky.

JP

Nenech se zmást, dotaz je první řádek a odpověď na něj je druhý řádek (červeně), třetí řádek (modře) je nový příkaz pro výhybku, aby se uvedla do nového stavu, ten mohl vzniknout až mnohem později, když někdo zmáčkl tlačítko na ovladači.

Aha, OK, takze by to melo spis byt [B1 02 20 nejaky checksum]?

JP

[fulda]

[BC 02 00 41] Request status of switch LT3 ().
[B4 3C 50 27] LONG_ACK: Command station response to switch state request 0x50 (Thrown).

... a abychom si ujasnili situaci, tak připojím ještě obrázek té komunikace.

Je to z ovladače, který se ptá centrály, takže TX toho prvního řádku a za 2-3ms dostane RX toho druhého řádku.

Proč je ten čas tak zásadní je proto, že za 1,260ms může začít komunikovat jakékoli jiné zařízení a může s zeptat na úplně jinou výhybku.

[belgarat]

Sice nevim, kdo se pta, ale vim, stav ceho je reportovany, ne?
Budu rad, kdyz mi nekdo vysvetli, v cem je muj preklad spatne.

"Kdo" se pta je asi jedno. Ale prislo mi, ze v odpovedi je pouze stav, ale v odpovedi neni zopakovano ID vyhybky pro kterou ten stav plati. Pokud je to tak, ve chvili kdy se pta vice nez 1 zarizeni se muzou "spatne sejit" (race condition) a z odpovedi pak nejde korektne rekonstruovat co a v jakem je .

Edit: ano, podobne jak pise Fulda jsem pochopil 3. radek jako pozadavek na zmenu na Closed, pote, co ovladac (treba po stisku tlacitka) nejprve zjistil, ze vyhybka je Thrown (dotaz a odpoved). Ale predpoklad, ze odpoved "stav vyhybky je XX" patri k bezprostredne predchazejicimu packetu je myslim prilis silny.

[JenikPluto]

Sice nevim, kdo se pta, ale vim, stav ceho je reportovany, ne?
Budu rad, kdyz mi nekdo vysvetli, v cem je muj preklad spatne.

"Kdo" se pta je asi jedno. Ale prislo mi, ze v odpovedi je pouze stav, ale v odpovedi neni zopakovano ID vyhybky pro kterou ten stav plati. Pokud je to tak, ve chvili kdy se pta vice nez 1 zarizeni se muzou "spatne sejit" (race condition) a z odpovedi pak nejde korektne rekonstruovat co a v jakem je stavu

Ale jo, to celkem chapu, ale Loconet preci zna OPC_SW_REP, ktery se k tomu da pouzit nebo to chapu blbe? Asi si s tim zase budu muset zacit hrat...

JP

[belgarat]

Ale jo, to celkem chapu, ale Loconet preci zna OPC_SW_REP, ktery se k tomu da pouzit nebo to chapu blbe? Asi si s tim zase budu muset zacit hrat...

JP

Dej pak vedet; smysl to dava, ale v tak zvane "specifikaci" (proboha jak nekdo takovy car poznamek od Digitraxu muze povazovat za specku...) je pro command 0xBC narizena odpoved typu LACK, coz je ASI OPC_LONG_ACK (aspon v ramci 2 stranek by mohli byt konzistentni), tedy 0xB4. Coz odpovida zaznamenane komunikaci. Za jakych okolnosti smi, nebo musi zarizeni pouzit 0xB1 jsem ve specifikaci nenasel. A aby se dalo spolehnout na vysledky nezavisle na zarizeni, tak by 0xB1 musela byt povinna.

[fulda]

Bohužel se dá postupovat jen reverzně, tedy tak, že se podíváš, jak to to které konkrétní zařízení dělá. A když to zjistíš, tak se nemůžeš spolehnout na to, že to jiné nedělá jinak. Viz zdejší komentáře "no jo uhlenbrock*, ten si jde svou cestou a s tím mi nekamarádíme"

*) za slovo uhlenbrock si doplň kterékoli zařízení, u kterého se ukáže že s ním dílo nějakého autora nefunguje

[zdeno]

Bohužel se dá postupovat jen reverzně, tedy tak, že se podíváš, jak to to které konkrétní zařízení dělá. A když to zjistíš, tak se nemůžeš spolehnout na to, že to jiné nedělá jinak. Viz zdejší komentáře "no jo uhlenbrock*, ten si jde svou cestou a s tím mi nekamarádíme"

Je to tak a opravdu s tim my uzivatele nic neudelame. Pokud mas nejaky napad, tak se o nej podel
---
Zatim je situace takova, ze v EU vyhrava Uhlenbrock a teda jeho klony budou uspesnejsi. Teda USA Digitrax je na ustupu a bude cim dal vic v minorite.
Takze tvoje pripominky se vyresi tak nejak same a bude po problemu. To ale bude jeste chvili trvat. Nam to nevadi, a ty mas co kritizovat


dodatek:
jeste tu je moznost jako centraly DR5000 a Centrbox, ktere podporuji oba Loconet systemy a ty jsou za vodou.

[HonzaM]

Je to tak a opravdu s tim my uzivatele nic neudelame. Pokud mas nejaky napad, tak se o nej podel

Jak je zřejmé, Jindra s žádným nápadem pro využití LocoNetu nepřijde, spíš bude hledat důvody pro jeho odsouzení. Vždyť pro to založil toto téma.
---

Zatim je situace takova, ze v EU vyhrava Uhlenbrock a teda jeho klony budou uspesnejsi. Teda USA Digitrax je na ustupu a bude cim dal vic v minorite.
Takze tvoje pripominky se vyresi tak nejak same a bude po problemu. To ale bude jeste chvili trvat. Nam to nevadi, a ty mas co kritizovat

dodatek:
jeste tu je moznost jako centraly DR5000 a Centrbox, ktere podporuji oba Loconet systemy a ty jsou za vodou.

DR5000 má navíc možnost využívat jak komponenty Digitraxu (konkrétně mám ověřeno a používám SE8C a DS64), tak Uhlenbrocku, kromě toho ještě umí součaně s LocoNetem využívat i komponenty instalované na všech kolejištích kde se dosud používá Z21 i NanoX, na kolejišti není třeba nic měnit, lze zároveň používat ovladače LocoNetu (DT402, DT500, UT4) i Multimaus a také mobily a tablety i bezdrátový WLANmaus a všechny systémy zpetného hlášení. Má v nabídce "LocoNetové" komponenty DR5088RC, DR4088 LN, připravuje modul zpětné smyčky s detekcí obsazení DR5013 a ovládací panel pro dvě lokomotivy DR5022 a asi tedy LocoNet bude dál rozvíjet.

[JenikPluto]

Bohužel se dá postupovat jen reverzně, tedy tak, že se podíváš, jak to to které konkrétní zařízení dělá. A když to zjistíš, tak se nemůžeš spolehnout na to, že to jiné nedělá jinak. Viz zdejší komentáře "no jo uhlenbrock*, ten si jde svou cestou a s tím mi nekamarádíme"

*) za slovo uhlenbrock si doplň kterékoli zařízení, u kterého se ukáže že s ním dílo nějakého autora nefunguje

Zda se, ze alespon nektera zarizeni to tak delaji, viz http://clarahost.clara.net/www.bromsgro ... _18_12.pdf

Cili bych si tipnul, ze na OPC_SW_STATE reaguje OPC_LONG_ACK a pak vysila OPC_SW_REP. Z toho mi plyne, ze LN umi v principu odpovidat stylem "ja vyhybka XX hlasim polohu zavreno". Ze to nektera zarizeni neuvyuzivaji je vec druha. Ja to casem zkusim implantovat do nektereho z dekoderu a vyzkousim, jak to bude fungovat. Zatim jsem tam zpetny ohlas stavu nedaval, protoze ho nepotrebuju (Zephyr s nim neumi zachazet).

JP

[zdeno]

Opravdu by mne zajimalo, jak resite pocatecni stavy u vyhybek, ktere nemaji zpetnou vazbu ??
Teda po zapnuti tam jsou opravdu nahodne stavy.
Teda pokud to neni tvrdy analog, kde napeti primo urcuje stav vyhybky.
Ale pokud pouzivate tlacika, tak ani nahodou netusite, co tam je !!

[JenikPluto]

Opravdu by mne zajimalo, jak resite pocatecni stavy u vyhybek, ktere nemaji zpetnou vazbu ??
Teda po zapnuti tam jsou opravdu nahodne stavy.
Teda pokud to neni tvrdy analog, kde napeti primo urcuje stav vyhybky.
Ale pokud pouzivate tlacika, tak ani nahodou netusite, co tam je !!

Jestli je to otazka mirena na me, tak nijak, protoze LN dekodery pro prestavovani vyhybek nepouzivam (pouzivam tohle http://diskuze.modely.biz/viewtopic.php?f=7&t=6920#p194002). LN dekodery mam pro ovladani osvetleni budov, poulicniho osvetleni a lanovky, tam mam zpetnou vazbu jasnou (vizualni) a po zapnuti LN tam mam statisticky zatim 100% stav 0. Nicmene si dovedu predstavit, ze ani u vyhybek tam nemusi byt nutne nahodny stav, pokud si dekoder pamatuje posledni stav vyhybky pred vypnutim, do stejneho stavu ji prepne po svem znovuzapnuti. Nebo ne? Mam v planu nekdy v budoucnu cely ten Mega bazmek preklopit na LN, tak az se k tomu dostanu, tak to budu resit.

JP

[Jirka_US]

Nicmene si dovedu predstavit, ze ani u vyhybek tam nemusi byt nutne nahodny stav, pokud si dekoder pamatuje posledni stav vyhybky pred vypnutim, do stejneho stavu ji prepne po svem znovuzapnuti. Nebo ne?
JP

Presne tak a funguje to stejne tak u MM jako u ovladace LocoNetu (respektive DT4xx) jen s tim rozdilem, ze u DT4xx se LocoNet ujisti, jestli ty vyhybku nekdo pred chvili jeste neprehodil, coz MM nedela, jak jsme se presvedcili a pokud ty vyhybku nekdo u XpressNetu prehodil, kdyz nebyl ovladac pripojen k XpressNetu, tak na rozdil od LocoNetu ten ovladac XpressNetu zmenu nezaznamena. A OPC kod o kterem byla rec se tyka teto situace, tedy aby ovladac mel spravne nastaven symbol vyhybky. Pro ostatni pripady se pouziva OPC kod, ktery jsi zminil a adresa je tam zcela jednoznacna.A situace, kterou popisuje fulda, kdy by snad mohlo dojit behem 1.26ms k nejakemu jinemu dotazu je jak se ukazalo z praktickeho hlediska velmi malo pravdepodobna.
Pokud se tyka situace, kdy vyhybka dosud nikdy nebyla pouzita, tak jak u MM tak i u LocoNetu je to rozliseno tim, ze u MM sviti symbol vyhybky ukazujici oba smery soucasne, u DT4xx blika symbol c/t. Po prvnim znamem prehozeni si jiz system pamatuje polohu, tak jak popisujes.

[zdeno]

Jestli je to otazka mirena na me,

nebyla
---
pokud se podivas na predchozi diskuzi, tak hlavni kritika Loconetu spocivala na paketu s opcde BC, ktery je hodne kritizovany aj na jinych forech, nez jen BIZ.
Proste ten paket se moc nepouziva, protoze je blbe zadefinovany a jeho pouziti diskutabilni. To je proste fakt a nikdy jsem ho nezpochybnoval.
Co jsem zpochybnoval byla jeho dulezitost, kdy ho vlastne nikdo nepotrebuje a automatika se da udelat bez nej.
---
Proto mne zajimalo, jak se to obchazi s pouzitim dekoderu prislusenstvi na DCC, ktere jsou na tom podobne.
Tam taky nikdo nevi, jak byly nastaveny naposledy, po vypnuti napajeni. A to plati duplem pri pouziti tlacitek.