Diskuzní fórum železničních modelářů

Vím, že se vyrábí řada komerčních dekodérů. Vím taky, že na těchto stránkách jsou minimálně dvě vyladěná amatérská řešení a možná i řada dalších.
Ale já si rád řeším řadu věcí vlastní cestou. Proto zamýšlím realizovat vlastní dekodér k ovládání přestavníku se servem. Z tohoto důvodu jsem se seznámil s mikroprocesory PICAXE (www.picaxe.com), které se mě líbí zejména proto, že je lze programovat ve vyšším programovacím jazyku (řekněme obdobou Pascalu/Delphi). Asi bych zvládl postupně i řekněme jazyk pro programování PIC (vždy jsem obdivoval a chtěl se naučit programování v JSA), ale u těchto mikroprocesorů jsem narazil na to, že je řada programátorů (pro amatérskou konstrukci) a každý vykazuje za nějakých (ne dopředu definovaných) podmínek nějaké chyby a všechny nejsou určeny pro všechny PIC.
Kdežto u PICAXE jsem postavil programátor za 3 Kč, vše fungovalo na první pokus (instalace SW, zapojení programátoru a první program). Programování je fakt jednoduché a každý kdo zvládl Pascal/Delphi/Basic to zvládne levou rukou. Dokumentace je výborná, SW zdarma a procesory za rozumné ceny.
Je však možné, že u časově kritických činností (ovládání serva) budou právě ty příkazy ve vyšším jazyce zdrojem problémů.
Přesto jsem se rozhodl, že se pokusím postavit i vlastní spolehlivý dekodér. Budu jich potřebovat docela dost.

Zamýšlím na to jít asi těmito kroky :
1) "Ovladač" 8 servopřestavníků, který bude mít tlačítkové (přepínačové) vstupy.
2) Otestovat na kolejišti v provozních podmínkách
3) Otestovat, zda při ovládání serv je možno v PICAXE současně provádět jiné operace bez vlivu na časování serv (příprava na doplnění komunikace)
4) Pořídit si digitální centrálu. Nastudovat komunikační protokoly
5) Doplnit do "ovladače" dekodér digitální komunikace.

Bod 1) mám asi z 50% hotov - laboratorní zapojení je funkční, otestováno se 3 relé.

Proč to tu píši ? Hledám někoho,
A) kdo již má zkušenosti s PICAXE a dokáže případně při problémech poradit, nasměrovat
B) nebo, a to hlavně - pro koho by toto bylo taky zajímavé a chtěl by na řešení se mnou spolupracovat.

Najde se někdo takový ?

dalsi do nasi rodiny lidi, kteri nejsou s nicim spokojeni a chteji mit vsechno pod kontrolou.
---
vybral jsi si tu nejtezsi cestu, proste jit cestou vlastniho vyvoje je hodne trnita cesta a ne vzdycky budes pochopeny a taky uspesny. Muj soukromy odhad je, ze iba 10-15% mych veci je tak nejak vseobecne vyuzitelne.
Vsechno ostatni je negativni zkusenost, ale ta se taky pocita, i kdyz je to otrava.
---
Ja pracuji s Atmely, ktere maji podobnou platformu Airduno, ktera se pouziva jako Pixace. Neni to to same,ale je to hodne podobne.

Co se týká časování a použití vyššího jazyka, tak to nemusí být problém, ale pochopitelně dalece víc záleží na tom, jaký použiješ model a jak si rozdělíš práci mezi hardware a mezi software.
Já používám například metodu multiplexování, která vychází z úplně původního převodu sériového signálu na posivném registru. Pak na tvorbu potřebuji jeden časovač a tvorba se odehrává na úrovni přerušení, hlavní program jenom vyplňuje a modifikuje konstanty.
Picaxe běžně provozují Hobíci v Modřanech (a mají i dobrej čaj)

@Zdeno : ano, napsal jsi to správně-mám rád věci pod kontrolou, možná spíše mám přesnou představu co mi věc má poskytnout a zřídka kdy něco splňuje všechny moje požadavky

@Fulda : pochopil jsem, že k jednomu generátoru impulsů postupně připouješ jednotlivé vývody se servy ? Mojl by jsi mi to trochu upřesnit ?
Ten problém, který jsem měl na mysli je to, že používám vestavěný příkaz "servo", který by měl generovat příslušné pulsy. Vše vypadá v pořádku, jen se občas ( po pár sekundách ale nepravidelně) tam objeví ještě nějaky další puls, ktery trochu pohne s servy. Takové bzučení od 100 serv by mě tedy silně vadilo. Vypadá to, že to generuje processor. A to přitom nic jiného nedělá (není tam zatím komunikace.) Už jsem zkoušel napájet i bateriemi a nc. Ještě chci zkusit rozdělení zdrojů. Pak už je jedině cesta nalrogramovat přímo jednotlivé pulsy na výstupu.
Nejspíš si myslím, ža to je ten příkaz ve vyšším jazyce, že tam je ještě nějaká obslužná rutina, která není časově zanedbatelný. Začínám tady studovat i fóra k picaxe.

presne to je to, co mi na servech vadi, ja to volam "chveni", teda nepravidelne oscilovani okolo nastavene hodnoty.
Mam osciloskop a tak muzem sledovat sirku pulsu od mikroprocesora a ten to zcela urcite nedela. Tam je presnost umerna pracovnimu kmitoctu. Cim vyssi kmitocet, tim jsou generovane impulsy presnejsi. Kolisani hodnot je nemeritelne, teda musi byt mensi nez 100nS, to jsou hranice mereni meho osciloskopu. Ukazuje mnohem vic, ale presnost je garantovana na 10 MHz. Moje serva se nechveji, sedi napozici jako pribita, ale to je za cenu dost sloziteho navrhu. Zatim to testuji, az budu spokojeny, tak to uverejnim.
---
Podle mne za to muze logika na servu, ktera spracovava impuls a vyhodnocuje shodu s potenciometrem, spolu s nestabilitou napajeni, ktere je taky zdrojem hazardu.
Jeste tu je jedna moznost a to pridani nebo odecteni rusiveho impulsu od ridiciho signalu. Tim myslim, ze rusivy impuls se naindukuje a v momentu zacinani nebo ukonceni ridiho impulsu ovlivni jeho delku. Tim dojde k spatnemu vyhodnoceni a servo se malicko pohne.
To je ale cisto jednorazova udalost a na to bych potreboval pametovy osciloskop.


PS dodatek
jeste to muze delat preruseni v procesoru. Mam to udelame tak, ze prijem bajtu od Loconetu je otazkou 6 strojovych instrukci, teda asi 6x12,5ns=75nS. O tuto dobu to muze litat v mem programu. Tento cas je pro servo neregistrovatelny. Pokud jsou nastavene preruseni jinak, tak to muze u jinych ovladacu delat problemy.
Zvlast u DCC, kdy se zpracovava kazda hrana od 58uS, 116uS se muze cas na preruseni docela nasbirat. Tim myslim, ze treba ROCO centraly nepouzivaji IDLE pakety, ale posilaji radu "1", treba 250 v kuse. Podle normy to neni chyba, ale na spracovani na servu to muze mit vplyv a cas na poslani ridiciho impulsu na servo, to "muze" ovlivnit.
To je muj nazor, pokud to nekdo muze premerit, bude dobre.

Ales píše:@Fulda : pochopil jsem, že k jednomu generátoru impulsů postupně připouješ jednotlivé vývody se servy ? Mojl by jsi mi to trochu upřesnit ?
Ten problém, který jsem měl na mysli je to, že používám vestavěný příkaz "servo", který by měl generovat příslušné pulsy. Vše vypadá v pořádku, jen se občas ( po pár sekundách ale nepravidelně) tam objeví ještě nějaky další puls, ktery truvhu pohny s servy. Takové bzučení od 100 serv by mě tedy silně vadilo. Vypadá to, že to generuje processor. A to přitom nic jiného nedělá (není tam zatím komunikace.) Už jsem zkoušel napájet i bateriemi a nc. Ještě chci zkusit rozdělení zdrojů. Pak už je jedině cesta nalrogramovat přímo jednotlivé pulsy na výstupu.
Nejspíš si myslím, ža to je ten příkaz ve vyšším jazyce, že tam je ještě nějaká obslužná rutina, která není časově zanedbatelný. Začínám tady studovat i fóra k picaxe.

Prohlížel jsi si někdy protokol, který serva používají, včetně toho jak a proč vznikl?
Je to trochu o dějepisu, ale člověku to trochu pomůže při uvažování nad tím, co se v servu odehrává.
Původní myšlenka byla, jak udělat ze sériové komunikace z vysílače do přijímače paralelní pro serva. Nejvíce se ujala metoda, která se dala v tehdejší době (konec 70 let) snadno vyřešit elektromechanicky. takže ve vysílači byl zdroj hodinového signálu nastavený zhruba na 50Hz, posuvný registr (s paralelním výstupem) a balíček RC členů, kde R byl potenciometr na kniplu. Logika byla asi taková, že 50Hz generátor na začátku pulzu vygeneroval právě jednu jedničku do posuvného registru. na každém z paralelních výstupů byl jeden RC člen, pokud se na vstupu objevila 1, člen se připnul a začel nabíjet to vygenerovalo impulz, který se odeslal do rádia, když došlo k nabití, posunul se posuvný registr a vygeneroval další pulz do rádia. Čili, rádio odesílá pulzy, jejich náběřné hrany jsou tak daleko od sebe, jaké jsou výchylky jednotlivých potenciometrů. pochopitelně když dojdou potenciometry (kanály), ta jednička vypadne z registru a je dlouhé ticho.
Na straně přijímače byla podobná logika. Dlouuhé ticho vedlo k resetu = do posuvného registru se nastavila právě jedna jednička (využití paralelního mazání) a ta se posouvala přez jednotlivé výstupy. Takže pokud vysílač disponoval například 5 potenciometry a přijímač pouze 4 bitovým registrem, tak jednička na konci vypadla, pokud naopak disponoval delším 8 bitovám registrem, tak vzhledem k paralelnímu mazání nikdy nedošla do konce.
Tento princip u nás používala třeba RC souprava Modela Digi (chápej, v té době pokud v tom bylo použito 2ks obvodu 7400, tak to bylo digi). Dobré bylo, že se pouhým prodlužováním posuvného registru dal zvětšovat počet kanálů. Jedná se o takzvaný PPM systém.
Osciloskopem napěříte zhruba toto:
na modulátoru
na rádiu
funkce demodulátoru
(ZDROJ1 ZDROJ2 - obrázky jsem nalinkoval z těchto stránek, nechtělo se mi je znovu malovat)

Takže servo dostává pulz, jehož délku porovnává s výchylkou potenciometru ve snímači. Původní logika byla taková, že se pulz poslal do RC členu (R je potenciometr snímače) a porovnávalo se co vypadne. Pokud bylo nastavení RC stejné, tak pulz trval stejně dlouho, jako jeho obraz v RC soustavě a nedělo se nic, pokud byl pulz kratší nebo delsí, tak se rozdíl použil jako kladný a nebo záporný pulz pro motor. Podle rozdílu se motoru prostě poslala větší nebo menší šlupka.

Poznámka:Tím pádem bylo možné definovat něco jako dlouhou nulu - tedy stav, kdy servo nedostává žádné impulzy se považuje za stabilní, motor serva má být v takovém případě uveden do bržděného režimu.

Tak a teď moje realizace. Já mám v nějakých registrech očekávanou výchylku pro serva, řekněme 4 serva A,B,C,D na výstupech jednoho portu procesoru. Logika kterou používám je identická jako u přijímače: připravím si do časovače hodnotu pro servo A, nastavím na 1 výstup pro servo A a spustím časovač. Časovač po uplynutí požadovaného času vynuluje celý port kde jsou serva (jedna instrukce). Hlavní program rozpozná, že servo bylo odbaveno, takže nastaví stejným způsobem pulz pro servo B. A tak dále. Na konci se vytvoří ještě pulz pro neexistující servo s délkou trvání 50-(A+B+C+D) a tak pořát dokola.
Pokud se serva namají pohybovat (a jsou dostatečně stabilizovaná), tak každé jedno servo vyřadím z logiky a přestanu pro něj generovat signál. Tím pádem nedocházi ke chvění u levných analogových serv.

Tato logika má několik předností, snadno se například rozšíří pomocí jednoduchého demultiplexeru (74 154) na větší množství serv než mám vývodů na procesoru.

Pochopitelně to předpokládá, že si celou ovládací logiku napíšeš sám a nepoužiješ knihovní funkci u které není jasné jak se chová. Viz poznámka o tom, že do všeho chceš vidět.

zdeno píše:presne to je to, co mi na servech vadi, ja to volam "chveni", teda nepravidelne oscilovani okolo nastavene hodnoty.
...

Tady je několik faktorů které vedou ke chvění serva. Jednak se jedná o teplotní a proudovou nestabilitu RC členu pro analogová serva, která používají klasické porovnávání délky pulzu. zejména jde o to, že kondenzátor se nevybíjí dokonale a RC vazba je citlivá i na délku nuly. Pak pochopitelně kvalita trimru a kvalita komparačních operáků použitých uvnitř pochybných ASIC obvodů.
Hodně se to liší u každého výrobce a rozhodně u čínského serva TG9 za $2 (40,- korun) nelze očekávat žádnou velkou stabilizaci.
Dá se tomu pomoci právě používáním dlouhé nuly, která ovšem u levného serva neznamená brzdu, ale uvolnění motoru, takže servo přestane být v tahu a pokud proti němu máme nějakou velkou sílu, tak prostě podlehne a posune se.

Aleši, vymýšlet již vymyšlené je stále živá záležitost. Možná je to i zájmem o daný obor a radost z výsledku. Šel jsem kdysi také touto cestou a pak jsem toho raději nechal. Pokud je tu záliba něčeho dosáhnout a dotáhnout to do šťastného konce a je-li dostatek času, pak není o čem debatovat. Pokud by se ovšem zvážily náklady a potřebný čas, tak je to cesta do pekel. Je tu také skutečnost, že kolejiště nemůžu provozovat, protože stále vyvíjím něco již hotového. Zvážil bych cestu něco ve svých nápadech změnit a použít hotové dekodéry. Pokud vím, tak například Fulda má něco hotového a já jsem se osobně rozhodl pro servopohony SP 2x1. Zmínka tu již o nich byla, tak se na ně podívej. Minulý týden jsem doinstalovat druhou desítku a všechna čest. Pořizovací cena se na první pohled může zdát vyšší jak ostatní, ale při zvážení co všechno je zde ošetřeno (například to zmíněné chvění a záškuby) a co dalšího musím nainstalovat na levnější dekodéry hovoří jasně.

@ Zdeno: V mém případě se mi zdá, že zdrojem je mikroprocesor. Na osciloskopu vidím vždy proběhnout nějaký impuls. Zkošel jsem to zaznamenat (neměl jsem zatím čas si s tím moc hrát) a jednou následoval druhý puls rozhodně dříve než za 20 ms. Podotýkám, že tam zatím nemám komunikaci implementovanou.

@Fulda : Díky za detailní popis a za vysvětlení. O servech jsem si něco nastudoval-o jednotlivých servech. O způsobu řazení ne a proto jsou to pro mě zajímavé informace. Tento způsob se mi líbí. Já bych asi původně řešil paralelními pulsy, pokud nebudu moci použít vestavěný příkaz "servo" - viz problém výše. Takže určitě půjdu touto cestou, kterou jsi mi tu naznačil.
Mohl bys mi ještě naznačit, jak do toho máš potom zintegrovanou komunikaci, abych si nějakým způsobem mohl nastavit koncept ?
Ještě jsem se chtěl zeptat, ty myslím používáš PIC, že? Pokud máš (měl jsi) nějaký amatérský programátor, jaké schéma se ti osvědčilo?

@Navratil02 : Jak píši asi v mém hlavním vlákně o mém kolejišti, chtěl jsem se už dříve naučit programování mikrokontrolerů. Zde bych chtěl spojit radost z poznání s užitkem. Je to sice asi na poprvé poměrně obtížný úkol, který spojuje dvě nezávislé činnosti, ale blikající ledka není cíl, který by mi stačil.
Obecně souhlasím, že není potřeba vymýšlet už vymyšlené. Ale v tomto případě jde o zábavu a tak čas nepočítám a prodávat to nehodlám. Z ekonomického hlediska však, jestli počítám s cca 100 servy, tak pak rozdíl i 50 Kč na servo už představuje zajímavou částku, která se dá investovat do něčeho jiného.

Ales píše:Mohl bys mi ještě naznačit, jak do toho máš potom zintegrovanou komunikaci, abych si nějakým způsobem mohl nastavit koncept ?
Ještě jsem se chtěl zeptat, ty myslím používáš PIC, že? Pokud máš (měl jsi) nějaký amatérský programátor, jaké schéma se ti osvědčilo?

komunikaci používám DCC, které je ve většině případů jednosměrné, takže pouze čtu serializovaná data. To celkem v pohodě stíhám "v mainu". Mám na stránkách nějaké popisy.

Programovadla používám dvě. Ze začátku jsem si postavil RCD prog (dnes nepoužitelný, potřebuje počítač s 12V sériovým portem), druhej mám klon Pickit 3, ale i tady musím konstatovat, že už to není co to bejvalo a kvalita tohoto výrobce jde dramaticky dolů, takže ti poradím najdi si jiného výrobce tohoto zařízení.

Ales píše:...jestli počítám s cca 100 servy, tak pak rozdíl i 50 Kč na servo už představuje zajímavou částku, která se dá investovat do něčeho jiného.

proto jsem zvolil maloobchodně nejlevnější procík na trhu PIC12F629

Mám malou poznámku ke konstrukci nových dekodérů pro používaní serva
k přestavování výhybek.
Po stavbě tří kolejišť se servy, vím že je zde problém s krátkým zkratem
na DCC, způsobený např. kov. kolečky vagónu, tj. takový,
který nevypne elektronickou ochranu centrály (NanoX) a také
když dojde k takzvanému říznutí výhybky. Oba typy těchto zkratů způsobí
na okamžik ztrátu na DCC a po obnovení DCC si serva dělají co chtějí.
Vzniká také problém při zapnutí kolejiště a používání tlačítka STOP na myši.
To znamená, že škubání serv trhá koleje i z podloží, likviduje případné
nastavení polohy serva a mikrospínačů nebo je úplně zničí.
Proto používám servodekodéry pouze s externím napájení DC +12V
a serva bez mikrospínačů.

Na to jsem už někdy upozorňoval, je potřeba vhodně pružný element mezi servem a vyhybkou.
Jinak moje dekodéry se základnovou stanicí řeší problém napájení a rušení signálu docela slušně. Troufám si říci, že nejslušněji z toho, co je na trhu.

fulda píše:Na to jsem už někdy upozorňoval, je potřeba vhodně pružný element mezi servem a vyhybkou.
Jinak moje dekodéry se základnovou stanicí řeší problém napájení a rušení signálu docela slušně. Troufám si říci, že nejslušněji z toho, co je na trhu.

Proto používám servoadaptéry, které řeší všechny tyto problémy, krom prvotního záškubu po zapnutí. Nicméně s tímto adaptérem nehrozí žádné poškození. Pouze si to kmitne a je klid. Navíc seřízení mikrospínačů si udělám pohodlně na stole a samotná instalace pod vexel není nijak náročná na přesnost. Pružné elementy to vyřeší samy.

komori píše:... když dojde k takzvanému říznutí výhybky. Oba typy těchto zkratů způsobí
na okamžik ztrátu na DCC a po obnovení DCC si serva dělají co chtějí.
Vzniká také problém při zapnutí kolejiště a používání tlačítka STOP na myši.

Toto na modulech nehrozí, neb máme DCC v koleji zcela samostatné a ovládání dopraven to neovlivňuje.

Ferda píše:Proto používám servoadaptéry, které řeší všechny tyto problémy, krom prvotního záškubu po zapnutí. Nicméně s tímto adaptérem nehrozí žádné poškození. Pouze si to kmitne a je klid. Navíc seřízení mikrospínačů si udělám pohodlně na stole a samotná instalace pod vexel není nijak náročná na přesnost. Pružné elementy to vyřeší samy.

Prosím o zaslání typu nebo nějakého kontaktu na tento servodekodér.
Protože, mě škubání serv velmi zajímá.

To není nic tajného a není ani těžké ho najít TADY.

komori píše:Prosím o zaslání typu nebo nějakého kontaktu na tento servodekodér.
Protože, mě škubání serv velmi zajímá.

---
Zatim jsem nevidel ovladac na servo, ktery by splnoval me mozna prehnane "pozadavky".
---
Zrovna ted testuji ovladac, ktery se mym pozadavkum opravdu velmi priblizuje a taky jsem ho dal na testovani v poctu 8 kusu na domaci kolejiste, kde je velmi intenzivne testovan. Zatim to vypada dobre, dokonce mne uzivatel navedl na velmi prinosnou myslenku, ktera se podarila realizovat. Pokud dopadne testovani dobre, urcite to zverejnim.