Moderní protokoly digitálního řízení

[Brejla]

Nojo chybička se vloudí ale na obsahu to nic nemění.

A nebylo by lepší čas věnovaný ironii a urážkám druhých věnovat alespoň mírnému zdokonalení mateřského jazyka

Nikoho jsem neurážel. Psal jsem pravdu. Takže odpověď na tvoji otázku je ne nebylo.

Sebevědomí na úrovni značně vysoké, znalosti na úrovni podstatně nižší ...

[Edys]

Sebevědomí na úrovni značně vysoké, znalosti na úrovni podstatně nižší ...

Ale nepovídej. Otázka je u koho....

[fulda]

Opět se pleteš. Tentokrát mícháš SMB a NetBIOS/NetBEUI

To je celkem možné, už více než 20 let tyto znalosti nepoužívám. Ale zdá se, že je mám pořád na dostatečné úrovni, abych tu mohl popsat základní podstatu.

Mohl by jsi tedy rozvést detailněji jak ta věc funguje, jestli by nebyla použitelná? Jde o to, aby se minimalizovala potřeba broadcast a multicast zpráv a pokud možno se také držel počet komunikujících párů na přijatelné úrovni.

[HonzaM]

Nojo chybička se vloudí ale na obsahu to nic nemění.

A nebylo by lepší čas věnovaný ironii a urážkám druhých věnovat alespoň mírnému zdokonalení mateřského jazyka

Jseš si jist, že v žádném ze svých příspěvků nemáš žádný překlep nebo gramatickou chybu? Podstatný je obsah, i když se mi občas ježí vlasy nad tím, co někteří pisatelé dokážou napsat, nejen nějaká měkká nebo tvrdá i, o shodě podmětu s přísudkem nebo interpunkci ani nemluvě. Občas to vypadá, že neprošli ani základní školou. Ale tahle diskuze není jazyková poradna.

[Edys]

Opět se pleteš. Tentokrát mícháš SMB a NetBIOS/NetBEUI

To je celkem možné, už více než 20 let tyto znalosti nepoužívám. Ale zdá se, že je mám pořád na dostatečné úrovni, abych tu mohl popsat základní podstatu.

Mohl by jsi tedy rozvést detailněji jak ta věc funguje, jestli by nebyla použitelná? Jde o to, aby se minimalizovala potřeba broadcast a multicast zpráv a pokud možno se také držel počet komunikujících párů na přijatelné úrovni.

To je právě ten problém tvého nápadu (teď to nechápej jako ironii) způsob komunikace který se snažíš na to použít je nevhodný právě pro svou podstatu fungování. Zeptám se všech jeden odpová pak si povídám s ním. To vše znovu a znovu. Právě proto kluci řešily IP adresy. Protože zasílat něco přímo na danou adresu je nejrychlejší a nejspolehlivější.
Já nevím jak to nejlépe vyřesit ale nikdy jsem netvrdil že to vím.

[Rudolf]

Pokud se už bavíme o TCP/IP co sáhnout k ověřeným věcem ? Centrála bude umět DHCP a DNS, každý dekodér bude mít v sobě adresu = jméno v DNS a je to. Jakou dostane přiřazenou IP adresu pak už nebude zajímavé...

Ruda

[Edys]

Pokud se už bavíme o TCP/IP co sáhnout k ověřeným věcem ? Centrála bude umět DHCP a DNS, každý dekodér bude mít v sobě adresu = jméno v DNS a je to. Jakou dostane přiřazenou IP adresu pak už nebude zajímavé...

Ruda

S tím se nedá než souhlasit. Ale schází tu ten podstatný příspěvek zdena ke kterému vznikla tato diskuze.
viewtopic.php?f=6&t=9958#p229665

[zdeno]

No právě. Zkus mi popsat, jak zabezpečíš, aby příkaz "Návěstidlo S1 na volno" šel vždy na to samé návěstidlo, když jednou to bude 192.168.4.123 a po druhé už třeba ....138. Kde budeš mít přiřazení "vláčkové" adresy k adrese IP?

Uplne zle uvazovani,
ESP01 slouzi jen jako komunikacni uzel, ne jako koncove zarizeni, Teda IP adresu ma jen dvojice ESP01 a vsechny zarizeni za tim uz maji adresu prislusenstvi Loconet nebo prislusenstvi DCC.
Neni teda dulezita IP adresa, ale obsah spravy, ktera se prenasi pres WiFi.
Priklad:
poslem paket <B0 01 31 EE> z IP adresy 192.168.4.100 na adresu IP 168.192.4.101 a kde to ESP01 odevzda procesoru, ktery uz zaridi vse potrebne.
Tady je vyhoda, ze to neposila do Loconet sbernice, ale primo se vykona prikaz podle dat v paketu.
Taky se muze poslat prikaz DCC, ktery nasledne vyhodnoti dekoder DCC prikazu a dokaze je spracovat primo v procesoru prislusenstvi.
Tady bude problem napajeni a uprava DCC signalu na spravny tvar.

[Edys]

No právě. Zkus mi popsat, jak zabezpečíš, aby příkaz "Návěstidlo S1 na volno" šel vždy na to samé návěstidlo, když jednou to bude 192.168.4.123 a po druhé už třeba ....138. Kde budeš mít přiřazení "vláčkové" adresy k adrese IP?

Uplne zle uvazovani,
ESP01 slouzi jen jako komunikacni uzel, ne jako koncove zarizeni, Teda IP adresu ma jen dvojice ESP01 a vsechny zarizeni za tim uz maji adresu prislusenstvi Loconet nebo prislusenstvi DCC.
Neni teda dulezita IP adresa, ale obsah spravy, ktera se prenasi pres WiFi.
Priklad:
poslem paket <B0 01 31 EE> z IP adresy 192.168.4.100 na adresu IP 168.192.4.101 a kde to ESP01 odevzda procesoru, ktery uz zaridi vse potrebne.
Tady je vyhoda, ze to neposila do Loconet sbernice, ale primo se vykona prikaz podle dat v paketu.
Taky se muze poslat prikaz DCC < 10AAAAAA, 1AAACDDD, EEEEEEEE>, ktery nasledne dekoder DCC prikazu, dokaze spracovat data primo v procesoru
Tady bude problem napajeni.

když budeš mít více esp01 tak co bude vědět že esp01A má adresu 192.168.1.101 a za ní takové a makové DCC zařízení.
Jinak myšlenka se mě jako taková líbí

[zdeno]

když budeš mít více esp01 tak co bude vědět že esp01A má adresu 192.168.1.101 a za ní takové a makové DCC zařízení.
Jinak myšlenka se mě jako taková líbí

Zajimave, to mne nenapadlo, vsak je to ve vyvoji.
Teda bude muset byt tabulka, jake adresy prislusenstvi jsou schovane za konkretni IP adresou.
Anebo se na kazde STA posila vsechno aktualne a to si samo vybere to svoje.
To znamena, ze pri kazdem prihlaseni STA na AP se bude muset AP podivat, jake ma data na vysilani a vybrat ta jeste nevysilana na konkretni IP adresu.
---
Jinak adresa AP je trvala a nemeni se.
Pokud se STA prihlasi, tak se prihlasi adresou IP a tak si samo urci, jake adresy prislusenstvi se mohou poslat.
Anebo se poslou jen ty, ktere jsou nove.
---
Tady mi docvaklo, ze sbernice Xpressnet a jeji klony neumi primo adresovat prislusenstvi.
To by chtelo dobreho znalce Xpressnet a jeho klonu na to, jak by se to dalo pouzit ??
Pouzivani konverze do DCC asi nebude to prave orechove.
Taky zpetna vazba bude asi problem. To by si museli vyresit sami.

[fulda]

Protože zasílat něco přímo na danou adresu je nejrychlejší a nejspolehlivější.
Já nevím jak to nejlépe vyřesit ale nikdy jsem netvrdil že to vím.

To ano, nemusí se komunikovat neustále broadcastem. Prostě se nějak určí kdo spravuje jména a kdo je tím "DNS" a také se nějak určí TTL (jak dlouho je jméno platné). Pak si každý může ukládat informaci a je to.

[Jirka_US]

To se hodí, protože na MRH vyšel nový článek o "Universal" Wi-Fi Throttle i videem (bez článku).

Jirka_US: už jí podporuje +-DCC?

Ano, samozrejme je to preci zrejme z kontextu toho videa. V obdobne konfiguraci, ktera je v tom videu detailne popsana (LocoNet), tedy s prislusnym HW lze provozovat DCC++, NCE, startset s mysi MM a dokonce s pravdepodobnosti hranicici temer s jistotou bude fungovat i s NanoX.

[Jirka_US]

Me reseni pro konfiguraci modulu s nekolika stanicemi nebo pro velke kolejiste pouziva misto ESP01 RPi zero a to vzhledem k cene, spolehlivosti a vykonu. Zvolil jsem verzi w, ktera ma jiz WiFi modul a BT chip primo na desce MB. JMRI faceless rezim zaridi vse okolo WiFi, takze uzivatel - modelar jen standardne programuje adresy prislusenstvi v tabulce JMRI. Zadne zpozdeni vzhledem k potrebam zel. modelare jsem nezaznamenal. Takze kazda stanice na modulu bude mit vlastni uzel s RPi na ovladani prislusenstvi a vstupy senzoru. Navic vzhledem k vykonu na rozdil od ESP01 lze nechat bezet na JMRI celou zabezpecovaci logiku ( Logix ) prislusneho nadrazi vcetne prislusneho ovladaciho pultu. Osobne radeji pouzivam jako IO porty ( obdoba LocoIO ) primo desku Arduina od DCC++, tedy bez motor shieldu.Je mozne usetrit ca.$3 za Arduino, pokud se pouziji primo IO porty RPi, jen pozor na logiku 3.3V.

[zdeno]

Me reseni pro konfiguraci modulu s nekolika stanicemi nebo pro velke kolejiste pouziva misto ESP01 RPi zero ......

co z toho mas realne odzkousene a otestovane ??

[Jirka_US]

Vse co je napsano vyse s vyhradou posledni vety. Tj. primy pristup na IO porty jsem vyzkousel (je treba se logovat k JMRI jako super user) a rozhodl z ciste praktickych duvodu pouzivat IO porty Arduina z DCC++ byt to stoji nejaky ten dolar navic.
Obecne plati, ze i u DCC++ v JMRI dochazi k vyvoji a obcas se vyskytne nejaka chyba ( stejne jako u jinych systemu ), ktera je v ramci prislusneho "release" opravena.
Mozna stoji za zminku, ze cely system/architektura krome DCC++ (tedy nekolik RPi) byl zkousen s LocoNetem a XpresNetem (LZV100 a startset MM ) a kombinaci techto systemu.

Je vyse popsane reseni neco co te zajima ? Potrebujes nejake detaily ? Komunita DCC++ a JMRI urcite oceni pokud se ti podari najit nejakou chybu popr. navrhy na zlepseni.