Kezdetben vala a Z21 (fekete, okos) és z21 (fehér, butább). A z21 egyszerűbb, olcsóbb hardver, "csak" XPressNettel és Ethernettel rendelkezik (meg persze foglaltságérzékeléssel), ami persze bőven elég, hogy az ember elprüntyögjön vele: kezdésnek van hozzá MultiMaus, aztán ha belejöttünk, rá lehet kötni PC-t is.
Később rájött a Roco, hogy az Ethernet tulajdonképpen egy olyan lehetőség, ami a szigorúan vett "kezdőfunkciókhoz" (egerekkel vonatokat irányítunk, váltókat váltogatunk) képest már Level 2., így el lehet kérni érte plusz pénzt. És megcsavarta a z21 firmware-ét: ugyanarra a hardverre már olyan firmware-t rakott, ami korlátozza az Ethernetet. A korlátozás feloldása pedig külön piaci termék lett (kartondobozba csomagolt kaparóssorsjegy-számkód, amit elegantosan "Freischaltkode"-nak, szabadra kapcsoló kódnak neveznek). A fentiekkel párhuzamosan a z21 neve z21Start lett.
Aztán a sima z21-et ki is futtatta a piacról, nehogy valaki ne akarja majd megvenni a kaparóssorsjegyet.
Szóval jelenleg, ha veszel egy z21Start-ot, azon rajta van ugyan az Ethernet-port, de "read only", azon csak küldi az infókat a z21, parancsokat nem fogad (talán a vész-állj a kivétel, meg persze a konfigurálás és , firmware-frissítés). Ennek megfelelően, mivel a mindenféle WiFi-s cucc Etherneten szeretne beszélgetni a z21-gyel, így egy nem aktivált z21Start-ról vissza fognak pattanni.
Ha a megvásárolt z21-ed mellé veszel egy kaparóssorsjegyet, majd a konfigurációs felületen a kóddal aktiválod a z21Startot, akkor a korábbi "sima" z21-gyel megegyező funkcionalitású központod lesz.
DigiTrainsPro app-ot szeretném használni z21- központtal. Routerem van amit tudnék majd használni. Digitools-os foglaltságjelzőt is tennék rá. Melyik központot keressem a "sima" vagy a "start"-ost. Mit jelent az, hogy meg kell venni a wifi kódot?
Ezzel a primitív megoldású foglaltságjelzővel nem nagyon van mit kezdeni.
Ugyanis - ahogy az előttem író is említette - nem tudsz érdemben beavatkozni. A két diódán esik 1,4V feszültség, ebből kell "gazdálkodni", hogy ebből mekkora áram jut az optocsatoló LED-jére. Nincs hol beavatkozni. Ez ilyen...
Vannak a piacon sokkal jobb, stabilabb, kezelhetőbb foglaltságjelzők. Igaz, azok nem 2-2db diódával detektálnak. Sajnos, hogy nagy nevű külföldi gyártók is használják ez a megoldást...:-(
Készítettünk egy segítséget az NMRA funkctions mapping-hez, meg a hosszúcímhez, meg a consist módhoz, hogy pl. egy MultiMaus esetén ne kellejen már fejben átszámolni a 2-es számrendszert 10-esre.
Tudom, van már ilyen a neten, de az mind magyarul van, vagy magyarul is?
Ez egy mankó, egy segítség, hogy a CV programozás ne a játék idejét vigye el.
És ez most megért két negatív értékelést???
Mindegy, nem engem/minket minősít... Tükörbe kellene nézni, és elgondolkodni, vagy esetleg csinálni egy jobbat, vagy, ha nem tud a minuszoló, akkor írja le, hogy szerinte mi a rossz, és hogyan kellene javítani rajta!
Volt itt régebben egy probléma, hogy az elkészített sínkavics ágyazat valahogy vezetett (szivárgott), és ezért állandóan üres pályán is bejelzett a rendszer. Erre volt válasz is, de nem találom.
DCC foglaltságjelző érzékenységét szeretném csökkenteni. Azaz nagyobb fogyasztásnál kapcsoljon csak be, kisebbnél ne.
Ha az alábbi ábrában a 33Ohm-os ellenállás értékét növelem, akkor "később", nagyobb fogyasztásnál fog bekapcsolni a fototranzisztor (mivel az infraLED később jelez)? Az értéket majd kikísérletezem, az elv a kérdés, hogy jól gondolom-e?
Csináltunk egy kis segítséget, lesz ugyanis egy új funkciódekóderünk, az FD2023-as. Ennek a beállításához találtuk ki. De érvényes minden olyan dekóderre, amelyik az NMRA szerint működik. A hosszúcín, consist mód. A funkciók gombokhoz rendelése csak olyan dekóderekre jó, amik az NMRA functions mapping-t használják, az ESU-ra például nem!!!
A tartalék funkciók alap esetben nem függenek a menetiránytól, de az FD2023-ban, az NMRA logikáját követve ezt is meghatározhatjuk. A kalkulátornak ez a része csak az FD2023-ra érvényes!
Az első link parancsközpont-emulátor. A második link már közelebb van, de ő meg kézivezérlősködik, azaz mozdonyparancsokat ad a z21-nek, nem eszközparancsokat fogad. Az olyan mondatokból pedig, hogy a ".NETcore és nanoFramework közötti kódmegosztás miatt egyes C# nyelvi funkciókat fel kellett áldozni", kb. annyit értek, hogy "fel kellett áldozni" :)
Igen, mikrovezérlőre van egy-két z21-emulátor-projekt. Általában többé-kevésbé sikerül összehozni a dolgot, de néha elég alap hibákat elkövetnek a programozók. Én például olyan projekttel találkoztam, ami toronyóra láncostul, támogatja az XPressNetet, LocoNET-et, kutyafülét; ugyanakkor pl. a parancsközpont nem ismétli a funkciókat; illetve azzal sem tudtak mit kezdeni, hogy az ESP időzítője lötyögni kezd, ha A/D átalakítást végez éppen, így vagy a zárlatvédelem működött, vagy a DCC-jel volt szép :)
Dekóder-projektből már jóval kevesebb van. Pedig lenne fantázia a dologban... nem kezdem el részletezni, mert belelovalom magam, és nem lesz kész a mai napi melóadag :)
:) Explicite nem írtam le, de a két váltóból összerakott Villány Elág és a TC-ben is látható ("Tövis" fedőnévre hallgató) 22 váltós állomás nem ugyanaz a projekt.
Villány elágazás picike, és jellegéből adódóan (attól függően, hogy állomás végébe kerül-e egy találkozón, vagy nyíltvonalra) távvezérelni kell. Ezért ott egy WiFi-s, webszerveres saját parancsközpontot pakoltam be, mellé pedig kereskedelmi forgalomban kapható dekódereket, mert a váltók és MTB-hajtóművek megvoltak. Mai aggyal inkább kipakoltam volna a hajtóműveket, és szervót raktam volna a helyükre, akkor kihagyható a buliból a 16V és a DCC.
ez az ESP-s cucc egy dekóder, de akkor a sínhez kellene kapcsolódnia (vagy ahol jön a DCC jel), nem?
Hát az attól függ, hogy mit dekódol mivé :) Az enyém a z21-hez WiFi-n kapcsolódik, nem rézen; ennek megfelelően UDP csomagokban kapja a parancsokat, nem pedig DCC-n. Tövis állomáshoz csinálom őket, mivel a 16 darab jelzőn átlagban 5 LED-del számolva, adott esetben speciális (nem magyar, nem is német) jelzésképet kivarázsolni bolti dekóderekkel meglehetősen macera lenne. Mivel a kb. 80 darab LED elég számottevő, portbővítők mellett döntöttem. Aztán majd meglátjuk, hogy hogyan válnak be; egyelőre a munkaasztalon van a projekt.
"Egy ESP megtoldva néhány PCA9685-tel nulla forrasztással 5000 forintból elvisz egy komplett állomást szervóstól-jelzőstől"
Van esetleg egy egyszerű kapcsolási rajzod vagy valami egyszerű sematikus/architektura (dobozos vagy hasonló) rajz? Illetve a komplett állomás hány kitérőt és jelzőt jelent? Tőled is megkérdezném, hogy élőben meg lehet nézni? :-)
Kicsit elvesztem. Először azt mondtad, hogy ez az ESP-s cucc egy dekóder, de akkor a sínhez kellene kapcsolódnia (vagy ahol jön a DCC jel), nem? Aztán meg azt is írod, hogy a gatyád rámenne a bolti dekóderekre de van ahol meg azt írod, hogy azt használsz. Most akkor mi van? :-)
Jól érted. Korábban itt a fórumon is linkeltem a TC-t, ami a jelzőket-váltókat állítja: https://youtu.be/XqTJrAHQuiY?si=5wsxQks_Dsk-Sjck -ehhez lesznek majd az ESP+portbővítős "dekóderek". Ingem-gatyám rámenne, ha bolti dekóderekkel akarnám megcsinálni a jelzőket, főleg, hogy direkt jó bonyolultra raktam össze, legyen benne emelt sebességű kitérő, ismétlőjelző, balvágány-jelző, hívójelzés (és még bele kellene szuszakolnom egy "sárga indikátort" is a poén kedvéért).
Természetesen egy ESP-ben is le lehetne programozni függéseket, hogy csak akkor állítsa a jelzőt, ha jól állnak a vasak, de a logika ilyen módon történő szétválasztása szerintem több hátránnyal járna, mint előnnyel.
Persze annak is van létjogosultsága, hogy a komplett bizbert berakjuk egy ESP-be. Ehhez viszont úgyszintén komoly felkészültség kell, programozási ismeretek, a bizberek ismerete (pl. programozz le a fenti állomásra imbolygó oldalvédelmet, oldalvédelmi célkizárással :). Ja, és kell hozzá valami "front-end" is, célszerűen valami pult (millió gombbal és lámpával), ekkor némi elektronikai ismeret sem árt; vagy ha már ESP, meg lehet fogni a könnyebbik(?) végén is, és egy webszervert belerakni -- ez utóbbi esetben azért nem árt némi HTML, javascript, AJAX, ilyesmi. Ilyennel is próbálkoztam, direkt emiatt tanultam meg az előbbieket: https://youtu.be/IN_NwctK254?si=6icLm3sKw2rQqVE9 -- ez a projekt aztán megakadt, de elég vicces, ha egy ESP-t valahol a lakásban rádugsz egy telefontöltőre; egy tetszőleges telefonról-tabletről-PC-ről megnyitod az oldalat, bökdösöl, az ESP meg küldi a parancsokat a Z21-nek, állnak a vasak és a jelzők.
Villány elágra végül a fenti projekt pepitában lett megcsinálva:
- az ESP kapott egy motorshieldet,
- leprogramoztam egy parancsközpontot;
- keprogramoztam egy objektum-orientált Siemens-Halske bizbert;
- összelinkelgettem a kallantyúkat-emeltyűket-vonalzókat-kilincseket, hogy meglegyenek a függések;
Jól értem, hogy akkor az ESP wifin kapcsolódik a Z21-hez kapcsolt routerre és így tudsz jelzőket, kitérőket állítani és ezt az egészet pl a WLANMaus-ról vagy pl egy traincontrollerrel/JMRI-vel is lehet(ne) vezérelni?
A vissza irány is meg van oldva valahogy? Pl a jelzés függhet a váltó állásoktól is vagy más jelzőktől.
Van kedved pár részletet, tapasztalatot megosztani?
"Tudom, tökfölösleges ilyesmire WiFi-t használni"
Annyival kevesebb vezeték és a Z21-hez úgy is van router...
Nem, hanem dekóder. Egy ESP megtoldva néhány PCA9685-tel nulla forrasztással 5000 forintból elvisz egy komplett állomást szervóstól-jelzőstől :) Tudom, tökfölösleges ilyesmire WiFi-t használni, pusztán kísérlet.
A Maus is készül, csak az nehezebb dió. Igyekszem mindent saját magam leprogramozni, egyelőre még csak okosítom a Z21-gyel beszélgetős osztályomat.
Ja, bocs, így már kerekebb a kép. Én parancsközpontot csináltam már, dekódert még nem (legalábbis DCC-alapút nem; a z21 Ethernet-protokollján ücsörgő WiFi-s cuccot igen). XPressNettel meg aztán végképp nem bajlódtam.
és ezt csak az adott dekóder ismeretében lehetne megmondani, hogy az éppen milyen jelet akar – a gyakorlatban a dekóder oldaláról ez azért nem szokott problémát okozni, mert általában a dekóderek taníthatóak (nyomógombbal, rövidzárral). Ha Te is raksz egy nyomógombot a dekóderedre, megtanulhatja azt a címet, amit éppen kap – akármennyi is legyen az, és akárhogy is dekódolja.
A Z kimenetet úgy érted, hogy két darab független fizikai kimenet lenne? Én azt gondoltam volna (de nem értek hozzá), hogy egy váltó dekóder egy portjához (tehát pl a 55-os címhez (ami mondjuk 52+3) tartozó két kimenet nem független egymástól, hanem egymás negáltjai. Lehet, hogy mindkettőt lehet külön vezérelni? Szóval az előző leírásomban lévő táblázatot továbbra sem értem, sajnos – Pontosan. Ha megnézed a DCC-szabványt, abban 3 bit van a kimenetre, és 1 bit az adatra. Azaz 8 bitet lehet egymástól függetlenül be és kikapcsolni. Az más kérdés, hogy
- Az esetek 90%-ában "páros" eszközöket kötünk a kimenetekre (dupla tekercses váltó; polaritásváltásos motor; esetleg dekóderen keresztül hajtott szervók). Ezeknek 3 állapotuk lehet (0/0, 0/1, 1/0), sőt, a 4. állapot (1/1) akár károsíthatja is őket, így a dekóderek többsége elintézi, hogy ha egy páros kimenetet bekapcsolsz, a páratlan párját kikapcsolja – adott esetben úgy, hogy ez egy opcionálisan kikapcsolható funkció. Az NMRA szabvány emlékeim szerint egyébként erről a jelenségről "úgy szokták, hogy"-szinten emlékezik meg: mivel az esetek többségében a kimeneteket párosan használjuk, a megszokás az, hogy a 3 bitnyi kimenet-cím alsó bitje a logikailag párokba rendezett kimenetekre kötött egyetlen eszköz (váltó, jelző) két állapota között választ, 0 jelenti a váltó egyenes állapotába, vagy jelző M!-ba állító kimenetét.
- Az esetek 90%-ában impulzusüzemű berendezéseket kötünk a kimenetekre, azokat károsíthatja, ha folyamatosan meghúzzuk a kimenetet. Így, bár a parancsközpont elvileg tud "kapcsold be" és "kapcsold ki" parancsot is adni, a dekóderek többsége elintézi, hogy "kapcsold ki" parancs nélkül is csak egy beállított hosszúságú impulzust adjon a kimenetére – vagy legalábbis van ilyen üzemmódja is.
Például ha veszel egy Digitools eszközdekódert, akkor a 8 kimenete logikailag párokba van rendelve, és a következő összefüggések lehetnek közöttük:
1.) a pár egyik kimenetének meghúzására érkező parancs hatására a kimenet meghúz, és úgy is marad; a pár másik kimenete kikapcsol (ha be volt kapcsolva).
2.) a pár egyik kimenetének meghúzására érkező parancs hatására a kimenet beállított ideig meghúz; a pár másik kimenete kikapcsol (ha be volt kapcsolva).
3.) a pár egyik kimenetének meghúzására érkező parancs hatására a kimenet meghúz, és úgy is marad egészen addig, amíg a kimenet kikapcsolására vonatkozó parancs nem érkezik; a pár másik kimenete kikapcsol (ha be volt kapcsolva).
(Tapasztalataim szerint az 1. és 2. esetben egyébként a dekóder a parancs adatát nem figyeli, csak a címet, így mindegy, hogy ki-, vagy bekapcsoló parancs érkezik, ő ugyanúgy bekapcsolja a kimenetet.)
Sajnos olyan üzemmódja a dekódernek nincs, hogy a páros és páratlan kimenet ne legyen keresztbe reteszelve, pedig a DCC-szabvány szerint akár lehetne is. Az megint más kérdés, hogy a legtöbb központ sem tudja egyesével kezelni a kimeneteket: a DCC-szabványban említett 3 bitnyi "kimenet-cím" felső két bitjét hozzácsapják a 9 bitnyi "dekóder-címhez" (így létrehozva egyetlen "csatorna-címet"), az alsó 1 bitet meg arra használják, hogy az adott csatornán belül két kimenetet lehessen macerálni.
"amennyit látok ebből a DCC-ből egy elég tákolmánynak tűnik"
Merész kijelentés! A DCC annak idején azzal nyerte meg az amerikai NMRA támogatását, hogy messze a legüzembiztosabb megoldás volt. Cserébe nem kompatibilis a korábbi, egyenáramú rendszerrel. Ezt - ha nem is könnyen - túléltük. Ha egy új rendszerben gondolkozunk, akkor az üzembiztonság központi szerepet játszik. Bizonyára lehet ilyet is találni, pl. a digitális rádió-vezérlések között. Akkor már csak az a kérdés marad hátra, hogy megéri-e az új rendszerrel kiváltani a DCC-t? Lenne-e annyi előnye az újnak, hogy megérje váltani és mekkora piaci elterjedést (újmagyarul "penetráció") lehetne elérni vele? Végül is a DCC most 30 éves és még mindig nem 100%-os az elterjedtsége!