soubeh dvou loko

[radeksindy]

ad Jirka:
Myslím, že to je celkem marný něco Zdenovi vysvětlovat. On se v tom prostě chce babrat, tak mu to nechme. Pro ostatní opravdu doporučuji také stáhnout JMRI, kde se dá celkem primitivním způsobem měřit rychlost a kalibrovat. Dají se dokonce určit tři měřící body, aby byla jedna vzdálenost pro větší rychlosti a druhá pro menší.

Pro programátorsky schopnější je možno vše v JMRI využít (není potřeba ani Java, stačí si osvojit Python) a udělat si svoje rutiny, které budou speedometer využívat.

[zdeno]

ty brdo, to jsem dneska pozde vstaval
---
to Sindy:
50 mS, to je odhad, kazde projeti loko ukazuje jinou hodnotu a limitni stavy jsou odecitatelne a nasledne spocitatelne. Neni mozne, aby to takto litalo. Zkusim udelat opto zavoru a uvidim, ci tu chybu nedelaji jazyckove relatka.
---
to Jirka_US:
mam vyrobene LocoIo, zapomenul jsem, ze ho mam, pripojim relatka a vyzkousim. Za to opravdu nic nedam.

dodatek: to nejde, ja nemam CAB bus a NCU AIU periferii !!!

[radeksindy]

50 mS, to je odhad, kazde projeti loko ukazuje jinou hodnotu

Jestli tomu dobře rozumím, tak 50ms je variabilita měření průjezdu lokomotivy nějakým úsekem. Je to tak? Jak dlouhý je to úsek? Tato chyba reprezentuje rozptyl všeho po cestě od senzoru až po jízdu lokomotivy, nikoli jen variabilitu měření. A řekl bych, že lokomotiva v tom hraje tu největší roli. Někdy se rozjíždění dvou již seřízených lokomotiv považuje za signál k vyčištění kolejí. Drobná cukání, výpadky apod. mají vetší vliv než zbytek.
I kdyby variabilita měření byla těch 50ms, tak jak už naznačil Bedlisch, tvůj výpočet chyby je zcela scestný, protože měření je založeno na vzdálenosti, nikoli na časové bázi. Skutečná chyba bude asi o řád menší. Kdyby byla chyba tak velká jak píšeš pro 100km/h, tj. (cca 32cm/s) tak si dej senzory 3m od sebe a chyba bude o řád nižší než si spočítal.
Modeláři modelující železnice v USA se bez několika lokomotiv v jednom vlaku neobejdou a léta už umí problém řešit. Návod lze najít pod kíčovým slovem "speed matching", při použití google translátoru to bude srozumitelné pro všechny.

[Jirka_US]

to Zdeno:
používám LocoNet a připojeni k PC přes LocoBuffer-USB. Nicméně pokud mám pochybnosti o přenosu přes LocoNet (což tak na 99% problém není), tak je možné ty senzory připojit přímo přes paralelní port, v JMRI je nato rutina. Jinak se obávám, že mé možnosti nějak efektivně pomoci jsou téměŕ vyčerpány. Stále jsem se nedozvěděl, jestli funguje ten speedometer v JMRI.

to radeksindy:
Americká kolejiště jsem se do tohoto okamźiku neodvážil zmínit, protože se vždycky najde "pár vtipálků" a nechtél jsem "odepsat" dalśí vlákno na zamknutí. Soupravy se 4 loko v čele + 100 vozů a více a na konci další loko nejsou úplně neobvyklé a je celkem jasné, že bez slušného "speedmatchingu" by to nebylo možné. Jen např. N-kaři mají tu výhodu, že modely, které používají, mají větśinou tentýž pohon (myšleno konstrukčně), byť je to jiný typ lokomotivy. Odkazů na "speedmatching" je sice dost, ale praktických zkuśeností poskrovnu. Nicméně platí co bylo již řečeno, v JMRI je vše co člověk potřebuje.

[zdeno]

50 mS, to je odhad, kazde projeti loko ukazuje jinou hodnotu
Jestli tomu dobře rozumím, tak 50ms je variabilita měření průjezdu lokomotivy nějakým úsekem. Je to tak? Jak dlouhý je to úsek? Tato chyba reprezentuje rozptyl všeho po cestě od senzoru až po jízdu lokomotivy, nikoli jen variabilitu měření. A řekl bych, že lokomotiva v tom hraje tu největší roli. Někdy se rozjíždění dvou již seřízených lokomotiv považuje za signál k vyčištění kolejí. Drobná cukání, výpadky apod. mají vetší vliv než zbytek.
I kdyby variabilita měření byla těch 50ms, tak jak už naznačil Bedlisch, tvůj výpočet chyby je zcela scestný, protože měření je založeno na vzdálenosti, nikoli na časové bázi. Skutečná chyba bude asi o řád menší. Kdyby byla chyba tak velká jak píšeš pro 100km/h, tj. (cca 32cm/s) tak si dej senzory 3m od sebe a chyba bude o řád nižší než si spočítal.
Modeláři modelující železnice v USA se bez několika lokomotiv v jednom vlaku neobejdou a léta už umí problém řešit. Návod lze najít pod kíčovým slovem "speed matching", při použití google translátoru to bude srozumitelné pro všechny.

Je to tak, ja mam dva useky (2x30cm oproti sobe) na ovalu. Pokud jedu na stupen 127 na ovladaci, tak casy mereni jsou od 721 do 783 (ty cisla zatim nic neznamenaji, treba prevodni tabulky), tak to je tech 7% rozdilu.
Nejvic se objevuji cisla okolo stredu, teda 750. Cetnost je 70% a zbytek lita okolo toho. V zasade bych to mohl resit aritmetickym prumerem.
---
Ted si s tim hraji cely den a vymenil jsem relatka za dotykove dratky z CD mechaniky a na loko jsem dal kousek plisku, ktery mi ty dratky sepne. Chyba je stejna, takze ty jazyckove relatka jsou v tom nevinne.
Zitra zkusim vymenit Locobuffer USB za klasiku na COM a uvidim, co to udela. Mozna to delaji latency casy na USB.

[BohousP]

Zkuste se podivat na tento meric rychlosti - ma opticke snimani. http://www.eshop-honzikovyvlacky.cz/honzikovyvlacky/eshop/11-1-DIGI-CZ/0/5/428-Univerzalni-meric-modelove-rychlosti

videl jsem to, ale nevyhovuje. Je to pro mne polotovar, ktery treba pracne dokoncit na ulohu, kterou potrebujem.
Nezhazujem to, pro nekoho to muze byt dobre, ale ja mam vyssi naroky na obsluhu ...
---

Zdeno, nezlob se, ale to, co popisujes jsou ty vyssi naroky Fulduv rychlomer (polotovar, jak pises...) ma opticke snimani, vlastni procesor, vyhodnocuje v preruseni bla , bla, bla ... Chapal bych, kdybys' ho chtel integrovat do nejakeho vyssiho systemu, to by asi chtelo jeste definovat vystup dat ...
Tvoje reseni pres USB a PC je o vyssich narocich ? Tam mas tolik nedefinovanych opozdeni, ze bych tim nemeril ani teplotu piva ve sklenici ...

[radeksindy]

Je to tak, ja mam dva useky (2x30cm oproti sobe) na ovalu. Pokud jedu na stupen 127 na ovladaci, tak casy mereni jsou od 721 do 783 (ty cisla zatim nic neznamenaji, treba prevodni tabulky), tak to je tech 7% rozdilu.

Musíš mít prostě větší měřící úsek, aby si zmenšil vliv chyby měření a jízdy lokomotiv. Mít úseky 2 x 30cm je nesmyslně málo.

Zitra zkusim vymenit Locobuffer USB za klasiku na COM a uvidim, co to udela. Mozna to delaji latency casy na USB.

Výměnou nic nezískáš, oba typy mají průchod paketu nesrovnatelně kratší než je délka paketu. Spojení rozhraní/PC je řádově rychlejší než LocoNet, uvnitř jsou jen FIFO fronty, paket není nijak zpracováván, rozhraní zajišťuje hlavně časování.

Ted si s tim hraji cely den a vymenil jsem relatka za dotykove dratky z CD mechaniky a na loko jsem dal kousek plisku, ktery mi ty dratky sepne. Chyba je stejna, takze ty jazyckove relatka jsou v tom nevinne.

To je nám jasný, že relé jsou v tom nevinně. Kdyby si poslouchal zdejší rady zkušenějších, tak bys takové nesmysly ani nevyráběl.

[zdeno]

to Bohous_P:
pro mne to je polotovar, ktery se musi na dany problem adaptovat. Jinemu to staci, mne ne. Pokud sledujes debatu, mym pozadavkem je vytvorit skupiny loko s rozdilnymi stupni rychlosti(40,60, 80, 100) a udelat "nejake" tabulky rychlosti. Teda, vymyslet to tak, aby dva lidi mohli prijit na setkani se stroji, ktere se nikdy nevidely a bez problemu je pustili do vicenasobne trakce. Podle mnohych to je utopie, ale zkusim. Nanejvys mne poslou do haje zeleneho. No a co.
Proto tu hledam konsensus, jak by to bylo nejlepsi.
---
Snimani casu pomoci detekce obsazeni je passe, to je uplne mimo tolerance (bandaze, spatny kontakt).
---
To Sindy:
pokud dam velky usek, tak projeti na rychlost 2 bude nekonecne casovo narocne. Jedine reseni je pouzit nekolik ruzne dlouhych useku, kde pomer cas a rychlost bude vetsi nez realna chyba.
Teda na "10km/hod" pouzit 30cm a na rychlost "100km/hod" pouzit 300cm. Tim padem zlikvidujem chybu mereni na minimum. Jak pise Jirka, je skoda nevyuzit programy, ktere jsou hotove a k dispozici.
---
Jeste tu je treti moznost, ze chyby na kolejistijsou mnohem vetsi, nez chyba pri vypoctu krivky rychlosti. Potom by asi fakt bylo lepsi nastavit, co se nejlepe da a pouzivat loko bez bandazi, aby se to samo upravovalo.

[HonzaM]

Na http://www.fleischmann.de/de/news/items ... index.html je video ukazující způsob nastavení a ovládání souběhu dvou lokomotiv u centrál Z21 a z21. Výhodou je že není nutné sahat do nastavení dekodérů mašin, nastavování usnadní třeba fuldův měřič rychlpsti. Video je sice v němčině, ale z obrázků je to myslím dost jasné.

[Jirka_US]

to HonzaM:
Docela jsem byl zvědavý jakým způsobem bude vyřešeno měření. Ruční měření nechávám bez komentáře. Jen podotýkám, že Zdenovi vadí 50ms.....
Nastavení Cv67-94 je naopak cílem nikoliv nevýhoda a je také předmětem celého vlákna.....Naopak nevýhoda je, źe musím mít pro souběh 2 a více loko buď konkrétní centrálu nebo komerční software. popř. jsem limitován počtem loko pro souběh.

Přeci jen zopakuji co je cílem. Posadím loko na koleje a spustím program, který si zkalibruje lokomotivu a po ukončení zapíše příslušné hodnoty CV67-94 do loko podle jedné ze 4 zvolených kategorií (100km/hod, 80km/hod atd). To vše bez nějakých dalších ručních výpočtú, nastavovaní nebo programování. Souběh loko musí fungovat na jakémkoliv DCC kolejišti s jakoukoliv lokomotivou, která je zkalibrována pro příslušnou kategorii (max 100km/hod, 80km/hod atd) a to bez použití jakéhokoliv programu pro provoz (ovládání) nebo nutnosti mít nějakou konkrétní centrálu.
Příslušný program (skript v pythonu) pro nastavení CV67-94 v JMRI jiź existuje a uvedl jsem i kde hledat. Není myšlen DecoderPro ikdyź ten se k tomu rovněž hodí, ale je to jiź "manuální"práce.
Samotné měření rychlosti je méně než 10% celkové úlohy a zabere pár řadků kódu a 50ms bych asi teď neřešil...

[zdeno]

zase jsem trosku dal
zmenil jsem nastaveni USB portu, kde jsem ve vlastnostech zmenil LATENCY cas na 2 mS,
Mam XP, servis pack 3, > ovladaci panely > system > hardware > spravce zarizeni > Porty > USB serial port > vlastnosti > advanced > latency timer = 2
tim jsem to omezil na hodnoty 745-756, coz pokladam za celkem dobre.
Dalsi podminkou je odpojit Internet, ktery v tom casovani dela neskutecny bordel, protoze ma vysoke priority.
To je tak samozrejma blbost, ze to malokoho napadne.
hodnota latency = 1 dela chyby, nevim proc a nechce se mi po tom patrat.