Servo přestavník

[Morris Zapp]

Kolegové,

můj problém elegantně vyřešen zahozením dekodérů ESU a přechodem na do-it-yourself ovladače serv, a to v uspořádání jedno servo - jeden ovladač. Takže nejsem ekonomikou nucen pořádat dálkové rozvody od dekodéru se čtyřmi výstupy, ale montuji ovladač přímo u serva. Naprostá spokojenost, prošlo to provozním setkáním bez jediného zaváhání.
A navíc proti továrnímu ovladači tady mám firmware na míru, takže třeba jednotlačítkové ovládání, což ESU neumí. Funkci DCC dekodéru nepotřebuji - je to malá dopravna D3 o sedmi výhybkách místně stavěných.

[zdeno]

neni vyresen, proste neverim tomu, ze zatlumenim hran a omezenim prenosoveho spektra jste to vyresili. To si jen myslite a az se dostanete do prostredi, kde bude uroven ruseni trosku vyssi, treba nekdo zapne trafopajku vedle serva, tak budes velmi prekvapeny. Udelej pokus, dej tam propojovaci kabel 5m a napajej s tim servo a uvidis, co se stane. Bude ti to litat jako splasene.
---
Moje reseni je spolehlive a odzkousene na tisicich NF zarizenich. Umis si predstavit, jak by se posluchaci na koncertech potesili, kdyby se tam kazdou chvili mel vyskytnou nejaky rusivy impuls ?? To proste nejde a nemuze se to dovolit. A jestli si myslis, ze se tam dropouty nevyskytuji, tak se zobud
---
Ale delej jak myslis, byla snaha pomoc.

[fulda]

Problém je vyřešen v intencích které jsme považovali za důležité. Tedy - funguje to za přijatelně málo peněz na běžném kolejišti a na běžném modulišti. Nikdo z nás neprovozuje kolejiště u megawattového generátoru, takže jsme tuto alternativu neošetřovali. Stejnětak jako nikdo z nás nepoužívá 5m dlouhé kabely, na to už jsou jiné přenosové protokoly a linkové vrstvy.

[Morris Zapp]

Zdeno,

moje řešení není v zatlumení hran a omezení spektra; řešení je v minimalizaci vzdálenosti mezi zdrojem ovládacích pulsů a vlastním servem. Samozřejmě, že řešit to skrzevá nízkou impedanci nebo vysoké napětí by taky šlo, ale proč? Nehledě na to, že s tím napětím bychom narazili na bezpečnost.
Další vývoj směřuji spíš k tomu, aby držák serva a struny "srostl" s generátorem pulsů v jeden montážní celek.

[zdeno]

zas mi nevkladejte svoje myslenky do meho projevu
---
Vsak jsem napisal, ze do vzdalenosti max. pul metru je to jeste celkem "v poradku". Fakt idealni by bylo, kdyby byl ovladac hned vedle serva, tim padem je moznost naindukovani ciziho napeti velmi mala. Ono tech moznosti odruseni je vice, treba kroucena trojlinka, ala to zas ma jine nevyhody.
---
Uz nebudu reagovat, vlastne mi je to tak nejak ukradnute, jak si to udelate. Snaha byla pomoci zkusenostma ktere mam. Kdyby jsem vedel pred rokem, s cim tu bojujete, tak bych vas hned usmernil spravnym smerem. Ono vzdycky a vsude je nutne zacit patrat po pricine a ne napravovat uz poskozene.
---
Jinak moje pristrojove vybaveni by ni zavidelo lecjake elektrotechnicke laboratorium. Nebudu tu vypisovat, co vsechno mam, ale je toho opravdu dost.

[zdeno]

nevim, ci je to tu nekde napisane, ale nenasel jsem to.
Jedna se o to, ze v EEPROM tabulke neni vyhrazeno pole 4 bajtu pro posledni stav.
Teda jak ovladac zjisti, jaka hodnota byla zapsana naposledy a podle bitu 7 v CV 541(29) se nastavi(nenastavi) do posledniho stavu ??

http://www.fucik.name/masinky/x/dcc4servo_v3.x.html

[fulda]

Nevím jestli je to z uživatelského pohledu podstatné, ale ukládá se to do posledního bajtu té paměti, ten se mi nevešel na obrázek. A pochopitelně se to vejde do 4 bitů celé, takže jeden bajt stačí. Ta hodnota není nijak editovatelná, dekodér jí používá interně.

[zdeno]

Nevím jestli je to z uživatelského pohledu podstatné, ale ukládá se to do posledního bajtu té paměti, ten se mi nevešel na obrázek. A pochopitelně se to vejde do 4 bitů celé, takže jeden bajt stačí. Ta hodnota není nijak editovatelná, dekodér jí používá interně.

tomu nerozumim, vzdyt nektere verze ovladace muzou mit i nekolik moznych poloh a pokud zaznamenavas jen ano/ne , tak se to do ctyrech bitu nemuze vejit. Nebylo by snazsi ty bajty primo pojmenovat a lokalizovat v EEPROM pameti ?
---
Ono mi tam jaksi vubec chybi zpetna vazba, teda ovladac nevi, kam je nastaveno servo po zapnuti a posle impulsy jen tak do vetru a do stavu serva se bud trefi nebo se servo prestavi.
Podle mne by stav serva mel zajistovat nadrazeny program, teda RailCo nebo neco podobne a pri startu toho programu by mel provect zakladni inicializaci vsech periferii. Teda bud dotazem na stav, pokud maji zpetnou vazbu nebo primo prikazem na nastaveni do zakladniho pozadovaneho stavu.
---
Tim myslim to, ze indikace na zobrazovadle, po startu, neodpovida realnemu stavu.

[Seidl]

Pokud se týká zjiš'tování výchozí polohy serva po zapnutí nebo uvažovat zda se řídící pulzy po zapnutí trefí do současné polohy nebo ne, je zcela bezpředmětné. Je holou skutečností, že serva se chovají podle jedné z následujících možností:
- po zapnutí sebou nekontrolovatelně škubne i když má vstup uzemněn nebo je na něj přiveden řídíci pulz (bez ohledu na jeho hodnotu). Je to dáno konstrukcí jeho elektroniky, kdy koncové tranzistory si v daný okamžik zapnutí dělají co chtějí. A jej jim zcela jedno, jestli jim na vstup něco přivádíte nebo ne...
- pokud je při zapnutí napájení vstup na log. nule, pak servo zůstane v klidu a po přivedení signálu reauguje jak má
- třetí možnost je, že v důsledku konstrukce elektroniky serva, jsou koncové tranzistory po dobu ustálení elektroniky odpojené a servo je také v klidu.
To, jak se servo chová po zapnutí zjistíte až na stole při zapnutí. A nikde není ještě zaručeno, že za měsíc u stejného typu se bude chovat stejně. Výrobce klidně změní elektroniku a je všechno jinak....
Jedinou známou a jednoduchou možností je, odpojit na nezbytnou dobu přímo motorek v servu. Znamená to servo upravit, ale jinak to není nic těžkého.

[zdeno]

nerozumime si
mne se jedna o to, zda je soulad mezi ovladanim a nadstavbou, ktera to servo ovlada.
Teda je mi implicitne jedno, v jakem stavu je to servo, ale neni mi jedno, ze RailCo ukazuje neco jine, nez je v reali nastavene.
---
Je jasne, ze po prvem prestaveni se to srovna samo. Ale treba zkrat to muze rozhodit a nasledne muze dojit k poskozeni modelu spatne nastavenou cestou.

[male zvire]

zdeno: od toho jsou v TC makra. Prostě si po zapnutí kolejiště spustíš makro které všechny výhybky přestaví do výchozí polohy a nemusíš nic řešit...

[zdeno]

zdeno: od toho jsou v TC makra. Prostě si po zapnutí kolejiště spustíš makro které všechny výhybky přestaví do výchozí polohy a nemusíš nic řešit...

kolik lidi, tolik chuti a dodal bych, znalosti ma taky kazdy jine.
---
Problem je v tom, ze kdo ovlada macra, nemusi resit takovou somarinu. Ja to resim jinak, pouzivam system vlakovych cest, to znamena, ze neexistuje, abych poslal vlak do spatne nastavene vymeny.
Jsou ale mezi nami lidi, kteri ovladaji kolejiste bodovo, teda myskou nastavuji postupne vlakovou cestu a pro ty muze byt problem, kdyz neco berou jako fakt a on to fakt neni. Tady by to melo byt sparovane implictne, teda po restartu se MUSI nastavit RailCo stejne jako prislusenstvi a je uplne jedno, ci to je navestidlo nebo vymena.
---
Proto bych uprednostnil definici posledniho nebo zakladniho stavu trosku jinak. Podle mne jeden bit na to nestaci.

[cipisekmp]

Ahoj, neni nahodou rekneme sjednoceni tc a kolejiste funkce refresh railorad? Ja teda presne nevim co to dela, ale vim ze u modulu jsme to po zapnuti systemu provedli a podle me to udelalo to sjednoceni.
Cipisek

[fulda]

Zdeno - součástí mechaniky servo přestavníku je v dobré praxi zajištění zpětné vazby. Podle toho jak se komu líbí, tak se zpětná vazba dělá z polohy serva, nebo z polohy jazyků na vyhybce. A potom máš možnost si v software nastavovat reakce na minulej a očekávanej stav.
Odvozovat to z dekodéru je podle mojeho názoru trochu nešťastné, protože cestou od dekodéru k jazykům na vyhybce je velké množství potenciálně poruchovejch spojení.

[zdeno]

touto cestou bych asi nesel,
protoze predpokladat defaultne, ze se neco pokazi je dost nestastne. Teda bud to funguje nebo nefunguje. Takze potom je jedno, od ktereho prvku to budem snimat. Souhlasim, ze prino z jazyku vyhybky je to nejlepsi, ale taky nejpracnejsi a nekoplikovanejsi. DCC ma jednu velkou chybu a to, ze nema z principu zpetny ohlas. Takze tam musi byt bud berlicka pomoci nejake sbernice nebo drat 1/0 nebo "dohoda", ze po startu tam musi byt tento stav.
---
O co mi jde:
definovat a pouzivat vic bajtu EEPROM na stanoveni chovani ovladace po startu. Bylo by dobre se dohodnout, jake ctyri bajty tomu pridelit a jaky rozsah pouzivat. Nevyhovuje mi rizeni jednim bitem. Je vlastne jedno, jak se dohodneme, ale urcity standard by bylo dobre vytvorit.
---
Taky se na to muzeme vykaslat, nech si to kazdy udela podle sveho.